wire VS nject

We use https://github.com/google/wire for every bigger project, take a look at it, it beautifully solves initialisation and also gives you a guideline on how to do it.

Im by no means a "purist" in such things, I love my magic and QoL-features/libs, but havent seen something that is so easy to use in go, that I immediately wanted to add it. And to be fair, I only looked closely at https://github.com/google/wire , others I have just skipped - and I will be looking into uber-fx as mentioned in the other comment.

If you have such a complex and deep dependency graph, and you don't want to manually maintain it, you could use some DI library to handle that for you. Something like https://github.com/google/wire for small-medium size stuff, or https://github.com/uber-go/fx for larger scale, more enterprise projects.

For big project you need DI framework, and I suggest Google Wire (https://github.com/google/wire)

Try https://github.com/google/wire. Compile time generated like dagger 2 in java.

Most people probably do it by hand (I do). But otherwise, probably https://github.com/google/wire is the most popular, maybe followed by https://github.com/uber-go/fx.

For larger object graphs do you roll everything by hand or encourage something like https://github.com/google/wire

The other thing is that I'm lazy, so I don't construct all dependencies in main.go manually but use wire to generate the construction of my dependency tree.

In terms of what I compare axon to, most DI frameworks in go require either lots of reflection to add/get values from the injector with interface{} based func params like dig or code generation like in wire which can be difficult to integrate into an existing codebase.

For those who commented about Java & DI: I used DI with Java and hated it. It seemed to be simply a complex interface around global variables. Please take a look at [nject]([https://github.com/muir/nject]. The idea is fundamentally different: you create an injection chain out of reusable components. I won't say that it makes DI simple, but it does alter the cost/benefit ratio such that DI becomes very advantageous for several uses.