←back to thread

257 points pmig | 3 comments | | HN request time: 0.657s | 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 #
1. aqueueaqueue ◴[] No.43100230[source]
IoC isn't even DI. IoC is saying "I need to talk to a service that handles these account operations I care about" rather than "I need a MySql connection, a coupla s3 buckets and a folder on disk"

DI can support both the "I need" and "I orchistrate" patterns.

Obviously modulo leaky abstractions! You might want to known if that account code is in L1 cache or Timbuktu.

replies(1): >>43102155 #
2. chamomeal ◴[] No.43102155[source]
So is DI usually referring to automatic framework-wiring DI? Cause I constantly pass dependencies in as arguments and call it DI.
replies(1): >>43108326 #
3. aqueueaqueue ◴[] No.43108326[source]
DI can be manual DI - passing dependencies. I think the hallmark is lack of "new" in your classes (or probably lack of specific imports in a non OO idiomatic language like JS)

IoC is more about design than dependency resolution mechanisms.