> The main benefit of constructing objects and tying them together via DI is to allow polymorphic handling of responsibilities.
This is already provided by interfaces, as previously discussed. To be clear, dependency injection makes sense; however, dependency injection frameworks don’t make sense to me.
> The underlying data in different implementations will be different. This is something Golang fails terribly at because it doesn't have polymorphism.
Go definitely has always had polymorphism; that’s the whole point of interfaces.
> The way Golang works, and the reccomended patterns for Golang are somewhat anti-DI.
DI (assemble your object graph in main() instead of distributing it across dozens of constructors a la OOP) is idiomatic Go; DI frameworks are not.
This is already provided by interfaces, as previously discussed. To be clear, dependency injection makes sense; however, dependency injection frameworks don’t make sense to me.
> The underlying data in different implementations will be different. This is something Golang fails terribly at because it doesn't have polymorphism.
Go definitely has always had polymorphism; that’s the whole point of interfaces.
> The way Golang works, and the reccomended patterns for Golang are somewhat anti-DI.
DI (assemble your object graph in main() instead of distributing it across dozens of constructors a la OOP) is idiomatic Go; DI frameworks are not.