Rust doesn’t have a formal specification other than “whatever the fuck our team hallucinated in this compiler version”

That's simply not true. The Reference, while not an ISO-style formal spec, does actually specify most of the intended language behavior, and incrementally approaches completion over time. But even if you insist on an ISO-style formal spec, there's Ferrocene: https://ferrous-systems.com/blog/the-ferrocene-language-specification-is-here/

it fucks your day because you’re not careful

The cve-rs vulnerability is actually not really something you'd ever write by accident. Also note that the bug report has multiple versions because, even though a "full" solution is pending some deeper compiler changes, the first ~~two~~ three versions of the exploit are now caught by the compiler. So, like I said, the compiler bugs do get fixed over time.

Borrow checking...existed in C++ too

Wat? That's absolutely not true; even today lifetime-tracking in C++ tools is still basically a research topic.

...someone found memory bugs in Rust, again, because it is NOT soundly memory safe.

It's not clear what you're talking about here. In general, there are two ways that a language promising soundness can be unsound: a bug in the compiler, or a problem in the language definition itself permitting unsound code. (unsafe changes the prerequisites for unsoundness, placing more burden on the user to ensure that certain invariants are upheld; if the code upholds these invariants, but there's still unsoundness, then that falls into the "bug in Rust" category, but unsoundness of incorrect unsafe code is not a bug in Rust.)

Rust has had both types of bugs. Compiler bugs can be (and are) fixed without breaking (correct) user code. Bugs in the language definition are, fortunately, fixable at edition boundaries (or in rare cases by making a small breaking change, as when the behavior of extern "C" changed).

Bugs around read-notifications are pretty bad. Slack still has those, but they're infrequent and transient, and often solvable with a hard-refresh.

It means both.

I understand what you're saying, but I want to do whatever I can to promote the shift in attitudes that's already happening across the industry.

And being late or never delivering out of fear of shipping buggy code is even worse.

From a business perspective, yes, usually true. But shipping buggy software can also harm your company's reputation. I doubt that this has been researched enough yet to be quantifiable, but it's easy to think of companies who were well known for shipping bugs (Microsoft, CD Projekt Red) and eventually suffered in one way or another for it. In both of those cases, you're probably right; Windows was good enough in the 90s to dominate the desktop market, and Cyberpunk 2077 was enough of a technical marvel (for those who had the hardware to experience it) that it probably bolstered the studio's reputation more than harmed it. But could Microsoft have weathered the transition to mobile OSes better if it hadn't left so many consumers yearning for more reliable software? And is Microsoft not partly to blame for the general public just expecting computers to be generally flaky and unreliable?

Imagine if OSes in the 90s crashed as rarely as desktop OSes today. Imagine if desktop OSes today crashed as rarely as mobile OSes today. Imagine if mobile OSes crashed rarely enough that the average consumer never experienced it. Wouldn't that be a better state of things overall?

This article somehow links to both the Reference and the Ferrocene spec, but still concludes that an official non-Ferrocene spec is necessary.

Why doesn't the Ferrocene spec accomplish what the author wants? He states:

In other words, without a clear and authoritative specification, Rust cannot be used to achieve EAL5.

What? Why can't the Ferrocene spec (and compiler) be used? Do Ferrocene and TÜV SÜD not count as "some group of experts"?

(Regarding the author's opening paragraphs, the Reference does make the same distinction about drop scopes for variables versus temporaries, though I can see why he finds the Ferrocene spec clearer. But that doesn't demonstrate that the Reference is useless as a stand-in for a specification.)

You can say the Rust implementation is wrong if it doesn't conform to the Reference. That is not the same as "you personally disagree with the behavior."

Rust's guarantees about the behavior of safe code are far stronger than anything C or C++ provides, with or without a formal spec.

Wow, I definitely should have google that myself before asking, but thank you for explaining and calling out that data point.

I honestly think that shows that it was in fact a bad idea to assign TLDs to countries. Having a country code acronym with a popular tech meaning is essentially just luck of the draw, so they've basically just arbitrarily given a few small countries a valuable resource to sell. I guess that benefits those countries, but I doubt "quasi-random fundraising for small countries" was ever the intent.

What were the issues you've had with WSL? I've been happily using that for a while now.

...I admit it's annoying that you need a new config file, but on the other hand, it's nice that it follows the xdg spec. Also there's really only one new file you need (init.vim) and it can just source your vimrc.

Plus, if you eventually do need or want to learn C++ for some reason, I honestly think that knowing Rust first would be quite helpful.

I think the "ten days" explanation has the merit of being charitable, because it implies that Brendan Eich wouldn't have made such short-sighted design choices under more favorable circumstances.

(I do not believe that it's a "sensible principle" to treat text as such a fundamental form of data that a basic language feature like the equality operator should be entirely shaped around it. Surely the consequences of building an entire language around text manipulation should be apparent by considering how awkward Posix-style shells are for any nontrivial scripts.)