That’s the mrustc project the author mentions. He wants Rust to be bootstrapped earlier in the process.

Okay. That’s just imposing a different (and at least equally arbitrary, if not moreso) definition of bootstrapping. Why does it matter that the author didn’t explain their “deeper reasoning” for having an interest in bootstrapping, or the Bootstrappable Builds project specifically? If you feel like that project isn’t meeting a sufficient bar for what counts as “bootstrapping”, or that using C as the first high-level language they bootstrap is “tragic”, take it up with that project, I guess.

The author doesn’t explain exactly what their interest in bootstrapping is, but the goal is pretty explicit:

So, for me, it would be really nice if there was a Rust compiler that could be bootstrapped from C. Specifically, a Rust compiler that can be bootstrapped from TinyCC, while assuming that there are no tools on the system yet that could be potentially useful.

There is nothing special about C.

I wish that were true, but isn’t it somewhat wishful thinking? Even an assembly-language Lisp would require an operating system in order to build a functioning compiler, wouldn’t it? And operating system APIs are in C.

Edit: more importantly, as the post explains, the special thing about C is the existence of TinyCC.

I agree with everything in the article, which makes it all the more unfortunate that I really detest Go as a language.

(It’s getting better, though.)

I’m a Rust fan, and I do think they eventually struck a pretty good “visibility vs noise” balance with ? (which was highly controversial at the time).

I should have stressed the “opinion” part of “IMO”. What I mean is that, when I read this, it struck me immediately as being exactly correct: https://joeduffyblog.com/2016/02/07/the-error-model/

The problem is that most languages with exceptions treat that as the idiomatic error mechanism. So checked exceptions were invented, essentially, to do exactly what you say: add the exception type to the function signature.

Having separate errors-as-return-values and unwinding-for-emergencies is a much more recent trend (and, IMO, an obviously good development).

Yes. True. But Uncle Bob literally complains about non-nullable types in the linked blog post.

I’m not saying testing isn’t important. I’m saying that hand-written unit tests are not the end-all be-all of software quality, and that Uncle Bob explicitly believes they are.

The blog post? Yeah, that was the moment I lost most of my remaining respect for his tech opinions.

Unlikely, unless his view has changed substantially in the last seven years: https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html

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

deleted by creator

The phrasing “available on servers” does seem quite weird. It does seem that having a single, standalone binary is much easier with Rust than with C++, though.

Oh, right, yes; of course it statically links the standard library. I was thinking of the fact that the standard lib is precompiled, but yes, it’s statically linked.

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 not so much a problem of there being things you “can’t do” in other shells or older Bash, as that it breaks existing shell scripts, which is frustrating.

Just because it doesn’t matter for most users doesn’t mean it isn’t a real limitation. I acknowledged as much in my original comment.

Did you read the linked Q&A?

What do you get if you run /bin/bash --version?

You get admin privileges on MacOS like a big boy. You can use bash or zsh commands in Terminal all you want.

Cool. So try updating to a version of Bash from the last 15 years, because the pre-installed one is Bash 3, because Bash 4 and 5 are under the GPLv3 license, which Apple won’t comply with.

…ah, no, you can’t update the pre-installed Bash, because it’s on a section of the file system that is read-only even with admin access. You can install Bash 5 as a separate shell, and use that as your default terminal shell, but any scripts written with the standard #!/bin/bash instead of the more flexible #!/usr/bin/env bash will still use Bash 3.

This “handholding” (or really, a safety net) is arguably a good thing, or at least a positive tradeoff; but you can’t claim it doesn’t exist.

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.