4 ms·

The decision tree remains the same as before. Both systems have active runtime sub-systems, GC, scheduler, and a compiler front-end. Java, of course, has a vi

The decision tree remains the same as before. Both systems have active runtime sub-systems, GC, scheduler, and a compiler front-end. Java, of course, has a virtual machine and intermediate representation (byte codes), and a JIT to make it performant. The runtime class loading mechanism is a key +input here. The JIT aspect is a mix, with the -input being the upfront startup cost. Go has far better C linkage, access to underlying memory object image, and provides the (glaringly missing from JVM) unsigned integer types. Java has a more modern type system and first class metadata facilities, with -input being "more rope". Go has a 'interesting' type system, with -input being source level fragility, but +input here is "less rope". Having extensively worked with concurrent systems in both languages, the distinction ultimately boils down to a question of whether langauge level continuation (fiber/green) as provided by Go vs. library/ByteCodeEngineering (various Java libs) is a critical requirement. I honestly think it should be clear at this point that Go is really displacing Python and the notion of Go vs. Java is a false dichotomy.

the8472 10y ago
> Go has far better C linkage This is changing. There already are 3rd-party FFI libraries for java[0][1] which are far less cumbersome to use than JNI and in the future there will be Project Panama[2] which will provide that out of the box. [0] https://github.com/jnr/jnr-ffi https://github.com/jnr/jnr-ffi [1] https://github.com/java-native-access/jna/blob/master/www/GettingStarted.md https://github.com/java-native-access/jna/blob/master/www/Ge... [1] http://openjdk.java.net/projects/panama/ http://openjdk.java.net/projects/panama/
wheaties 10y ago
Go isn't displacing Python any more than Elixir is displacing Ruby.
- deleted 10y ago
  [deleted]
pjmlp 10y ago
Also the Go advantage regarding AOT compilation to native code only exists, if one ignores that the majority of commercial third party JVMs do have it as a feature.
weberc2 10y ago
> the distinction ultimately boils down to a question of whether langauge level continuation (fiber/green) as provided by Go vs. library/ByteCodeEngineering (various Java libs) is a critical requirement. Excellent point. This doesn't seem to be brought up very often (or at least it's rarely emphasized) in Java/Go comparisons.

the8472 10y ago

> Go has far better C linkage This is changing. There already are 3rd-party FFI libraries for java[0][1] which are far less cumbersome to use than JNI and in the future there will be Project Panama[2] which will provide that out of the box. [0] https://github.com/jnr/jnr-ffi https://github.com/jnr/jnr-ffi [1] https://github.com/java-native-access/jna/blob/master/www/GettingStarted.md https://github.com/java-native-access/jna/blob/master/www/Ge... [1] http://openjdk.java.net/projects/panama/ http://openjdk.java.net/projects/panama/

wheaties 10y ago

Go isn't displacing Python any more than Elixir is displacing Ruby.

deleted 10y ago
[deleted]

pjmlp 10y ago

Also the Go advantage regarding AOT compilation to native code only exists, if one ignores that the majority of commercial third party JVMs do have it as a feature.

weberc2 10y ago

> the distinction ultimately boils down to a question of whether langauge level continuation (fiber/green) as provided by Go vs. library/ByteCodeEngineering (various Java libs) is a critical requirement. Excellent point. This doesn't seem to be brought up very often (or at least it's rarely emphasized) in Java/Go comparisons.