←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 4 comments | 18 Feb 25 16:55 UTC | HN request time: 1.837s | 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 #
cmrdporcupine ◴[19 Feb 25 02:25 UTC] No.43097852[source]▶
Most "microservice" backend type stuff is I/O bound, not CPU bound. You're likely not going to win much.

Maybe get away with lower memory instances though.

replies(2): >>43100131 #>>43100337 #
1. rahen ◴[19 Feb 25 09:05 UTC] No.43100131[source]▶
Cold latency is an issue with microservices. If you need to use Java, you'll likely end up using frameworks like Spring or Quarkus, which somewhat diminish the advantages of using the JVM and Java as a language.

At that point, you might as well start with Go from the beginning.

replies(1): >>43100860 #
2. gf000 ◴[19 Feb 25 11:10 UTC] No.43100860[source]▶
Is it really an actual issue? How often do you restart instances or scale up horizontally?

A cheap 10 years old desktop PC can easily handle all the traffic a medium-sized website generates at all times.

replies(1): >>43101501 #
3. pylua ◴[19 Feb 25 12:48 UTC] No.43101501[source]▶
What do you define as medium size?
replies(1): >>43101587 #
4. gf000 ◴[19 Feb 25 12:55 UTC] No.43101587{3}[source]▶
Stackoverflow famously ran on a single, although quite beefy server PC for a long time (not any longer, but not for performance reasons AFAIK).

I think it's a good data point to have to scale your workload to stackoverflow's, and reconsider the hardware costs.

(Obviously horizontal scaling has its place, but if it's that variably scalable, maybe there are better solutions, e.g. a single bigger instance -- often times even for cheaper)