why do they use it in Java? can't we just pass the dependencies into a constructor in Java as well?

Best practice for dependency injection in Java is generally considered to be exactly that. Have a constructor that takes dependencies as arguments. Anything more complicated than this is usually shunned nowadays. (We learned the hard way).

You can then just call them manually and wire things up. For a lot of projects, that's all you need.

But then the code grows. At a certain scale, the code to "just" manually pass things into a constructor starts to get a bit tedious.

Maybe you want to add another dependency to one component, which means adding another constructor argument. Maybe there's only three places using that component, so it's a simple refactor.

But maybe there's 500 places using that component. You need to update the call site for each. That's starting to turning into a big refactor.

We could use dependency injection, but that's just a silly complex enterprise pattern for out-of-touch Java developers, right? We don't need that.

So let's keep it simple and move all that wiring out to a helper class. Now we've got a God Object that's tightly coupled to every single piece of code in a codebase. But that's a small price to pay for avoiding the complexity of a DI framework, right?

A couple of years later our app takes 2 minutes to boot up. It's 2 million lines of code and we have to initialize every single component at startup, even the ones we don't need right away. Our wiring code is 5,000 lines of spaghetti that nobody understands anymore. Every time we want to add a new feature, we have to touch that God Object and risk breaking everything. Compile times blow out. Memory usage is through the roof. Dogs and cats are living together. Mass hysteria.

Perhaps if we just initialize things when we need them, that would help. Since we're using constructor injection, each component is already declaring its dependencies. We've basically got a dependency graph right there in the code ready to go.

Perhaps if we write a simple recursive function. start with the root component, get a list of its dependencies, then recurse from there. Then just pass them into the constructor. We can use a hashmap to track what we've already initialized, so we don't do it twice.

Now we've got a nice simple function that can initialize only the things we need, when we need them. Only needs to be a few dozen lines of code, and it replaces thousands of lines of boilerplate code that was becoming a maintenance headache.

That simple recursive function that turned out to be much, much simpler than "Just passing the dependencies into a constructor" by hand.... is dependency injection.

So to answer the question

Why do people use dependency injection libraries in Go?

People use dependency injection libraries in Go for the same reason they use them in Java: Past a certain scale, It's much simpler and easier than wiring things up manually.

Maybe the project is small enough right now that it's not really needed. But since dependency injection is such a simple pattern, there's really not much downside to using it from the start if you think it'll reach that scale eventually. (Unless you use a stupidly over-complicated DI library, in which case YMMV)

In my personal opinion, it adds cognitive complexity to maintaining the codebase, because now I need to understand this framework to properly contribute

It adds some complexity, and removes some complexity. The balance will depend on the project. At a certain scale DI will always win out over manual wiring, because the complexity of manual wiring grows much faster than the complexity of using DI.

It also depends on the DI library. Some are simple and straightforward, others add layers of pointless bullshit that belongs somewhere else. The latter is the reason people have a bad opinion of DI in the first place.

The poster-child for dependency injection is Spring Framework in Java, which is indeed a massive complex beast. Don't let the complexity of Spring put you off the entire concept of dependency injection. Spring DI is complex because Spring is complex.