Contrary opinion to the others: In almost all cases, don't bother self-hosting the entire compiler. At least not if you want an end result that optimizes nicely

Contrary opinion to the others: In almost all cases, don't bother self-hosting the entire compiler. At least not if you want an end result that optimizes nicely and can generate code for a wide range of architectures. That's a lot of work, and you're better off targeting an existing compiler framework (ahead of time: GCC or LLVM; JIT: the JVM or the CLR; in both cases there are probably other good choices as well). Of course if you start your project with "I wonder what an X compiler in X would look like", you will self host your hobby project end to end. But if you are trying to make something that is maximally useful for others, use the already existing stuff that is out there, and that is much better than what you would pull off on your own. As for the parser, it's probably true that for many languages, self-hosting the frontend may be attractive. For others it might not. Someone else wrote: "if people who are really good (let's say) Go programmers want to make the Go compiler better they then don't have to try and write go in C++ if the main compiler is written in C++", which is somewhat true. On the other hand I once had to do stuff in the gfortran frontend, and I was very happy that it was written in C and not Fortran, because I know C but don't know Fortran. So I guess as long as your language is niche among people likely to be compiler developers, the point about attracting that talent doesn't hold. If your language gets popular enough, self hosting the frontend should become more interesting. Before that it's more of a gimmick.