Finally a reason for me to consider using Go vs Java.
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.
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 [1] https://github.com/java-native-access/jna/blob/master/www/Ge... [1] http://openjdk.java.net/projects/panama/
Excellent point. This doesn't seem to be brought up very often (or at least it's rarely emphasized) in Java/Go comparisons.
[0] https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc... [1] https://www.azul.com/products/zing/pgc/
It's probably also be less CPU-efficient than azul's, since it uses forwarding pointers instead of page table trickery. But if you have such a large heap you'll also have many cores. Here's a performance comparison to G1[1].
[0] http://openjdk.java.net/jeps/189 [1] https://rkennke.wordpress.com/
>Java creates a lot more garbage.
Very true, Go is great about keeping things on the stack.
Also sync.Pool helps a lot when used as needed.
For example, there's a mess of different error handling techniques (e.g. err == io.EOF vs os.IsNotExist(err) vs perr, ok := err.(*os.PathError); ok).
This also prevents the language from evolving, as can be seen in the case of the context package (see 'Frozen' in this post https://github.com/golang/go/issues/14660#issue-138695431 )
While the above poster didn't explain his problem clearly, it is a valid complaint.
Example of one of them: https://play.golang.org/p/pku8VJteH1
That stupid issue means that packages like os return 'error' even if it will always be of type '*PathError' so you have to be careful to note if the package you're using screwed up in returning err structs or not when doing `if err != nil` or else you'll check a nil interface vs a nil struct... not what you want. This hinders the ability to make richer error types somewhat. In addition, it means you have to always read the docs because the type system cannot represent the possible errors you can get there safely.
Second, this is bad because of places in the language (like io.Reader.Read) where it returns two values (numRead, err) where both are useful.
Due to the lack of sum types, you can't actually tell in multiple-returns of errors whether the results are mutually exclusive or not. What's more, without sum types, there's no way to express to the type system correctly that you indeed are in a non-nil branch of a value or so on.
Finally, there's no macros or other ways in the language to have more expressive error checking than the brain-dead "if err != nil". Sure, what go has is better than java's terrible implementation of exceptions, but it's so much worse than what you get in rust or ocaml or so on.
"It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. At some indefinite point, a Go 2 specification may arise, but until that time, Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.)."
Granted that means it is effectively a freeze on backwards incompatible changes, but it does leave the door open for additions to the language.
Having said that, the go authors are definitely very conservative with language changes.
"Not everything was fixed, though. We're still learning (but the language is frozen for now). "