| I recognise that DI frameworks may have a place when working with large teams and large applications, but otherwise I discourage them for a few reasons. The prerequisite knowledge problem: "Manual" DI requires knowing the language. Framework DI requires knowing the language and the framework. This alone makes it harder for new people to approach the codebase if they have not familiarity with the framework, even if they have mastered the language. There are already several DI frameworks for golang, but which ones are your new hires familiar with? The "how do I do X" problem: If you want to do something with your dependency graph, it's usually straightforward to express with plain code, but it might not be immediately obvious how to accomplish the same with the framework. For example, having multiple dependencies of the same type. With "manual" DI this is totally unremarkable. With wire, it goes against its mechanism and requires a minor workaround. The implicit graph problem: A DI framework the frees you from having to think much about the dependency graph may cause you to accidentally create a messy, illogical graph. It's easy to end up cornered by dependency cycles, for example. With manual DI, a flawed graph is more obvious early on because it's code you have to read and write. Explicit, not implicit. |