The usual argument is that it is a distraction when you’re designing a language, and it leads to programming languages that are all excellent for writing compilers and parsers, but not particularly good for other things.

Since the majority of programs are not compilers, it might make more sense to focus on interesting things that aren’t relevant to compilers.

Some ideas from the top of my head: async I/O, a great SIMD story, effect systems, robustness systems for long-running processes (I’m only aware of Erlang/Elixir), and many others.

Compilers do exercise some things, like error handling and memory management, but they’re not particularly difficult or interesting in general.

I had a little homebrew CI system, and decided its first use case would be building itself. Seems like an extremely obvious thing to do, right?

The problem happens when you have bugs and test failures. The hoster and hostee look the same, behave the same, and emit the same error messages. So I had unknowingly opted into spending a big chunk of my debugging time being confused and wrong about A) where errors were coming from and B) what they even signified.

Basically, self-hosting too early, before the thing was stable and trustworthy, was a disaster. (It's obvious in retrospect, really, but was still pretty awful at the time.) I tried again later, after everything had stabilized and it was routinely building other projects routinely, and it was fine.

The main objection I used to have was there are infinite things to do when building a programming language, it's already enough to build 1 compiler, you probably shouldn't also build a second as your main stress test of the language.

That said if your languages is for building compilers you'd probably want to do it. Otherwise, basically no one writes compilers, and if they are they're writing them for their own languages in something much more mature than your nascent language. And if the ambient advice is to bootstrap asap, they'll only be using your language for a hot second anyway, so they're the worst users to cater towards.

These days I think all languages should try to do it with an LLM because, why not? That also means bootstrapping a compiler isn't exactly an impressive feat anymore, most new languages are doing it now.

The problems with bootstrapping a self hosted compiler are often greatly overstated.

These days with LLM bootstrapping the compiler is a lot like using YACC for the parser. You just point the LLM at your compiler spec, tell it "bootstrap this" and then it does.

I would go so far as to say Zig even tries too hard to solve it (although they reused existing technology they already wanted, so it was almost free). You can bootstrap a self-hosted compiler to new environments by porting the source, cross-compiling it, and scp'ing or otherwise downloading it over to the target. And that's if you don't want to just use QEMU to develop it. We already do this exact thing when developing for embedded devices or often any type of aarch64 programs.

What additional cost does it have to implement the toolchain in C? I would say there is some benefit in terms of implicit testing to have a compiler self-hosting. But having a toolchain in C also has real benefits.

To be fair, it really is a confusing way of communicating, and it’s useful feedback when taken to heart.