Yes. Types are good. Numeric operations have specific hardware behavior that depends on whether you're using floating-point or not. Having exclusively floating-point semantics is wildly wrong for a programming language.

Πρεσυμαβλυ, ἰτ ἀλρεαδυ ὐσεδ ΣΙΜΔ, ἀνδ θατ'ς ὁ θε ἐξιστινγ ΓΝΥ ὐτιλιτυ βεατ ῾Ρυστ βυ ἀ φακτορ ὀφ 17ξ.

Looks like it wasn't even a bug, just a missed opportunity to use SIMD.

https://askubuntu.com/q/641049

TL;DR: it's supposed to send email to an administrator, but by default on some distros (including Ubuntu), it isn't actually sent anywhere.

I didn't use the word "personal", but it's inherently somewhat personal in that it's one person trying to fight back against a decision that Linus and GKH have both endorsed (to put Rust in the kernel). "Crusade" is strong wording, but so is "I will do anything I can to stop this." That's far beyond simply "prioritizing [other] things."

The spec requires errors to be a single string, and also mandates using the space character as a separator? I'm not a fan of deviating from spec, but those are...bad choices in the spec.

For anyone else wondering, here's the text of the actual email cited as the CoC violation:

Michal, if you think crashing processes is an acceptable alternative to error handling you have no business writing kernel code.

You have been stridently arguing for one bad idea after another, and it's an insult to those of us who do give a shit about writing reliable software.

You're arguing against basic precepts of kernel programming.

Get your head examined. And get the fuck out of here with this shit.

... the issue I have is people lying and saying Rust is a drop in replacement for js

I am genuinely curious whether you've actually seen this claim before, or if you badly misunderstood or are simply exaggerating a claim about Rust being a good language for web servers, or if you simply made this up as a straw-man. I can't imagine anyone who knows what they're talking about using those words I that order.

[warning: "annoying Rust guy" comment incoming]

I don't think Rust is perfect, but arguably I do "idolize" it, because I genuinely think it's notably better both in design and in practice than every other language I've used. This includes:

• C
• C++
• Java
• C#
• Kotlin
• Scala
• Python
• Ruby
• JavaScript (...I've barely used this, but I doubt my opinion would change on this one)
• Perl
• Go
• Bash (...look, I've had to write actual nontrivial scripts with loops and functions, so yes, Bash is a real language; it just sucks)
• Tcl/Tk (if you don't know, don't ask)
• CommonLisp (...again, I've barely used this, and I wish I had more experience with this and other Lisps)

In a literal sense, I agree that all (practical) languages "are flawed." And there are things I appreciate about all of the above languages (...except Tcl/Tk), even if I don't "like" the language overall. But I sincerely believe that statements like "all languages are flawed" and "use the best tool for the job" tend to imply that all (modern, mainstream) languages are equally flawed, just in different ways, which is absolutely not true. And in particular, it used to be true that all languages made tradeoffs between a fairly static, global set of binary criteria:

• safety/correctness versus "power" (i.e. low-level system control)
• safety/correctness versus run-time efficiency (both parallelism and high single-thread performance)
• ease-of-use/ease-of-learning versus "power" and runtime-efficiency
• implementation simplicity versus feature-richness
• build-time versus run-time efficiency
• type-safety versus runtime flexibility

Looking at these, it's pretty easy to see where most of the languages in my list above fall on each side of each of these criteria. What's special about Rust is that the core language design prevents a relatively novel set of tradeoffs, allowing it to choose "both" for the first two criteria (though certainly not the latter three; the "ease-of-use" one is debatable) at the expense of higher implementation complexity and a steeper learning curve.

The great thing about this isn't that Rust has "solved" the problem of language tradeoffs. It's that Rust has broadened the space of available tradeoffs. The assumption that safety necessarily comes at a runtime cost was so pervasive prior to Rust that some engineers still believe it. But now, Rust has proven, empirically, that this is not the case! And so my ultimate hope for Rust isn't that it becomes ubiquitous; it's that it inspires even better languages, or at least, more languages that use concepts Rust has brought to the mainstream (such as sum-types) as a means to explore new design tradeoff spaces. (The standard example here is a language with a lightweight garbage-collecting runtime that also has traits, sum-types, and correct-by-default parallelism.)

There are other languages that, based on what I know about them, might inspire the same type of enthusiasm if I were to actually use them more:

• Erlang
• Gleam
• OCaml
• Swift

...but, with the exception of Swift, these are all effectively "niche" languages. One notable thing about Rust is that its adoption has actually been rather astounding, by systems language standards. (Note that D and Ada never even got close to Rust's popularity.)

rm - rf is the only version that makes sense, since the only reason to delete and re-clone is to recover from an unexpected .git/ state, and git rm won't remove that.

And in fact it's not specific to Rust, and Rust is the first language with a fix available. (Thanks to some other comments for pointing this out.) Java has apparently declared it "won't fix."

https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/#appendix-b-status-of-the-affected-programming-languages

Neovim is a fork; it's compatible with those.