3 ms·
If it becomes a chore to instantiate your dependency tree with `new` or whatever in the root of your app, it's a good indication that the dependency tree _is to
by jen20 1y ago
If it becomes a chore to instantiate your dependency tree with `new` or whatever in the root of your app, it's a good indication that the dependency tree _is too complex_. You _should_ feel the pain of that, to align incentives for simplification.
Using an IoC container is endemic in the Java ecosystem, but unheard of in the Go ecosystem - and it's not hard to see which of them favours simplicity!
- surgical_fire 1y ago> instantiate your dependency tree with `new` or whatever in the root of your app Then you are doing dependency injection, just replacing the benefits of a proper framework by instantiating everything at once the root of your app. Whatever floats your boat, I guess. Thankfully I don't need to work on your code.
- jen20 1y agoIndeed, you get the benefits of dependency injection, without the complexity and shit show of a truth-obscuring framework. I think we can both agree that it’s good we don’t need to work with each other though.
- surgical_fire 1y ago> truth-obscuring framework. That you think that a DI framework obscures anything is just a developer smell. Having worked with multiple of those, it was always pretty clear what was being instantiated and how.
- jen20 1y agoWell in that case, every Java DI framework I’ve encountered has that smell. Spring, Guice, all of them. Same in C#. Perhaps it’s an enterprise (in the pejorative) thing. It is interesting to note that these frameworks are effectively non-existent in Go, Rust, Python - even Typescript, and no one complains you can’t build “real things” in any of those languages.