Then if you take into account the fact that Go's language features do not promote highly-performant code (GC, heap allocation, dynamic dispatching) that a few people in this thread has touched on.
While better looking code is highly subjective, Rust has indeed traded off some aesthetics for safety, performance, etc... However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust.
For a given piece of code as written today, its compilation speed will naturally improve over time as processors get faster. Optimizing it to a certain degree becomes faster for the same reason. Therefore, assuming a fixed threshold for what constitutes "fast [enough] compilation", potential for more optimizations becomes available over time.
> However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust.
That's true for many languages, including PHP or Perl. The problem is: once you use these languages more, you discover that most people don't do it (for various reasons, one of them often being that they're trying to be clever).
Go has a better syntax that rust, objectively, because it refuses to create new operators that are not orthogonal to existing ones. That makes it easier to parse because there are fewer 'code synonyms' (eg. the rust Fn<(Arg1, Arg2), (Rtn)> is identical to Fn<Args, Arg2> -> Rtn; to be fair go has its share of these irritations as well; eg. x := 1, vs var x = 1; but fewer of them)
It's got nothing to do with how pretty or ugly the code is.
Also what is stopping a LLVM backend for Go being developed?