3 ms·

Will this open the door to utilizing Java libraries from within go apps? Coming soon: scala.go (!)

mike_hearn 12y ago
No - for that you'd need a Go implementation on the JVM. Last time I checked there was a half finished student project that does this. But not a full implementation. That's a shame. I've encountered a Go shop that was really suffering from things as basic as "our best debugger is gdb which doesn't really work" and "how do we get a stack trace from our running program?". The Go crowd like to talk about how Go programs are small and standalone, but obviously the HotSpot JVM is not just a big pile of NOPs. You can get very small implementations of Java too, but only by cutting lots of useful functionality. I bet if a company produced a solid, compliant Go for the JVM, that'd be a license to print money. I feel like lots of startups are coding themselves into a corner by relying on the relatively new and simple Go runtime. If they could bring their code across to the JVM and get access to all the useful tools it has, that'd be worth some money.
- bkeroack 12y ago
  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. Luckily it's being worked on (https://github.com/derekparker/delve https://github.com/derekparker/delve).
  - 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.

No - for that you'd need a Go implementation on the JVM. Last time I checked there was a half finished student project that does this. But not a full implementation. That's a shame. I've encountered a Go shop that was really suffering from things as basic as "our best debugger is gdb which doesn't really work" and "how do we get a stack trace from our running program?". The Go crowd like to talk about how Go programs are small and standalone, but obviously the HotSpot JVM is not just a big pile of NOPs. You can get very small implementations of Java too, but only by cutting lots of useful functionality. I bet if a company produced a solid, compliant Go for the JVM, that'd be a license to print money. I feel like lots of startups are coding themselves into a corner by relying on the relatively new and simple Go runtime. If they could bring their code across to the JVM and get access to all the useful tools it has, that'd be worth some money.

bkeroack 12y ago
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. Luckily it's being worked on (https://github.com/derekparker/delve https://github.com/derekparker/delve).
- 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.