[jibal]

And that is grossly dishonest ... my original comment said nothing about what is true for me, and I never assumed (or assume) that what is true of me is true of others. In fact the whole point of my comment that you are responding to here is that I don't think that what is true of me is true of you--you are clearly better at these things than I. You are just being pointlessly and ungraciously belligerent. It's a hell of a way to treat consumers and admirers.

> zsf team is perfectly capable of implementing compiler optimizations.

Again with that strawman. The issue was about duplicating the years of effort put into LLVM. No doubt with ENOUGH effort that can be duplicated--logic dictates that ... but then it has to be continuously tracked. And when I said "recreate comparable", there is of course an implied time scale.

You're all in a huff because I used the word "naive". But then you made an argument that your naivety gets the damn thing done anyway because of will power, work ethic, etc. I grant that it's a good argument with results to prove it.

Enough ... I won't be provoked into responding again.

[0x000xca0xfe]

I think you are overestimating the impact of the long tail of compiler optimizations. You don't need to reverse-engineer every microarchitecture under the sun and optimize for their specific quirks like LLVM does to have useful code generation.

Just doing the basics goes a long way with a tiny fraction of the effort. Yes it will leave some percent on the table but this is hardly the end of the world. With their own compiler they have full control over the entire chain and might be able to make up for that with their own language-specific optimizations.

Go has a custom compiler, too, it's not as good as LLVM, so what?