4 ms·

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 mu

by eklavya 19d ago

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

ndriscoll 19d ago
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.
jeffbee 19d ago
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.
- eklavya 19d ago
  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.
gf000 19d ago
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?
- eklavya 18d ago
  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.

by eklavya 19d ago

ndriscoll 19d ago

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.

jeffbee 19d ago

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.

eklavya 19d ago
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.

gf000 19d ago

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?

eklavya 18d ago
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.