generic-client VS wire

code generation is a mostly disjoint topic from DI. Granted, some solutions like https://github.com/google/wire use code generation, but you're exactly right about their pitfalls. If your dev environment doesn't have good support for generated code, it is a nightmare. If you can goto-definition the generated code, then it is suddenly feasible, but perhaps still a bad choice.

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.

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.