Isn't your objection there basically "LF doesn't pay enough for people to put up with negative social dynamics"? In which case, wouldn't paying more help a lot?
Because abstractions leak. Heck, abstractions are practically lies most of the time.
What's the most time-consuming thing in programming? Writing new features? No, that's easy. It's figuring out where a bug is in existing code.
How do abstractions help with that? Can you tell, from the symptoms, which "level of abstraction" contains the bug? Or do you need to read through all six (or however many) "levels", across multiple modules and functions, to find the error? Far more commonly, it's the latter.
And, arguably worse, program misbehavior is often due to unexpected interactions between components that appear to work in isolation. This means that there isn't a single "level of abstraction" at which the bug manifests, and also that no amount of unit testing would have prevented the bug.
I think his views on how to achieve good quality software are nearly antithetical to the goals of Rust. As expressed in that blog post and in Clean Code, he thinks better discipline, particularly through writing lots and lots of explicit unit tests, is the only path to reliable software. Rust, on the other hand, is very much designed to make the compiler and other tooling bear as much of the burden of correctness as possible.
(To be clear, I realize you're kidding. But I do think it's important to know just how at odds the TDD philosophy is from the "safe languages" philosophy.)
There is nothing specific in the rust port that makes fish more available for servers or LTS distros.
Being written in Rust does improve availability, because by default Rust statically links against everything except libc, and you can opt out of that if necessary. So there is inherently no need to build separate dependency packages for each distro, unless you use a Rust crate that specifically links to a C or C++ library.
It's relevant because there are still platforms that don't have actual Bash (e.g. containers using Busybox).
sh is not just a symlink: when invoked using the symlink, the target binary must run in POSIX compliant mode. So it's effectively a sub-dialect.
Amber compiles to a language, not to a binary. So "why doesn't it compile to sh" is a perfectly reasonable question, and refers to the POSIX shell dialect, not to the /bin/sh symlink itself.
I haven't worked on any teams where all members committed "every 24 hours", and there have always been some branches that live longer than we'd like (usually just unfinished work that got deprioritized but still kept as an eventual "todo"), but most teams I've worked on have indeed followed the basic pattern of only one long-lived branch, reviews and CI required prior to merge, and all feature-branches being short-lived.
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"?
The author also makes some incorrect or misleading claims, specifically about emacs. I acknowledge there's a high bar for entry there and don't personally like emacs, but it's not modal, and it does have the ability to display images and markdown previews.
I know several world class programmers, and interestingly, the commonality among them is that they all seem to use Vim as their code editor. Many people I know who think of themselves as world class programmers use Emacs.
It absolutely can be constructive. The reason people respond that way on SO is because it is genuinely common for people to think they need something because they've misinterpreted the core problem they have.
Isn't your objection there basically "LF doesn't pay enough for people to put up with negative social dynamics"? In which case, wouldn't paying more help a lot?