HendrikHensen
Joined 11 months ago
Joined 11 months ago
Sorry I have to defend my pride here a little bit. When I joined my previous company, the entire company was on Java 8. When I left every app in every team there was up-to-date on the latest LTS release at the time, 17. I assisted many teams in upgrading their Java, Spring, etc, and inspired even more.
I would argue that I'm one of the last people who you could blame for most companies being many Java versions behind...
That team was using Java 17. Java 21 was just released and frameworks had no meaningful support for virtual threads whatsoever.
In my experience, most companies using Java are chronically multiple versions behind (e.g. some of my friends still in the Java world are on 11).
Perhaps you can share some sources which prove that Java's performance blows Go out of the water without breaking a sweat? I have not seen any such articles about that in the past 3 years, besides the cherry-picked cases where the JVM JIT can optimize some small algorithmic part of the program on the fly (which is not relevant in most web applications).
I'm happy to stand corrected.
Edit: I found this one using a quick search myself https://medium.com/@mohnisha/java-vs-golang-performance-test... I'll check it out and see if I can reproduce it myself too. Still too bad about that gargantuan memory usage, but I guess memory in the cloud is cheap.
While I think this is a huge boon, have you ever published a package on the Maven Central repository? I must confess I haven't in a few years now, but when I did until ~3 years ago it was a major pain in the ass. And every release again.
I think there's something to say about Go's model where the package is just in some Git hosting and a release is just creating a tag. As a package maintainer, this is just pure bliss compared to the Maven thing.
> and really dislike the experience of trying to run a Go service compared to a JVM service.
What are you running into specifically? I have the complete opposite experience. With Go, 1 small binary comes out that I can run anywhere (and put into a distroless container), whereas with Java I have to find a way to somehow run a full JVM (most often with (large parts of) an OS too).
Perhaps you're alluding to the things you can do with JMX, but I have never really seen much benefit in that. I found it trivial to add similar functionalities with internal HTTP endpoints easily. But since I don't have much experience in this particular area, probably I'm missing something.
Also I don't understand "it's not trivial to grow them". It is trivial to grow them, and that's why Go went this way. Maybe only 0.1% or fewer of use-cases will ever find any issues with the resizing stack (in fact probably the majority of uses are fine within the default starting stack size).
Don't get me wrong, I like Java and don't very much like the Go language. But Java has a lot to improve upon still.
Do you have some sources or experiences to share on this topic? I'm very curious. My experience is the complete opposite.
At my previous job there was a Java web application and running in Kubernetes (1 vCPU and 1Gi of memory) was able to deal with at most 80 requests per second, using up almost the full 1 vCPU and ~600-700MiB of memory. That was a bit disappointing, since we were supposed to support at most ~1000rps on this API, 13+ pods is a lot, and we felt "software could do better".
A reactive guru from another team told us we should use a reactive stack, so he came in and rebuilt the app using the reactive stack. Now it was doing about 120rps on one pod (about the same memory usage), which was a good improvement, but still disappointing.
One guy on the team was motivated to rewrite the API in Go as a proof of concept, and we were blown away. With the same 1 vCPU it was now able to handle 400 requests per second, while using ~100-200MiB of memory, and having approximately 20% better response times.
> builds just as fast (at least when not using some popular build tools)
I find this a little bit of a cop-out, because almost everyone is using the popular build tools. And it's quite a chore to build a full application without those popular build tools. With Go, all batteries for building are included.
I don't understand what "industry purposes" means and in what aspects Java is better than Go in your opinion (I can think of some myself, but I'm interested in your perspective).