Hacker News Reader

Comment by eklavya | Hacker News Reader

I ported a moderate sized java project to golang. Test suite runs order of magnitude faster now. There isn't much change in terms of the architecture. Pretty much the same algos and data structures. The whole dev tooling runs on a 16 gb mac without swapping now. I used vs code for both

View on HN

IME they're both in a place where Rust is maybe ~40% faster for a decent CRUD web application server, but with go you need to write much lower level code to get there (e.g. using composable generic iterators will ruin your allocations, so it's all manual for loops). You can write idiomatic high level Scala and get the same performance. Which could be as simple as the go compiler offers no ability to force inlining and has way too low of a complexity threshold, but that basically makes reusable code unusable in high performance situations.

The whole go team's philosophy tends to also revolve around assuming their users don't know what they're doing, which is annoying. Like an inline keyword: thinking you know better than me doesn't mean I'm not going to inline it; it means I'm going to manually write it inline myself in the code, and then think the language sucks because it's tedious, error-prone, and verbose. Or they tend to mark lots of stuff private for no reason, and e.g. with TLS 1.3 they just ignore your config because they think they know better, etc.

Isn't this mostly about java cold start costs? It might be that other people are optimizing for steady-state performance, not transient startup performance.

One particular test was running for 20 minutes, doing repetitive calculations, hopefully enough to get jitted. It finishes much much faster now. I could have profiled to check what was going on but the test was simple and the dev tooling and the ram usage was a major concern for me. Also gradle upgrades were painful.

Java tooling taking up a lot of ram was a major motivation for me. I have done a lot of Scala as well. I don't think either Java or Scala in the real world beat go on performance for most cases. I don't doubt that in some cases jvm can do better but at least before Valhalla delivers all the promises, in real world, I am doubtful.

I have been a Java/Scala user almost for the majority of my career. I doubt I would pick jvm over golang going forward though. Also not having to deal with OOP is a plus.

And if you ported that golang to Java you would almost certainly have seen that same speedup.

Absolutely not, I am not an amateur. Forget about the codebase, I am sure you won't claim that the dev tooling for Java is lighter than golang.

From real world experience, the JVM does a superior job at optimization and has superior GCs compared to golang.

Not sure which dev tools specifically you're referring to.

So you compare the build tool of A and B on a short-lived job type where java is knowingly not its strongest? How is that a meaningful comparison?

I am not sure I understand your point. It's a meaningful comparison based on my situation. But even if it isn't, what are you arguing for? I change my use case rather than the tool/lang? Sorry if I misunderstood.

Reply on news.ycombinator.com