These are extremely superficial observations. You should learn more about each of these languages before dismissing them; Go is especially easy to learn.
(I quite dislike Go, actually, but "it has no classes" is nowhere near a valid reason not to learn a language.)
OP clearly means "preprocessor", not "precompiler". You're right that preprocessing itself isn't slow, but the header/impl split can actually cause some slowness at build time.
Yes, popular programs behave correctly most of the time.
But "perfectly fine for the last two decades" would imply a far lower rate of CVEs and general reliability than we actually have in modern software.
I don't know, but I also don't know how much you think is "enough" to deal with project cultural issues. It sounds like it must be quite a bit?
First and foremost _____ is a giant hack to mitigate legacy mistakes.
Wow, every article on web technology should start this way. And lots of non-web technologies, too.
Take a step back and look at the pile of overengineered yet underthought, inefficient, insecure and complicated crap that we call the modern web....
Think about how many indirections and half-baked abstraction layers are between your code and what actually gets executed.
Think about that, and then...what, exactly? As a website author, you don't control the browser. You don't control the web standards.
I'm extremely sympathetic to this way of thinking, because I completely agree. The web is crap, and we shouldn't be complacent about that. But if you are actually in the position of building or maintaining a website (or any other piece of software), then you need to build on what already exists, unless you're in the exceedingly rare position of being able to near-unilaterally make changes to an existing platform (as Google does with Chrome, or Microsoft and Apple do with their OSes) or to throw out a huge amount of standard infrastructure and start as close to "scratch" as possible (e.g. GNU Hurd, Mill Computing, Oxide, Redox OS, etc; note that several of these are hobby projects not yet ready for "serious" use).
If you think anything in software has worked "perfectly fine for the past two decades", you're probably not looking closely enough.
I exaggerate, but honestly, not much.
Do you mean moonshine_save? Does it even provide an API for loading that doesn't return a Result with a possible LoadError?
Rust doesn't generally "throw" errors, it returns them; and generally, function APIs will guide you in the right direction. You generally should not use unwrap() or expect() in your finished code (though the unwrap_or... variants are fine), which means that you must handle all errors the API can return programmatically (possibly just by propagating with ?, if you will instead be handling the error in the caller).
See also Asahi Lina's thread on this, which explicitly says that Rust is one reason why their drivers cause fewer kernel panics than others: https://vt.social/@lina/113045456734886438
Isn't your objection there basically "LF doesn't pay enough for people to put up with negative social dynamics"? In which case, wouldn't paying more help a lot?
I asked, and it's to replace some of the bits that require Perl: https://hachyderm.io/@notgull/113035157972265244
You can see the full (current) sequence here: https://bootstrapping.miraheze.org/wiki/Live-bootstrap
Slow compared to just chucking everything into a single source file, actually: https://github.com/j-jorge/unity-build
That's only true for clean builds and even then isn't universally true, and of course there are other reasons not to do unity builds. But the existence of the technique, and the fact that historically it has sped up build times enough for various projects to adopt it, does show that the C++ model, with headers and separate compilation units, has some inherent inefficiency.