But the tools that are available to profile performance, memory etc on the JDK are wonderful.

It is much easier to reverse engineer compiled Java than Go.

Later

But see below, I think I misconstrued this comment.

I agree in general, but in this particular case (escape analysis [1]), you won't see what's happening in the ByteCode output. That being said, it's still very easy to see how the code will be JITed by running it through JMH (or just making sure it runs enough time to be optimized). The JVM and IDEs like IntelliJ contain tons of tools to review that.

To get back to the issue at hand, from my personal experience, if you have many small varibales, your app will perform better in Java than Go. The escape analysis in Java is probably more advanced than the one in Go, and in Java you could also use a generational GC if you prefer throughput to latency.

[1] To be more accurate, the actual optimization the JVM does is called Scalar Replacement, and it's not even about allocating variables on the stack, but rather about inlining primitives: https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacemen...

The argument above is being able to reverse engineer the machine code that will be executed by the processor. Java bytecode isn't that. That's why he said "the JIT adds a layer of mystery".

Ah, that makes sense.

I suspect parent may be better able to divine what the Go compiler intended by looking at the produced assembly, vs. knowing or predicting how the JVM will behave by looking at bytecode/decompiled Java code. Not that it is impossible, it's an additional skill that's bourne of familiarity with Hotspot/Graal/$JVM

It's awesome to see all this Java expertise on this thread but at its essence -- a jar file doesn't define the program that's going to run. It's the union of a jar and the JVM it runs on. With Go, the binary is the whole story.

So even if I can predict how a particular JVM will treat a given jar, I'm still stuck if my code might be deployed across a range of JVMs.

I say all this having written orders of magnitude more Go, with apologies to the Java programmers.

>So even if I can predict how a particular JVM will treat a given jar, I'm still stuck if my code might be deployed across a range of JVMs.

This seems like an odd objection to me. I'm not the biggest Java expert, and I don't currently use it professionally, but I've never written Java that was meant to run on a runtime I not only didn't control but did not know the version of. In theory this was supposed to be a big feature of Java, in practice the community is moving towards bundling the JVM when distributing apps, precisely because versioning is such a fiasco.

Why not just ask the current jvm what version it is and act accordingly? I mean surely you can advise the user / customer what JVM's your code is compatible with, which really translates to what JVM's you have tested your programming on, right?

I'm obviously surrounded by folks far smarter than me, so I'm posting something probably grossly uninformed to see what the experts think!

>Why not just ask the current jvm what version it is and act accordingly?

I would! That's more or less what I was saying. But earlier on in the life of Java, there were technologies like Web Start and applets that could be embedded in webpages and the idea was that they would run on the client much like JavaScript does today, and you would have little idea of what the client environment was like, other than "it's a JVM." That turned out to be a bad idea for a number of reasons, most famously security, and the situations in which you can't just bundle your JVM are dwindling.

Fair enough! Still, I'm thinking many javascript pages query to find out the browser environment and also act accordingly. I do agree with the security complaint, however I also like web apps.

I do think that you are sort of implying that web applets can't determine which jvm they're running under, is this really the case? Was there any reason that the java webapp folks prevented the applet from inquiring of the java version?

This page chats about the version stuff for applets, it seems even with applets there was some options for picking the java version:

https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...

You've made a nice argument for bundling the jvm so maybe I should change my inclination there, especially since I do like avoiding depencencies.

> I do agree with the security complaint, however I also like web apps.

Java applets are basically dead at this point, it’s all JS.

> I do think that you are sort of implying that web applets can't determine which jvm they're running under, is this really the case? Was there any reason that the java webapp folks prevented the applet from inquiring of the java version?

I never wrote applets but the point I was trying to make is that your environment is fundamentally unknown in that context. You could query for different versions and so on, but you would probably never know for sure because you don’t control the runtime environment (everything from the JVM down to the OS). This was supposed to be a big selling point of Java and it has for the most part turned out to be more trouble than it’s worth. That’s all.

>... a jar file doesn't define the program that's going to run. It's the union of a jar and the JVM it runs on. With Go, the binary is the whole story.

I was saying the same thing - albeit poorly perhaps. I'm no Java expert either, but once had to download 'jad' off sourceforge to decompile a buggy 3rd party lib :-).

> I'm still stuck if my code might be deployed across a range of JVMs.

Modern Java is meant to be packaged with the JVM via jpackage. You will know exactly what you're running on.