3 ms·

Go on the JVM completely defeats one of the biggest Go selling points for me: compilation to native code. Debuggers are definitely a weak spot, though, I agree

• mike_hearn 12y ago
  What precise benefits do you look for? Bear in mind "compile to native code" is a bit vague. JVMs compile bytecodes to native code too, they just do it on the fly instead of ahead of time. If you mean "single executable" then there are ways to do that with Java too, check out the downloadable demos on the Avian website. But many native apps are not single files and have lots of libraries they depend on, so the distinction there isn't obvious either.
  • bkeroack 12y ago
    One of the hats I wear is "DevOps"/"SRE" (among other things). To me the JVM is another big layer of complexity between the code and the hardware it runs on that makes debugging and performance analysis that much more complicated. Granted, it also brings tools to the table (JMX, etc). However given the choice I'll nearly always pick an application that compiles directly to a native machine code binary. It's ironic to me that the JVM was conceived as a portability panacea ("write once, run anywhere") yet outside of mobile virtually everything runs on x86(-64). So with the JVM we have this thick, unnecessary VM layer that penalizes (in terms of performance and complexity) all code running on it. The fact that Go programs are all statically-linked (easy deployment, no weird dependency issues) and are reasonably safe given idiomatic coding patterns are nice bonuses.