Hacker News Reader

Comment by stevefolta | Hacker News Reader

Re "c)": No, self-hosting is the biggest temptation, and the worst mistake, for any programming language. It's death to bootstrapping. However, if you do succumb to the temptation to self-host, having a C backend, as Copper does, is probably the best way to handle it.

View on HN

I've never really understood the opposition to self-hosting.

As long as:

* Your language is the kind of language that suits compiler development.

and

* You support compiling to C or something so that bootstrapping doesn't involve an opaque binary or compiling 30 different git commits in a row.

What are the downsides exactly?

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.

What's the problem with self-hosting? I do imagine it's easier to write a compiler in something like Haskell.

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

Self-hosting is a trivial matter if you can roughly map a subset of features of an existing language to your language. Write bootstrap compiler in that language and translator in parallel (as long as you have good AST/LST), run conformance tests on both.

As long as one of the backends is something widely available, I don't see a problem. C is a decent option. LLVM IR is another.

This isn't at all true, as proven especially by Zig.

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.

As someone who has monkeyed around with the zig compiler, having the bootstrap done made monkeying around way, way more straightforward than when it wasn't around. I will admit I don't know the details and it's possible the QOL improvements that affected me only depended on other things that got solved along the way. But I have been building the stage0 and stage1 compilers to get my first artifact when I bump to the latest.

Why is it harder to bootstrap a self-hosted language than it is to bootstrap a language implemented in C, which itself must be bootstrapped?

Bootstrapping is a one-time cost, but implementing the toolchain in C is a cost everyone has to pay every single time they touch the toolchain source.

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.

Reply on news.ycombinator.com