Hacker News Reader

Comment by Xeoncross | Hacker News Reader

1) for one-off scripts and 2) If you ignore memory.

You can make about anything faster if you provide more memory to store data in more optimized formats. That doesn't make them faster.

Part of the problem is that Java in the real world requires an unreasonable number of classes and 3rd party libraries. Even for basic stuff like JSON marshaling. The Java stdlib is just not very useful.

Between these two points, all my production Java systems easily use 8x more memory and still barely match the performance of my Go systems.

View on HN

I genuinely can’t think of anything the Java standard library is missing, apart from a json parser which is being added.

It’s your preference to prefer one over the other, I prefer Java’s standard library because atleast it has a generic Set data structure in it and C#’s standard library does have a JSON parser.

I don’t think discussions about what is in the standard library really refutes anything about Go being within the same performance profile though.

Memory is the most common tradeoff engineers make for better performance. You can trivially do so yourself with java, feel free to cut down the heap size and Java's GC will happily chug along 10-100 times as often without a second thought, they are beasts. The important metric is that Java's GC will be able to keep up with most workloads, and it won't needlessly block user threads from doing their work. Also, not running the GC as often makes Java use surprisingly small amounts of energy.

As for the stdlib, Go's is certainly impressive but come on, I wouldn't even say that in general case Java's standard library is smaller. It just so happens that Go was developed with the web in mind almost exclusively, while Java has a wider scope. Nonetheless, the Java standard library is certainly among the bests in richness.

ZGC? It should be on par or better than Go.

Java’s collectors vastly outperform Go’s. Look at the Debian binary tree benchmarks [0]. Go just uses less memory because it’s AOT compiled from the start and Java’s strategy up until recently is to never return memory to the OS. Java programs are typically on servers where it’s the only application running.

[0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Also -- Java versus Java native-image

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

IIRC the native image GC is still the serial GC by default. Which would probably perform the worst out of all the available GCs.

I know on HotSpot they’re planning to make G1 the default for every situation. Even where it would previously choose the serial GC.

Reply on news.ycombinator.com