[azth]

Java (and C# I believe) can also compile to binaries. And golang has a runtime as well.

Now what is the advantage again? The Java can compile to JVM bytecode and be better performing than golang, all while having superior introspection and monitoring and debugging abilities. It seems to be a win-win. Only some ideological "closer to the metal" philosophy doesn't apply, so what?

If startup times are truly an issue, look at Quarkus[1] and Micronaut[2], and a lot of other frameworks that use GraalVM to compile to native binaries.

[1] https://quarkus.io/ [2] https://micronaut.io/

[brabel]

I am mostly a Java guy, but when people claim that Java can also compile to binaries, I really don't like that.

It's kind of true... but with so many caveats it's almost a lie.

* it compiles so slowly even basic applications can take 10 minutes to compile. What the hell are they doing all that time?!? Go can compile to multiple OSs architectures on the same machine and it takes a couple of seconds even for large code bases!!

* you can't use most of the Java ecosystem as reflection is endemic... good luck manually declaring everywhere reflection will be used.

* the loss of the JIT hurts peak Java performance a lot. Java runs as fast as Go *once the JVM is warmed up*! Native-image peak performance tends to be some way behind.

Not saying GraalVM native-image is useless, it can be used if you have the energy and knowledge to get past the issues... but as someone who konws Go as well as Java, if I am going to the trouble of going native, I'd just use Go without a doubt.

[cle]

Also good luck if you need to cross-compile. The Go toolchain for that is seamless, Graal’s is non-existent (because it is fundamentally incompatible with the way native image compilation works).

[pjmlp]

If you are cross compiling while using Java, you really don't get Java.

[cle]

If you are building and distributing executables using Graal native-image, you probably care about cross-compilation.

[pjmlp]

Which is an very good example of not understanding what Java is all about.

[cle]

Can you please just say what you mean instead of posting vague, shallow dismissals?

[pjmlp]

So you are a Java guy and are only aware of GraalVM, while ignoring all the AOT commercial offerings since 2000?

ExcelsiorJET, J/Rockit, Websphere Real Time, PTC or Aicas aren't GraalVM.

Also if you don't want to lose JIT, while having the advantage of AOT compilation, JIT caches are a thing, nowadays available for free on OpenJDK, OpenJ9 and Android (even though it isn't proper Java).

[brabel]

I've been working with Java since 2009 only... those things you mention have never been used anywhere I've seen since then (but yes, I heard of them as things of the distant past that no one used).

[sblom]

No one insulted Java. Why so defensive?

Go and Java make different tradeoffs. If you're unreasonably effective in Java and its tradeoffs work for you, that's completely fine. If you have good tools that make Java more like Go when you need Go-like characteristics, that's cool too.

[azth]

I'm pointing out the inconsistencies in golang fans arguments which I've seen from the very beginning since it was touted as a "systems programming language" (which has been more or less silently changed since it wasn't true, but it doesn't stop the fans from parroting it). Same goes with many other false claims about the language, which aren't just non demonstrable, but demonstrably false.

[geodel]

Relax. Many people would call Docker/Kubernetes, and various types of databases like CockroachDB as systems. Lot of enterprises call large internal applications as "systems" There is no copyright on "systems programing" and it can be used only for OS kernels and such.

[codeflo]

While I agree it's probably not worth getting angry about, I would agree with the GP that the word "systems programming" traditionally has a meaning that's different from "programming things that might be called systems". What you're describing is often more simply called "backend programming".

[azth]

In that case, Python is also a "systems language", but you don't see people claiming it as such.

[geodel]

Then go ahead and do it. Who knows, it could dissipate a lot of your pent up anger.

[azth]

You can stop with the odhominem

[Thaxll]

Java does not perform better than Go, they're pretty much on par but I would say that overall Go is faster. As for the tooling that Java has those it's because the language and runtime or so complicated with many layer of abstraction that you need those.

Go has pretty good introspection with pprof it's enough, you don't need something heavy like JFR. For debugging delv is ok, not on part with C++/ Java but it's fine, you can even do remote debugging now.

The thing is with Java and to some extend C#, yes they have different runtimes, VM, AOT / JIT etc .. different thing to compile to native binary: none of them are really mature atm and moreover it's even more complexity for the programmer, now he has to choose which runtime or compiler he's going to use, it's crazyness. Same story with the GC Java offers, too much choice, too much burden on the programmer. For app A you're going to use this GC + runtime, app B is going to be different, it really mess up the dev / ops process.

[azth]

> Java does not perform better than Go, they're pretty much on par but I would say that overall Go is faster.

Real world programs disagree. And for any large program, the JVM is a superior optimizer than golang's compiler.

> As for the tooling that Java has those it's because the language and runtime or so complicated with many layer of abstraction that you need those.

I heavily disagree. I deployed services both in golang and Java/JVM languages, and simplicity of the language or runtime has nothing to do with the JVM having superior observability and monitoring.

> you don't need something heavy like JFR

I wonder why my employer is spending millions of dollars on dev salaries to build something not even remotely comparable to the JFR for their golang programs then.

Secondly, the JFR is extremely light weight, and gives you < 1% overhead at runtime. Show me another ecosystem that gives you this out of the box.

> Same story with the GC Java offers, too much choice, too much burden on the programmer.

It doesn't really. The newer GCs have very few knobs to turn. Compare to when you hit GC issues in golang, the solution is to rewrite code in nonidiomatic ways as we saw with Discord. The first approach is superior.

[bberrry]

I urge you to look into Javas new ZGC. It's a massive achievement, having only <1ms pauses even on TB sized heaps. Go:s GC can't hold a candle to it in terms of low consistent latency.

[dragonwriter]

> As for the tooling that Java has those it's because the language and runtime or so complicated with many layer of abstraction that you need those.

Sure, Java has much more need of dev tooling than Go. But the available dev tooling on Java being enough better than the Go tooling to make the language + tooling have a better DX can still (if that is one's experience) be a valid advantage, for anyone not working in an artificially constrained environment where they are forced to code with Notepad and no tooling.

[fourseventy]

99% of people run Java on the JVM. Just because you 'can' compile java to native code doesn't mean it really applies in real world situations. Plus as far as I can tell the only compiler that can compile Java to native code (GCJ) is no longer maintained.

[pjmlp]

PTC, Aicas, WebSphere Real Time, GraalVM, OpenJ9.

Additionally, JIT caches are now part of OpenJDK, OpenJ9 and ART.

[marwis]

Nowadays people use GraalVM Native image for AOT compilation.

[k__]

It's true. Go is basically Java/C# with its runtime baked into the binary. Also, it's only marginally faster than Java.

I never understood Go. I was sold as the C killer and failed, now it's basically an alternative to Erlang/Elixir, but suddenly people started running around and saying "Noooo, it was never meant to be a systems programming language like C!!!"

[azth]

golang is not marginally faster than Java however in the real world.