Hacker News new | ask | show | jobs
by ravishi 1569 days ago
We use Uber/fx in the org I work.

Took me a while to buy into it, because as you said, it doesn't seem any better than hand-written code.

But after a few years I noticed fx was being adopted by more and more teams, and it reduces cross-project contribution friction, some teams started building conventions around it, and more importantly, iterating on these conventions, etc. It's become just really handy for us.

This is many many small teams (5 people per team, more than 4k devs around many offices and countries).

1 comments

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.
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!

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.
Dependency injection happens all the time in Go. It's just a lot more elegantly expressed in idiomatic Go than in FX.
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.

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