[melling]

I was always under the impression that Go never had a great optimizing compiler. It was never a primary focus given the limited developer resources.

I couldn’t find a direct C# to Rust comparison but Rust trying to compete with C++ means performance is a goal, if that’s what you are after.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[throwaway894345]

I don't think it was "limited developer resources" so much as a desire to preserve blazing-fast compile times. The very rough rule-of-thumb that I've heard is that optimizations must pay for themselves (a compiler which is itself compiled with the given optimization must not be slower than the previous version).

[igouy]

"He used the compiler's self-compilation speed as a measure of the compiler's quality. Considering that Wirth's compilers were written in the languages they compiled, and that compilers are substantial and non-trivial pieces of software in their own right, this introduced a highly practical benchmarks that directly contested a compiler's complexity against its performance."

p44 "Oberon — The Overlooked Jewel" Michael Franz, in "The School of Niklaus Wirth".

https://www.google.com/books/edition/The_School_of_Niklaus_W...

[gwp]

> I was always under the impression that Go never had a great optimizing compiler. It was never a primary focus given the limited developer resources.

It's an intentional choice, that's why it compiles code so fast. Also because of that it's a lot simpler than say GCC. Before Go, the Plan 9 C compiler was designed in a similar manner too (I think the Go compiler was forked from it).

I think the simplicity aspect is even more important than the compiling speed. It's easier and cleaner to keep the compiler simple and write optimized assembly code by hand when it's needed. That way, the compiler doesn't get so messy (fewer bugs, easier to maintain...) and the written program is of better quality (humans can produce better code than compilers).

[kaba0]

How often have you met compiler bugs? Also, humans absolutely can’t produce better code than compilers, at least not reliably. All those minor improvements that compilers routinely do does add up. And noone wants to write arcane hacks that make code unmaintainable and may not even provide a performance benefit (CPUs are finicky beasts, sometimes the seemingly worth option is faster)

I very much want my computer to work as hard as it can to make my code more performant for free. What I would like to see more is a separate debug and release build mode, where the former can go as fast as it can without optimizations, while the latter can be as slow as it wants and result in the most optimal binary it can produce. Zig does that for example.

[the_duke]

There are both GCC [1] and LLVM [2] backends for Go, but I don't think they see much usage compared to the default.

[1] https://golang.org/doc/install/gccgo

[2] https://go.googlesource.com/gollvm/