> Leverage an already existing compiler backend, typically GCC or LLVM – just like Julia, Rust, or Swift. > > Or, similarly, target an existing, battle-tested VM – like e.g. Elixir, Kotlin, Clojure, or F#.

Each of these options come with enormous, unavoidable, and ultimately unnecessary baggage derived from their substantial histories. They simply don't, can't, represent the full spectrum of acceptable foundations for new language development.

GCC and LLVM both have terrible UX with their ridiculous compilation times. Go wanted good developer UX so that ruled those out.

None of those VMs would allow for the native compilation that was another design goal.

They had specific design goals which nothing out there met.

> GCC and LLVM both have terrible UX with their ridiculous compilation times.

And so will go if it implements the optimizations they implement. GCC and LLVM are not putting sleep(10) everywhere just for the sake of longer compilation times.

Then it won't do those optimizations. Fast compiler times are more important than being the fastest at runtime. It has to be "fast enough" and given the adoption I'd say the consensus is that it already is. More optimizations are all gravy at this point.

> Fast compiler times are more important than being the fastest at runtime.

For you, maybe.

If you need the fasted language why are you using Go?

I don't. I avoid Go like the plague. My point was that you don't get to unilaterally decide for everybody whether fast compile times or runtime performance is more important.