[singron]

"static" in java DI can refer to setting global variables with singleton instances. E.g. java logging libraries usually do this so that you don't have to DI everywhere you want to log. In Go, some packages do this like flag and log. In Rails, this is so common that it replaces DI entirely, but I usually didn't feel like rails suffered from it.

I think what you are referring to is just manually doing DI. I.e. you defined constructors that accept dependencies and then call them all in a main function. I think this is tolerable if your codebase is structured for it. In typical java codebases, it gets ugly really fast. IMO this is caused by a general proliferation in the number of classes (due to class-per-file among other reasons), as well as a tendency to never use "static" DI. As an extreme example, if you needed to inject a logging dependency, then almost all code would need to be part of the DI graph. In a typical web backend, you might DI the sql connection pool. This causes basically all code to need DI since it either uses sql or has a transitive dependency that uses sql. IMO injecting the connection pool is not useful since it's not useful to write tests where you inject anything other than a real sql connection.

[benhoyt]

Ah, that explains the confusion. Yeah, I didn't mean static as in the "static" keyword in Java / C++, but as in specified in the statically-typed code. Defining constructors that accept dependencies -- exactly. Ah yeah, I can see how Java exacerbates things here with the one-class-per-file rule -- ugh.

Go doesn't require one class (well, type or struct in Go) per file, and has much more flexibility in how you build packages as a result. I think it's a good thing that dependencies like the logger and the database are passed around explicitly: I've learned the hard way that "explicit is better than implicit" even when it means a bit more boilerplate.