←back to thread

257 points pmig | 1 comments | | HN request time: 0.209s | source
Show context
pseudoramble ◴[] 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 #
tomohawk ◴[] 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 #
1. codr7 ◴[] No.43097777[source]
There's nothing forcing you to write EE style code in Java though, or depend on frameworks written in that style.