←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 5 comments | 18 Feb 25 16:55 UTC | HN request time: 0.213s | source
Show context
pseudoramble ◴[18 Feb 25 22:58 UTC] No.43096211[source]▶
I’ve been out of the Java scene for a really long time, but will be coming back to it soon. I’m curious - these performance issues described here, are they inherit to how Java itself? Is it baggage from Spring/Boot? Are there ways to get more bang for the buck with some careful choices in a system like this?

The closest I’ve done to Java recently is C#, which I think may have similar challenges, but overall didn’t seem quite as bad if you avoided lots of framework extras. It also wasn’t something I was digging into deeply though, so perhaps I’m mistaken.

replies(6): >>43096295 #>>43096314 #>>43096318 #>>43096420 #>>43096427 #>>43100389 #
1. tomohawk ◴[18 Feb 25 23:23 UTC] No.43096427[source]▶
Having done a lot of Java and Go, Go has much better mechanical sympathy between the language, libraries, and vm than Java does. The JIT GC in Java are marvels of engineering, but they have to be.

As an example, in Java, everything is a pointer, so pointer chasing all the time, which is not good for cpu cache, etc. In Go, there is first class support for composition.

The other main adjustment, if coming from Java, is reduced cognitive overhead. It usually only takes a week or two for an experienced Java dev to be reasonably effective in Go, but it takes a few months to break the mental habits of overthinking everything.

replies(2): >>43097777 #>>43098602 #
2. codr7 ◴[19 Feb 25 02:13 UTC] No.43097777[source]▶
There's nothing forcing you to write EE style code in Java though, or depend on frameworks written in that style.
3. re-thc ◴[19 Feb 25 04:32 UTC] No.43098602[source]▶
> As an example, in Java, everything is a pointer, so pointer chasing all the time, which is not good for cpu cache, etc

Strictly speaking that's not true. It's everything is a pointer in theory to make it easier to reason with and JIT / JVM optimizing in the background.

There are primitive types and there are lots of tricks in the JVM e.g. escape analysis that places objects on the heap/stack etc.

replies(1): >>43100250 #
4. PhilipRoman ◴[19 Feb 25 09:23 UTC] No.43100250[source]▶
Despite all the advances in JIT, I've literally never seen it correctly optimize a HashMap<Integer> (happy to be proven wrong). Hopefully the renewed focus on value types can finally bring some sanity.
replies(1): >>43100317 #
5. neonsunset ◴[19 Feb 25 09:34 UTC] No.43100317{3}[source]▶
In C#, all struct generics are monomorphized and struct-based abstractions are zero-cost :)