[sidlls]

"Dependency Injection" should be just shorthand jargon for "pass a pointer/reference to the dependency into the constructor".

Unfortunately, thanks to enterprisey-OO zealotry, it's become a terrible monstrosity of frameworks, obfuscation-by-configurable-injection, and other terrible practices.

Every single application I've worked on where DI (in practice, not theory) is in use has been fragile, hard to debug, hard to test, and hard to maintain.

And this particular framework looks like it has all the markings of making any go application worse.

[geodel]

> Every single application I've worked on where DI (in practice, not theory) is in use has been fragile, hard to debug,..

From what I have learned working at various jobs it seems to be the feature and not bug in system design. When things break it is considered a problem worthy of attention of those numerous architecture astronauts. It would have just been college project if things work without any fuss.

[cleancoder0]

Given a list of pairs, where one is an object and the other the arguments of the constructor, find a way to construct all of the objects.

Topological sort and run. That’s all there is to dependency injection and I cannot imagine a graph so large that I would care for toposort

[taeric]

This leaves out lifecycle management.

Which, yes, some lifecycles are confusing. But using them well can be very beneficial