←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 8 comments | 18 Feb 25 16:55 UTC | HN request time: 0s | source | bottom
Show context
time4tea ◴[19 Feb 25 07:02 UTC] No.43099396[source]▶
The jvm is a pretty insane beast. It will do usage based recompilation, escape analysis for memory, so non heap allocation is super fast, has great memory safety... But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware software in the late 90s and early 2000s. It's cargo cult programming of the highest order. In the OP, the author is comparing apples with oranges, with a bit of misunderstanding that java/jvm means spring boot, and while that is true for a lot of people and certainly a lot of stuff on the internet implies that 'this is the way', it's not required. Startup times of ~100ms are absolutely standard for a big program, similarly unit tests taking 1ms. I prefer to write kotlin rather than java, as it's a nicer language ,IMHO, but still those bytecodes run on Jvm and same stuff applies.

Edit: im not advocating writing 'ls' in java, and I would also agree that java uses more memory for small programs, so its not a systems programming language probably.

Just use new() it's pretty fast.

replies(12): >>43099426 #>>43099935 #>>43100071 #>>43100330 #>>43100562 #>>43101034 #>>43101071 #>>43101189 #>>43101914 #>>43102326 #>>43102666 #>>43143349 #
1. unscaled ◴[19 Feb 25 11:42 UTC] No.43101034[source]▶
I think we can sum it this way. The blog post writer's intuition was correct: if you write two equivalent Go and and JVM programs, the Go program would use less heap memory and have faster startup times. What they are incorrect about is the extent of these claims.

It is obvious that most of the memory and startup overhead in their software comes from Spring, rather than the JVM. The JVM is probably not an ideal platform for writing an Kubernetes infra tool like operator or a sidecar (mostly due to heap size and more a complex binary packaging story), but using Spring Framework for writing these kind of tool is a bigger problem. If they just wrote their initial tool in Kotlin without using Spring framework at all, it would be much faster. They could even have kept Dependency Injection with a lightweight framework like Koin or Dagger (even a reflection-based framework like Guice performs worlds better than Spring).

I would probably still prefer Rust for writing most infrastructure projects nowadays. GraalVM Native Images has similar memory footprint to Go and solve the slightly troublesome JAR deployment story, but with the complex license terms for the enterprise edition (where most of the performance optimizations are), I don't feel safe using it. I also prefer Rust's concurrency model and I find cargo to be a far more pleasant experience than either Maven or Gradle, but in the end of the day, you will not see serious issues if you use Kotlin in a sane way, and you can even save on some Go boilerplate.

replies(2): >>43102500 #>>43109804 #
2. AYBABTME ◴[19 Feb 25 14:30 UTC] No.43102500[source]▶
Rust has its uses but why would you write infra code in Rust when Go is used for most of it, and is just much more ergonomic and fast to work with. The iteration times with Rust are quite detrimental. On the other hand, most of k8s' ecosystem is in Go.

I don't like commenting in language-war territory things but I found your comment surprising. "Rust or JVM" for infra isn't a dichotomy I would expect.

replies(3): >>43104823 #>>43108196 #>>43126048 #
3. sn9 ◴[19 Feb 25 17:34 UTC] No.43104823[source]▶
Discord had a pretty famous transition from Go to Rust [0].

[0] https://discord.com/blog/why-discord-is-switching-from-go-to...

replies(1): >>43111050 #
4. packetlost ◴[19 Feb 25 21:49 UTC] No.43108196[source]▶
Eh, I don't think iteration times in Rust are nearly as bad as you think. During a realistic development loop compilation is <1s in most situations thanks to incremental compilation and tests are fast unless you have synthetic slowdowns such as sleeps or IO (which would effect both languages equally).
5. indemnity ◴[20 Feb 25 00:51 UTC] No.43109804[source]▶
Funnily enough the initial version of Kubernetes was written in Java! But refactored into Go early on https://archive.fosdem.org/2019/schedule/event/kubernetesclu...
6. derekperkins ◴[20 Feb 25 04:16 UTC] No.43111050{3}[source]▶
They didn't have particularly great reasons to migrate at the time besides the team wanting to write rust. That article is just trying to provide validation
replies(1): >>43114935 #
7. sn9 ◴[20 Feb 25 14:20 UTC] No.43114935{4}[source]▶
"With the Go implementation, the Read States service was not supporting its product requirements. It was fast most of the time, but every few minutes we saw large latency spikes that were bad for user experience. After investigating, we determined the spikes were due to core Go features: its memory model and garbage collector (GC)."
8. lexicality ◴[21 Feb 25 10:37 UTC] No.43126048[source]▶
The entire point of writing rust is that you're trading writing speed for runtime safety. It takes longer to write but you can guarantee you're never going to have a nil pointer panic or race condition.

Unless you're doing something super weird your infra code is gonna be running for way longer than you spend writing it so who cares if it takes an extra 20%/30%/50%/whatever time to write?