←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 1 comments | 18 Feb 25 16:55 UTC | HN request time: 0s | source
Show context
ed_blackburn ◴[19 Feb 25 08:36 UTC] No.43099953[source]▶
The real win for this team isn’t just switching from Java to Go. It’s breaking free from the heavyweight framework ecosystem that the JVM all but forces on you.

It’s not that the JVM is bad or that Go is a silver bullet, but Go does act as a forcing function, pushing teams to write simpler, more efficient code without layers of boilerplate, indirection, and unnecessary IO.

You can still do inversion of control without an IoC container—instantiation works just fine! Look at Go’s HTTP middleware pattern with structural typing and first-class functions. No config files, no annotation magic, just composition, testability, and code small enough to hold in your head.

replies(6): >>43099997 #>>43100043 #>>43100230 #>>43100886 #>>43100954 #>>43101873 #
1. thecupisblue ◴[19 Feb 25 11:28 UTC] No.43100954[source]▶
I wouldn't see this as the win for the team. The real win here would be:

* Understanding where the issues and bottlenecks are coming from * Understanding how it came to these issues * Figuring out how to resolve the issues without changing the whole tech stack

That way, the team would end up with a deeper understanding of their organisational issues leading to it, understanding of their code, cost of services, cost of the ecosystem and cost of computation. They would have been able to apply this knowledge to other projects in the company running the same stack.

The way this is written is basically sweeping the problems under the carpet with "tech slow, new tech fast" solution, while simultaneously letting the team keep doing whatever it is they were doing that made this slow. This is nothing but a surface level rewrite without understanding the real cause of the pain.