... 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.)

First and foremost _____ is a giant hack to mitigate legacy mistakes.

Wow, every article on web technology should start this way. And lots of non-web technologies, too.

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.

Rust is extremely geared toward maintainability at the cost of other values such as learnability and iteration speed. Whether it's successful is of course somewhat a matter of opinion (at least until we figure out how to do good quantitative studies on software maintainability), and it is of course possible to write brittle Rust code. But it does make a lot of common errors (including ones Go facilitates) hard or impossible to replicate.

It also strongly pushes toward specific types of abstractions and architectural decisions, which is pretty unique among mainstream languages, and is of course a large part of what critics dislike about it (since that's extremely limiting compared to the freedom most languages give you). But the ability for the compiler to influence the high-level design and code organization is a large part of what makes Rust uniquely maintainability-focused, at least in theory.

Perl programs are, by definition, text. So "paint splatters are valid Perl" implies that there's a mapping from paint splatters to text.

Do you have a suggested mapping of paint splatters to text that would be more "accurate" than OCR? And do you really think it would result in fewer valid Perl programs?

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

Go if you want a real mental challenge

I don't mean to be rude, but I find this baffling; what do you mean by it? One of the primary design goals of Go is to be simple to learn (this is fairly well documented), and it's one of the few things I really have to give the language credit for. Rob Pike has specifically discussed wanting it to be accessible to recent CS graduates who have mostly used Java. I have never heard anyone before describe learning Go as a "challenge."

I wish I were more aware of what level of burnout there is in other large open source projects. Is Rust unique? Better? Worse? How do other projects manage this (if in fact they do)?

Projects like GCC and the Linux kernel do almost all their development in the open, via mailing lists, so maybe it would be possible to analyze that data to determine, say, the rate at which contributors drop out of the project. But I'm not aware of anyone having actually done an analysis like this.

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

There are a fair number of them: https://en.m.wikipedia.org/wiki/Non-English-based_programming_languages

But arguably, as long as the compiler supports unicode, it shouldn't matter that much what language the keywords are in. There are other more important issues impacting how easy it is to program in non-English languages:

• availability of documentation and tutorials
• English comments and API names in common libraries, especially the standard library
• tooling for handling unicode, especially BiDi (which is part of why Arabic is especially tricky) - Vim, for instance, has had an open issue about this for almost a decade: https://github.com/vim/vim/issues/204

"I don't care too much because creating your own terminal is like 20 lines of code these days. People who really care can just create one as easy as configuring an existing one."

wat