None of these are arguments against LLVM or a virtual machine, they're just implementation details of Java.
You are underestimating the impact of that choice on language design. When Java was designed, garbage collection was one of the major features, and almost all languages with GC were either interpreted or using a VM. Static native binaries with GC and goroutines is something relatively unusual in the design space. I can think of OCaml and Haskell doing something similar for example.
Common Lisp, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Eiffel, Objective Caml, Standard ML, Haskell, Dylan, Sather, Mesa/Cedar, BETA.
All were able to AOT compile to pure sugar free native code, with various forms of GC support.
Re:Go is boring, and that’s fantastic
by moreaccountspls on Thursday July 02, 2020 @04:12PM
(#23717485)
Sure, and if the moon was made of cheese, it would still be a sphere lighting up the night sky.
The fact that the go designers prioritize things like statically compiled binaries is the whole magic of Go in the first place. The language is whatever, it's fine, it's cool. But like the article says, the magic is in its holistic attitude towards process, tooling, and distribution.
> How is this any kind of pro or con? It's just an implementation detail.
This is actually one of my favorite things about Go. The fact that you get a single statically-linked binary at the end is so much nicer than having to mess around with JVMs and JAR files and CLASSPATHs. Sure, there's a lot of tooling to handle this in the Java world, but it adds significant complexity, and makes life difficult when you need to do something slightly different.