I thought of the term "bootstrap pilgrimage" years ago to concisely refer to such projects --- both to highlight the journey of learning they give, and to refer to the fact that not everyone may have the time nor skill to embark on one.

I've always struggled to find a succinct way to describe the benefits of installing Arch Linux. "bootstrap pilgrimage" is the perfect term!

Archlinux has gotten substantial easier to install in the last decade or so. I no longer get any 'bootstrap pilgrimage' feelings from it. Lots of stuff now works out of the box, even.

But I guess, I'm too used to it, too?

I haven't installed it since ~2016/2017, so my knowledge might be outdated. If you use one of the arch-based distros with a GUI, then you're right that it's very easy to install.

If you follow the Wiki though, I think you still learn quite a bit: https://wiki.archlinux.org/title/installation_guide

I am following that guide whenever I do a new install. I've never used one of those GUI enabled installers for Arch.

I started with Arch around 2010, and last did a fresh install on a new computer a few months ago.

Yes, you can still learn quite a bit from the guide if you are new to it. But it's gotten a lot easier over the years. I remember eg X and wifi used to be a bit of a pain, but now they mostly just work. Thanks to UEFI, you can also boot directly into your kernel, and no longer need to muck around with an extra boot manager like grub or syslinux. (Assuming your computer's UEFI implementation is not too buggy.)

I like that term. I've tried a couple of bootstrap pilgrimages.

For a job, we needed Go on FreeBSD 8, which entailed a local patch to revert pipe2 to pipe in Go, and building from source. That was my first bootstrap. Go, as Russ mentions, is easy to bootstrap, and I've done it a couple of other times.

I've tried to bootstrap Rust, from its old compiler written in OCaml, but that one is trickier. It has not been maintained like Go's bootstrap compiler and the bootstrap chain has long since been broken. Furthermore, rustc is only guaranteed to be able to be buildable with the previous release. As far as I can tell, no one has built rustboot in many years. I like doing software archaeology, so I'll probably try again with that project sometime.

mrustc takes another approach, closer to the aforementioned GNU Mes, in that it's a reimplementation of Rust, intended for bootstrapping rustc. https://github.com/thepowersgang/mrustc

Relevant is https://github.com/NixOS/nixpkgs/pull/85542 , a (very stale) PR that uses mrustc to get straight to Rust 1.29 and then walks the chain.

nowadays you can skip straight to 1.54, that's relatively fresh

I believe Guix has shiny and clean rust bootstrap using mrustc, no?

Oh nice - https://github.com/Millak/guix/blob/00747316ee0e1a7962ffe226...

Funny story: The way my compiler ( https://github.com/neat-lang/neat ) used to build is, three years ago there was an initial minimal compiler that was written in D. And every time you checked out the Neat repo on a new system, it had a file with a list of breaking commits, and it would:

- git clone itself in a subfolder

- git checkout and build the initial D compiler

- install it in a temporary prefix

- git checkout the first breaking commit and build it with the initial compiler

- install it over the previous compiler

- git checkout ...

and so on. In normal operation all these stages would be cached, so before I abandoned this approach, I think I was up to a hundred or so intermediate versions.

Eventually I started doing git releases, which needed a better solution. So since I have an optional C backend, I just build the compiler with the C backend, then zip up all the C files to make the release. Then to bootstrap from it, I just do (effectively) gcc *.c -o build/neat_bootstrap.

edit: Ah, here it is: https://github.com/Neat-Lang/neat/blob/v0.1.6/bootstrap.sh

That's a lot of steps in your bootstrap chain. I think tying it to releases can make it easier, but it's good your process is automated.

Rust has a long chain too, but rustc only uses features itself, that the previous release supports. Releases are every 6 weeks.

Go had been bootstrapping from 1.4 (the last C compiler release), until the release of 1.20 this year, when the bootstrap compiler was bumped to 1.17.13 and will be bumped yearly [0]. That meant go1.4 had to be able to compile new versions, keeping the compiler from using new features in itself for 8 years. Notably, this now allows for generics to be used in the compiler.

[0]: https://github.com/golang/go/issues/54265

I did that too, many compilers ago! Of course, I broke something somewhere and forgot where. My compiler tastes have changed since, and I think next time I'll maintain a basic bootstrap from Scheme or Rust, but I always thought it was a neat way to do it.

A couple years ago, I also worked on bootstrapping the Rust compiler from the last OCaml version. I managed to get it up to an early 2014 snapshot, before I got stalled on a particularly tricky issue with the forked LLVM, and decided to drop the project for the time being. I still have all the 200-odd scripts to patch and build everything; I should probably get around to publishing those.

You should definitely publish that and comment a link! That would be very useful, since you got much further than me.

See also the Bootstrappable Builds project, especially their stage0 projects:

https://bootstrappable.org/ https://github.com/oriansj/stage0 https://github.com/oriansj/stage0-posix/

Reminds me of https://elephly.net/posts/2017-01-09-bootstrapping-haskell-p...

The difficulty of bootstrapping GHC