Hacker News new | ask | show | jobs
by shizcakes 1004 days ago
I feel that you've ignored all the reasons why folks feel that Go is more reliable and faster than Java.

Fighting with the JVM - even in modern versions - is an absolute pain. The practical reality of using _any_ JVM language is wasted memory footprint, classpath issues, weird dependency graphs because a mega-apache-project was used to solve a simple problem, etc. Never mind getting basic things like RPC clients over TLS (fighting with openssl and keystores? in 2023? really?) working.

> my real point was Java is easily faster and more reliable than Go and it seems pretty insane to reach the opposite conclusion

Citation needed. Disagree in practical observation.
2 comments
pjmlp 1004 days ago
As if there aren't plenty of blogs about fighting Go runtime, some of them giving up, and doing rewrites in C++ and Rust.

https://discord.com/blog/why-discord-is-switching-from-go-to...

link
jpgvm 1004 days ago
Oh I am well aware of Java's warts and you hit a few of them but they are clearly -not- performance or reliability.

Yes there are lots of things that suck about Java and the JVM but you can't in good faith argue that it's slow and unreliable.

link
smitty1e 1004 days ago
Once it hits full stride, sure. While not a Java dev, I work with plenty of Java enterprise systems (looking at you, ElasticSearch, and probably big chunks of AWS).

One appreciates the engineering durability of it all.

I do refer to the healthy startup time for the cluster as the "Java pause".

Perhaps that's a cheap shot, blaming the language, given that we're getting rich logging and a predictable approach that makes things boring in a good way, but there you have it.

link
jpgvm 1004 days ago
Yeah the JVM definitely makes tradeoffs that adversely affect startup time, things like autowiring DI, etc all contribute to this - it's not just the runtime. It can be slightly annoying so periodically effort is invested to make it fast again, see recent Spring Boot startup speeds which are pretty damn quick now but can be made super fast with static wiring. (all without needing to resort to CRaC or AoT)

I was really getting at the fact that you can't reasonably call something unreliable or slow when it's probably powering some of your most loved (and performant) distributed systems that your applications rely on - doubly so if you are running on AWS or GCP. If it was either unreliable or slow, let alone both it wouldn't be fit for purpose.

link