Exactly, the propping up of Go seems unfounded. Java in it's newest iterations make it more compelling as a target, and people, especially young people, overlook it because of its stigma as enterprise cruft.
But still nobody wants to use it given the choice, because it sucks. 75% of the code you write is boilerplate mainly thanks to OOP, the com.foo.bar stuff is an eyesore, and it somehow uses even more RAM than Python. That's without getting into the enterprise cruft land where each method has 3 annotations on it, where the annotations themselves are maintained by an entire outsourced team.
75% boilerplate, come on. It has records and pattern matching now. Many of the cases of boilerplate are strictly self inflicted. And this criticism is absolutely laughable in a thread about Go, where you have to repeat some error ritual every 3 lines, losing the signal in all the noise. Java is a much more concise language than Go.
com.foo.bar solves a very real issue that is a big problem in e.g. the Node and Rust ecosystem (package name squatting).
And it uses as much RAM as you set it to use. It's true of every managed language that more memory equals less work to do, that is better throughput. But Java's GCs are the state of the art, it will work just fine with half the pre-configured memory.
The Go error handling is bad enough that it makes the lang not a top choice for me. Seems like entire vision of Go was being the opposite of C++ in every way, and that resulted in something halfway decent, but it unfortunately doesn't use exceptions. You get stuff done in fewer loc than in Java at least, and it always had solid m:n greenthreading, and the GC just works without having to tune it.
Come on, java starts up fast enough and the memory usage can be set (better throughput vs less memory, it's a classic tradeoff. Go just defaults to worse throughput).
Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly.
Yeah it can be adjusted, on the other hand you have a language that just works. Starts instantly and memory usage is bounded by usage, not guesstimate of how much the JVM will need.
> Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly
Have you many java projects that didn't use some fat framework? Good for you if you did, but 100% of java project I had the displeasure of touching were huge mess with deprecated frameworks on ancient java versions.
And it's not really a VM in that sense of the word. It's a runtime, Go also has such a runtime it's just bundled.