What should a modern Go dependency injection framework look like?

Go DI has always been a trade-off. Runtime DI frameworks provide a convenient API, but they rely on reflection and discover dependency problems during application startup. Compile-time DI frameworks avoid those problems, but some APIs become verbose and less ergonomic. I have been exploring a different approach: dig — compile-time dependency injection for Go with an Fx-style API and Wire-style code generation. Repository: https://github.com/shanjunmei/dig The main design goals are: dependency graph resolution during go generate zero runtime reflection zero runtime dependency after code generation generated code is plain Go minimal API: Build, Provide, Supply, Invoke, Module Example: func InitApp() func(context.Context) error { return dig.Build( dig.Provide(NewConfig), dig.Provide(NewDatabase), dig.Invoke(StartServer), ) } After generation, the application does not depend on a DI runtime. Some design questions I would like feedback on: Do you prefer compile-time DI or runtime DI in large Go projects? Is avoiding reflection an important advantage in practice? Are there DI patterns from Wire/Fx/custom solutions that should be preserved? What API choices would make a Go DI library feel natural? The goal is not to create another DI library for its own sake, but to explore what a more Go-like DI design could look like. Feedback and criticism are welcome.