I have worked with Java a lot, but not in a very long time, and I only touched on Beans (that’s what it’s called right?) very briefly. My experience with DI is mostly from PHP using the Symfony DI framework. Certainly using YAML and some of the keywords I chose were inspired from Symfony.

It’s interesting that you say you believe the pattern to be too old for Go. Fundamentally (without a container) DI is a pattern for making your code more modular and testable. In this way it cannot be “old” — in the same way that SRP is also a good practice to follow regardless of age or language.

I believe you are referring more to the idea of using a container and configuring it outside of the language, with another tool. Then I agree, it’s not very Go-ish. However, I don’t want the idea of it being similar to tools used long ago to taint its usefullness today. I’m not saying your whole application should be configured this way. Certainly not, but in my experience there are certain workflows that are made much easier with a configured container. Especially when dealing with applications that have a lot of external APIs.

What I think is most important here is that Go is a typed language and I didn’t want to betray that by building an abstraction layer that used reflect or required any explicit casting that could lead to runtime errors. That is why I chose to build the Go code so you would get the full support of the compiler, without the headache of creating the common boiler-plate code.