Bootstrapping trust in compilers

It is usually a significantly manual process (I now have to download and install an OS which is supported by the runtime and build a cross-compiler for my target platform, which may or may not even be possible, or even work), isn't always supported by the runtime, usually requires changes to the build procedure, often requires special patches - and at the end of all that users are still left with either having to repeat all this themselves, or trust someone else's binary bootstrap.

Compared to a simple, portable, C-based bootstrap where any user can type 'make' and ensure provenance directly from source. For what gain?

Uninformed? Perhaps. I haven't designed and written my own language, and I'm certainly no expert. I'm just someone who gets asked to port these new languages to platforms which aren't Linux or OSX, and it's a lot of hard work. I just know that if I did it write my own it would look a lot more like perl/python/lua than ghc or go from a build perspective.

http://homepage.ntlworld.com/edmund.grimley-evans/bcompiler....

> Portability matters. If you want your language to be useful and available to as many people as possible, why would you seek to artificially limit the number of platforms it can be built on, just so you can avoid writing the bootstrap in C? I'm sure there is some amount of pride on the part of the language author when their language can bootstrap itself, but it certainly isn't a pragmatic decision.

This problem is easily solved by having a rule that each new version of the compiler must compile in an older version of the compiler. The first few versions are written in C, and once the compiler is self-hosting, new versions of the compiler are compiled on older versions of the compiler. This gives you a path from C to the current version of the language.

In practice, this happens very naturally, because it's how compilers are usually written. Assuming you have version control and the first versions of the compiler are written in C, you usually have the ability to bootstrap up from C. The only thing missing in many projects is documentation and tooling for that process.

But beyond that, off the top of my head, I'd say the primary reasons:

* performance

* memory usage (think resource restricted environments)

* performance

* no extra runtime needed

* performance

* start up overhead

* predictable performance (think real-time stuff)

* access to ubiquitous native APIs

* performance

Look at programs like Nginx or PostgreSQL.

They make crazy effective performance optimizations that are really only available to native code. Of course, not every program is a web server or a database, but they are compiled for good reasons, and those reasons apply to many other programs.