←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 3 comments | 18 Feb 25 16:55 UTC | HN request time: 0.001s | source
Show context
philipwhiuk ◴[19 Feb 25 00:58 UTC] No.43097227[source]▶
As a Java developer...

If the entire problem domain space is written in a language it's dumb not to follow suit. Libraries that solve problems reduce your work to your own specific issues, rather than 'building an apple pie from scratch'.

Java is good right now because most problems have libraries to do what you want. Most formats have APIs.

It's not perfect in any area - the start-up time is a bit lame, you have to write 'anti-Java' to really get close to native performance. But it's quick to build in, the toolchain is solid, the dependency framework works better than all the alternatives. It's a 95% language that's been made development friendly.

(Golang somehow added versioning late and is 'Git+' at best, NPM unpublished stuff, C++ is hell, etc. Rust crates just doesn't have much but seems to have been built properly).

But if you're working in a new space (crypto, AI, cloud) then you should definitely look at what the state-of-the-art libraries are written in.

And you should think real hard before you implement your app in anything else. Because there will be a real, long term, painful penalty unless you get VERY lucky and the entire ecosystem pivots to your language.

replies(3): >>43097402 #>>43098224 #>>43099533 #
pylua ◴[19 Feb 25 01:18 UTC] No.43097402[source]▶
I’m also a long time java spring developer. I started writing a game recently and was really surprised about how bad the performance can be when you run it in a tight game loop.

The startup time is also a real problem, as you really want to be able to scale up pods quickly.

That said, it’s good enough right now. You can make it work at scale, and it’s worth the cost trade off of trying to do it more efficiently in a different language.

I would be curious to see how a rust microservice would compare in my companies infrastructure. How much cloud saving could we squeeze?

replies(7): >>43097852 #>>43098236 #>>43099325 #>>43099962 #>>43100846 #>>43101310 #>>43102551 #
gf000 ◴[19 Feb 25 11:08 UTC] No.43100846[source]▶
Could you expand on "how bad the performance can be" part?

If you are doing graphics, it is entirely more likely that you do something dumb there - there are many pitfalls.

Also, unless you are doing something very CPU-heavy, there won't be any noticeable difference as web servers are doing IO predominantly. Maybe slightly less RAM usage (but you could also just decrease the heapsize to tradeoff a bit of CPU-time for memory, if it were to make sense).

replies(1): >>43101486 #
pylua ◴[19 Feb 25 12:46 UTC] No.43101486[source]▶
In my game loop I was using optional. When I profiled it the use of optional was one of the slowest points that could be optimized using null checks and ifs.

There were a lot of other slow areas as well, not where you would expect it.

replies(1): >>43101596 #
gf000 ◴[19 Feb 25 12:57 UTC] No.43101596[source]▶
Sure, Optional is not the most optimal thing to use/do, though depending on how many entities you were operating with, that itself may still be negligible.
replies(1): >>43101624 #
1. pylua ◴[19 Feb 25 13:00 UTC] No.43101624[source]▶
That’s the pain point - well written java code may not be the most performant depending on the situation.

It wasn’t just optional but other areas as well.

replies(1): >>43101746 #
2. gf000 ◴[19 Feb 25 13:11 UTC] No.43101746[source]▶
That's not my experience, though game development is certainly a niche and Java may not be the top choice for that.

You might sometimes have to reach for SoA-like structures and reference them via indices, at least for the core ECS, but for the rest you can easily use bog-standard Java -- not everything has to be "ultra-fast, specially written java", just certain hot loops.

replies(1): >>43107871 #
3. pylua ◴[19 Feb 25 21:22 UTC] No.43107871[source]▶
Right. I didn’t started digging into it until I realized the application was clearly sluggish in certain scenarios. As I am doing this for fun I am going to see what kind of speed up I get in rust for this.