unrecoverable errors in the form of panic

ahem

Correct link without /edit/: https://github.com/Nutomic/ibis/releases/0.1.2

you’re not supposed to immediately reach for macros

correct

for small things you don’t quite like about the language.

incorrect

Excessive macro use makes it impossible for others (including your future self) to read your code

N/A. the macro above is trivial.

impossible for others to read your code and there’s often good reasons why it’s designed like it is.

fiction

There is a general mechanism in Rust that allows language users to add their own sugar. It’s called macros 😉

macro_rules! keep {
    (let $id:ident = $expr:expr => $($tt:tt)+) => {
        let $id = $expr;
        let $id = $id$($tt)+;
    }
}

fn main() {
    keep!{ let path = std::env::current_dir().unwrap() => .as_path() };
    println!("{path:?}");
}

You can remove let from the macro’s fragment specifier and invocation.

mastering_rust

Maybe wait until you’re actually good at it.

Rebinding with and without mut is a known and encouraged pattern in rust. Leaving things as mut longer than necessary is not.

Neither.

• make new() give you a fully valid and usable struct value.
• or use a builder (you can call it something else like Partial/Incomplete/whatever) struct so you can’t accidentally do anything without a fully initialized value.

Maybe you should also use substructs that hold some of the info.

Good.

Can you formulate your question better, with a minimal example and properly formatted code?

If you’re using an LLM to “learn”, stop. Otherwise, I don’t understand what lazy_static has to do with anything.

It’s hard to tell what you’re asking. But maybe you’re confused because println! (it’s a macro btw) expands to code that involves format_args! which is a compiler built-in that doesn’t take ownership of the token expressions that get passed to it. Notice how the bottom of the format_args! page has this to say:

Lifetime limitation

Except when no formatting arguments are used, the produced fmt::Arguments value borrows temporary values, which means it can only be used within the same expression and cannot be stored for later use. This is a known limitation, see #92698.

So, it’s kind of a feature and a limitation at the same time.

Looks trivial and easy to automate.
I possibly would have done it if they had a test suite.
But unless I didn’t look hard enough, they have no tests at all (other than linting)!

If NULL was a billion dollar mistake, imagine how many billions it’s going to be for AI-generated code.

I have no specific knowledge of this stuff. But the generic answer is an obvious one.
However Python code does it can be replicated in Rust.
For example, if python code executes the driver as a subprocess, then that too can be done in Rust.
So checking how Python code does it will probably lead to an answer to this question.

Maybe ask a web dev community about this.
There could be something better written in Rust.
There could be something better NOT written in Rust.
They should know.

Good. But a lot of us do this already:

[target.x86_64-unknown-linux-gnu]
linker = "clang" # for mold
rustflags = ["-c", "link-arg=-fuse-ld=/usr/bin/mold"]

[target.x86_64-unknown-linux-musl]
rustflags = ["-Z", "gcc-ld=lld"]

I didn’t understand your sentence. But: Having concerns is valid.
Having them in the context of this story/ad is misplaced.

IBM invested 1B$ in Linux all the way back in year 2000 (imagine how much that is worth with tech inflation), and they did it again years later.

That 1M$ is nothing. It’s not nearly enough to control the Rust foundation for one year, let alone controlling the Rust project as a whole. Calling it a “Vote of Confidence in Rust’s Future” was probably a good-spirited joke from the author, at least I hope it was.

Note that IBM still doesn’t control Linux (even after acquiring RedHat), and we still have no problem calling them evil. Some of us still have no problem calling MS evil either, although many of the new crop of developers won’t, because for them the chance to have the financial privilege of working there someday outweighs any moral considerations. Incidentally, there is a good intersection between this group, and the group that takes moral posturing about whatever in-group approved cause of the month to the maximum. Ironic, isn’t it?

This is effective advertisement, not a donation. A real ad (with a campaign) would probably have cost much more, and wouldn’t continue to be propagated for free months after the ad campaign is over, like this peace of news.

This type of ad is also much harder to filter/block, since not only it appears to be site-native, but also topic-native.

Not based on, but built on top of Iced.

The fork wouldn’t be that different from whatever upstream Iced snapshot it last synced with. There are two major, if peripheral, changes still. A renderer for some Wayland special needs, and some integrated accessibility support. At least that was the case until a few weeks ago. I don’t think anything significant changed since.

So the Iced API itself is largely the same. However, since this is built on top of Iced. COSMIC apps are more inclined to use abstractions and tools from libcosmic wherever applicable instead of using Iced API directly. But you still see plenty of direct Iced API use.

Thunderbird is still going?

What’s next? Rust in Songbird?

A conspiracy theory explanation is not necessary as it:

• Operates on the idealistic myopic assumption that common people are an altruistic force for good. The reality is that there is plenty of self-servingness going around.
• Assumes full collusion, removing the simple possible explanation of useful fools being taken advantage of to the maximum. Note that useful fools can still be motivated by self interest. They are just not necessarily fully aware of how they are being used.
• Ties an argument to unprovable points/events.

It doesn’t take a conspiracy theory explanation to observe how classic corporate anti-FSFers are very content with social licenses (CoCs) being elevated to a position where they are considered more relevant and have more signal power than the software licenses chosen, or how many new-gen open-source contributors have no problem singing the New Microsoft (and the likes) praises… etc

You can easily guess who is behind such narratives and why.

You would think so. But anti-FSF sentiment comes in different forms nowadays.

My first (and only) visit to the Mastodon world was years ago. Top post (or whatever you call them) was from some micro-celeb (who probably didn’t even code) bitching about how Stallmann caused great damage, and how the FSF’s biggest achievement was giving decades of “our” free labor to corporations. The microblogtards replying agreed of course. Needless to say, that tab didn’t stay open for long.

Social war ultras (big intersection with microblogtards) also don’t like Stallman and the FSF.

So, new developers may have chosen non-FSF licenses not only because of copyleft implications. But also because it looks and goes along better with the posturing ethics of the times. The snowball has already gotten large of course, and next-gen devs may just be going along with the choices made by their predecessors or library dependencies without knowing much about the why.

Still, there should probably be more MPLv2 in the Rust ecosystem.