[leoqa]

Same. It’s nice to publish an fx module that implements a middleware that plugs into all of the 12000+ microservices we run. One example is adding a debug/flame graph endpoint to your service- it’s a one line import into your app.

[otterley]

The Go convention for adding features like that is

    import _ "example.com/feature"

Á la https://pkg.go.dev/net/http/pprof

Reads a heck of a lot easier!

[closeparen]

If the complaint about dependency injection is that it’s magic, brittle, and difficult to debug - globals mutation via init() is much worse. In FX codebases this is heavily discouraged. The concepts of constructors and lifecycle hooks in an FX graph are not that hard to grok; you can pretty readily figure out what’s going on if you want to.

[otterley]

Dependency injection happens all the time in Go. It's just a lot more elegantly expressed in idiomatic Go than in FX.

[closeparen]

The “import _” approach you recommend is idiomatic Go but it is inherently a global mutable state approach and not a DI approach.

I suppose elegance is in the eye of the beholder. FX is very elegant in my opinion: just specify your constructors and your needs, let the computer do the topo sort. But you’re right it is not idiomatic Go. Idiomatic Go is always to maximize the volume of rote, low-information-density code to accomplish any given task. Any time you are being clever and automating grunt work you are certainly violating the spirit of Go.

[ravishi]

It sure does. But as I commented before, readability might not be the best/only metric to strive for.