Two, arguably: one with Apple and one with upstream Linux.

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.

Christoph Hellwig isn't criticizing Rust the language, and Hector Martin isn't claiming that he is. This is about a project, Rust for Linux, that has been endorsed by both Linus and GKH, and one maintainer personally attempting to stop it from moving forward.

The user clicked an option to "discard" all changes. They then got a very clear pop-up saying that this is destructive and cannot be undone (there's a screenshot in the thread).

The article is more about the behavior of members of the C++ committee than about the language. (It also has quite a few tangents.)

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"?

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

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.

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