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?

I don't really understand the connection between the blog post and your comment. Could you expand on the connection between his stance against CLAs and your paraphrase about mega-corps and how we should "suck it up because of principles"?

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

That's true in C as well, though. This is what people mean when they say things like "undefined behavior can result in time travel".

The difference is twofold:

• Rust's rules for valid unsafe code are not completely formalized yet. This means that there are open questions about whether particularly complex patterns in unsafe code will be guaranteed by future versions of the compiler to be sound. Conversely, the C and C++ spec are generally sufficient to determine whether any particular piece of code has undefined behavior, even if actually analyzing it to find out is not possible automatically using existing static analysis tools.
• Because safe Rust is so strict about what it permits, the compiler is able to make more aggressive optimizations; in theory, this could indeed cause undefined behavior to be "worse" at runtime than a comparable situation in a globally-unsafe language. I'm unaware of any actual examples of that phenomenon, though.

Minor point of clarification: it can't have runtime reflection, but in principle it could have compile time reflection.

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

This is as funny as the Clyde response, arguably funnier.

"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