[mgrund]

Full disclaimer: Uber employee using fx daily as well as in hobby projects. Post reflect my personal opinion and is not related to Uber.

It really does work really well in practice:

- It pretty simple and lightweight so it’s blazingly fast even though it happens at runtime (in contrast to e.g. the Java DI frameworks I’ve seen)

- The module concept is extremely powerful to make modules that plug in with zero effort

- Modules have a lot of autonomy (unlike wire, as I understand it - I have no personal experience with it), like being able to do things at various stages of the application lifecycle (startup, shutdown hooks), collaboratively populate dependency groups (e.g. implementing handlers or middlewares independently and injecting them separately using the grouping mechanism), optional dependencies

Once you have a nice standard library of common modules (this is really crucial for it to work well IMO), it’s a huge speedup to make a high-quality service. My biggest issue with it is that it doesn’t match structs with interfaces, so you effectively end up depending on structs/pointers or returning interfaces.

[akshayshah]

Warms my heart to hear that people still find some value in fx :)

Does fx.As[0] help match structs to interfaces? It was added long after my time, but seems to target this problem.

[0]: https://pkg.go.dev/go.uber.org/fx#As