[pron]

> Similar performance to Java but with much less code, better interoperability, and a more robust standard library.

I disagree on all points.

1. The similar performance to Java is usually in small benchmarks. Once the program grows, the difference in quality of the GC and code generation starts to show (in favor of Java, of course).

2. Less code? I've seen Go programs in the wild that are indeed shorter than their Java counterparts, but that's almost invariably because the Go code is less "careful" (less attention to error handling, logging, monitoring, maintainability etc.) But when you compare programs that actually do the same thing, I find that the code size is similar, with Go winning fewer characters and Java 8 fewer lines.

3. Interoperability is, IMO, much better in Java, where you can interoperate with both C as well as JVM languages (including JVM ports of Python, Ruby and R); for Go it's just C.

4. As to the standard library -- especially when it comes to concurrent data structures -- there are few if any languages out there with implementations of as high a quality as Java, and the difference between the variety and quality of available third-party libraries is beyond comparison.

All in all, I find Go and Java to be quite similar, and the choice between them boils down to the runtime. I reach for Go when I need small command-line programs where JVM warmup is unacceptable and static linking to a native executable is a plus, and Java for long-running, "important" server apps, where top performance and deep monitoring (and sometimes hot code swapping) are necessary.

[fauigerzigerk]

I agree that Go and Java are very similar indeed. Without goroutines, Go would be little more than a rewind of Java to a moment before J2EE happened. A major motivation for both languages was to take dangerous weapons out of the hands of mediocre programmers (or programmers made mediocre by being forced into large and ever changing teams).

But I have to disagree on performance. What kills Java performance is memory consumption and the way memory is laid out. It has always been the number one killer. It killed Applets. It killed Java on the desktop. And it makes Java a bad choice for most server side infrastructure. I predict that Go is going to wipe out Java for that latter kind of task within 5 years if not less.

Memory consumption is what constrains performance for most tasks. That's why most benchmarks are entirely irrelevant.

Java's creators made two huge mistakes:

1) Throwing out structured value types, which is the root cause for Java's insatiable appetite for memory. 20 years of garbage collection research were unable to compensate for the damage done by not having structured value types.

2) Throwing out so many (supposedly too complex and too dangerous) meta programming features that everything meta had to be built around the language. Trading complexity at the language level for a much more unsound form of complexity on the runtime and tooling side is what caused the J2EE disaster.

Go's creators avoided the first mistake but they are busy repeating the second one with even greater determination.

[pron]

I disagree with your analysis. Value types are being added (that's what the HotSpot team is busy working on) with relatively precise control over memory layout, and their negative impact only became clear when random memory access became more expensive (in relative terms). Still, Java performance isn't "killed" for the simple reason it handily beats Go, and often enough beats C++ in large, multithreaded programs. So if this is what Java performance looks like when it's "killed" by lack of value types, I'm very hopeful at the prospect of adding them, because Java will have no competition then, let alone Go, which lags behind even now. Large, big-data analytics software (like H2O) written in Java achieves 100% of maximum hardware performance ("Fortran speed"). The trend is that more and more performance-sensitive applications are transitioning from C++ to Java. Also, Quasar adds true fibers ("goroutines") to Java.

Now, I don't know exactly what you mean by memory consumption, but if you mean total memory consumption by the JVM, that's a feature of the GC chosen, which usually trades extra RAM for added performance -- it certainly does not negatively affects performance.

As to point 2, I think that was Java's greatest decision (which Go can't replicate), because the malleability of bytecode afforded by class loaders and agents have made the JVM extremely flexible while at the same time extremely performant. At the language level, annotation processors -- really, AST transformers -- are extremely powerful (see the new pluggable type systems for Java 8) and not easy enough to abuse by under-qualified developers. If you want a more powerful language, the JVM offers quite a wide selection, which is another thing Go cannot do.

[vinceyuan]

I didn't choose Java for my backend just because it uses too much RAM. The VPS(s) with large RAM are expensive.

[pron]

Then assign the JVM less RAM and suffer worse performance -- it's often a simple tradeoff you can make when launching the app. It would still likely be faster than most other choices (certainly all other GCed environments).

[vardump]

Did that (reduce heap size), ended up having 30 minute GC loops. Implementation in another <unnamed, new> language decreased memory usage rather radically.

Well, I guess I could have also done Structure of Arrays implementation and additionally avoided 'new', but it's not Java anymore at that point, is it? Easier to just write it in another language at that point.

Generic branchy business logic type code is indeed about as fast in C++ as in Java. But that doesn't hold for all types of software.

How fast is Java native floating point math vs. C++/intrinsics? Last I checked, C++/intrinsics seemed to have 2-8x lead. What about sorting? Last I checked C++/intrinsics sort seemed to be about 20-50x faster versus Java.

Some comparison:

http://unriskinsight.blogspot.com/2014/06/fast-functional-go...

[pjmlp]

Fully agree with 1), specially if you look at some alternatives back when Java appeared into the scene:

- Oberon

- Oberon-2

- Active Oberon

- Component Pascal

- Modula-3

All with GC, value types, generics (just Modula-3), system programming capabilities and compilation to native code in their reference toolchain (Oberon variants also had JITs).

But now we have Java, with large installed bases, very mature tools, and latest by Java 10 that mistake might be fixed.