Rust has multiple qualified compilers for several safety standards, with more in progress.

Both of these things are discussed in the article. (changelogs and semver)

They're hand-waved away by saying the changelogs are bad and the semver isn't always accurate. While I mostly agree with, that doesn't mean they don't provide _some_ value. You get categorized changelogs (even if the messages are technical) and semver that's generally correct. The alternative of good changelogs and perfect semver isn't free.

You can also roll your own strings in Rust just fine. Take the bstr crate, for example.

> (I don't know if they've considered adding it)

The paper you want to look up is “epochs” (the OG name for editions) but there were questions that never got resolved, and so the proposals are dead for now at least.

The Rust language does not currently have an LLM policy, but the one under discussion is not a total ban.

That would be a reasonable worry, except that this specific issue has been discussed for like, a decade. It’s the only beef people have. It’s unlikely that they’ll find something else any time soon.

Talking about this specifically, yes it's difficult to think of a reason to change ranges in the future.

But bringing my post to a more general stance, I'm of the opinion that Rust is fixated a bit too much on the goal of having a minimal core and leaving the ecosystem to find its own ways forward. Maybe it wouldn't hurt that much if the language, with its current age, started opening up to providing more of the stuff that's currently deemed "inappropriate" for the stdlib. Didn't we have enough time to let the bazaar do its thing and come up with some locally optimal API designs yet? While having a consistent way to version APIs (such as the mentioned Go's /v2) solves the issue of "being stuck forever".

I guess all this to say that extremes are never healthy. The Rust Way is a good one for letting the community discover and experiment, but not even compromising on an async engine is (as always, IMHO) taking it a bit too far.

Async engines are one of the worst things you could have chosen as an example. They are wide and varied, with a ton of different tradeoffs for different scenarios. Ones for high performance networking are also complex, requiring tremendous engineering effort, and are massive. Putting something in the stdlib doesn’t magically make something better maintained.

Interfaces also do not magically become good or useful. There has been suggestions around some async traits, but no suitable one has actually been found yet. Yes, it has been a very long time, but that’s just how it goes sometimes.

> but not even compromising on an async engine

FWIW, Tokio's API is not the right one for io_uring, buffer pools for reads changes everything. There'll be yet another huge ecosystem churn. I'm personally hoping for it to happen sooner rather than later.

The E | F | G could be two different features, "anonymous sum types" or "union types".

TypeScript is an example of a language with union types: https://www.typescriptlang.org/docs/handbook/unions-and-inte...

"untagged union" usually means "no discriminant" not "runtime discriminant."

(Rust has both tagged (enum) and untagged (union) unions, but untagged ones are unsafe and therefore mostly used for C interop and similar cases.)

People often call Python/TypeScript unions "untagged unions" even though they're a very different creature from C/Rust unions. Ideally there'd be a term specifically for them but I'm not aware of one.

See https://en.wikipedia.org/wiki/HAWK_beacon as one possibility here (and these are not without their own drawbacks, to be clear)

> for no reason except style.

There are other reasons (not that they're good ones):

https://www.reuters.com/article/business/energy/how-us-emiss...

https://en.wikipedia.org/wiki/Corporate_average_fuel_economy