←back to thread

257 points pmig | 1 comments | | HN request time: 0.001s | source
Show context
ed_blackburn ◴[] 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 #
hyperpape ◴[] No.43101873[source]
> the JVM all but forces on you

I don't think you're wrong, but you're making this sound like it an issue with the JVM. It's certainly not. I guess it could be an issue with the Java language, but I don't really think so.

Mostly it's an issue with the Java ecosystem.

replies(1): >>43102124 #
1. chamomeal ◴[] No.43102124[source]
Yeah sounds more like a java issue to me. Clojure is usually beautifully terse and straight-to-business with very little boilerplate, and it usually runs on the jvm.

But still agree with the other commenter on the benefits of go. I’m not a huge fan of go, but it’s definitely encourages grug brain style (https://grugbrain.dev/) which has many benefits.

In fact, the only time I disagree with grug style is when I’m really close to the perfect generics for a TS function with lots of coupled inputs. Always so close…