Dependency injection in Go with Uber-go/fx • Hacker News Board

Re: Dependency injection in Go with Uber-go/fx

#91

Post by staticassertion » Mon, Feb 28, 2022, 3:07 PM UTC

ceras wrote: post #85

staticassertion wrote: post #64

Earlier quoted context omitted.

This is pretty much what I don't get. DI by construction is trivial and has all of the benefits of a DI framework. DI frameworks just let you move some things around, which is mostly confusing.

As someone who's liked using DI frameworks, I'm curious: if you do it manually, as your codebase gets large, doesn't it get harder to "plumb" a new object that needs to get used somewhere at a deep level? This seems like it'd get more unwieldy when refactoring. I've never worked in a large codebase that did this manually so I'm not sure what it looks like. The large codebases I've seen that don't use DI have used som…

All object creation is in one place - main. So no, I should never have to go deep anywhere.

Re: Dependency injection in Go with Uber-go/fx

#92

Post by lucasyvas » Mon, Feb 28, 2022, 3:49 PM UTC

staticassertion wrote: post #91

ceras wrote: post #85

Earlier quoted context omitted.

As someone who's liked using DI frameworks, I'm curious: if you do it manually, as your codebase gets large, doesn't it get harder to "plumb" a new object that needs to get used somewhere at a deep level? This seems like it'd get more unwieldy when refactoring. I've never worked in a large codebase that did this manually so I'm not sure what it looks like. The large codebases I've seen that don't use DI have used som…

All object creation is in one place - main. So no, I should never have to go deep anywhere.

This is my take as well. Plus, if you are plumbing something that deep, the odds that your design is total shit is approaching 100%.

Manual DI reveals problems like this way earlier.

DI frameworks, IMO, are some of the most useless around. Solution seeking a problem.

Re: Dependency injection in Go with Uber-go/fx

#93

Post by kcartlidge » Mon, Feb 28, 2022, 8:18 PM UTC

I started off decades ago with stuff like Delphi, PHP, and Python, all without DI. About 2001 I started with C# and I found properly implemented DI in .Net to be a killer feature.

However I loved it so much that I then wrote my own Node DI package (property and constructor injection). It didn't take long before I abandoned the idea - Node doesn't really fit with DI.

And I feel the same about Go. Some languages (eg C#, Java) work amazing with DI. For some others (eg Node, Go) it simply feels wrong. I can't put my finger on why, but reading the sample Go code in the original article makes me feel how I do when (in film) I see a human body with a limb bent to an unnatural angle.

Just to clarify I'm all up for well designed IOC with Node and Go, I'm just unconvinced it should be done with DI.

Re: Dependency injection in Go with Uber-go/fx

#94

Post by BobbyJo » Mon, Feb 28, 2022, 8:21 PM UTC

taeric wrote: post #62

BobbyJo wrote: post #57

Earlier quoted context omitted.

What's the difference? Isn't the 'injection' part the part where you don't need to connect point A and point B?

Sorta. The pattern is having standard method of injecting dependencies. Having a framework just saves you having to do the actual injecting, manually. This is easy to see in frameworks like dagger, which compile time generate the boilerplate you could manually do. And if everything is a singleton with no lifetime management, the framework doesn't buy you too much. The pattern, though, is kind of nice. I rarely have t…

> (Contrast to python, where I don't know what is going to happen if I add that import...)

I felt that in my bones.

Re: Dependency injection in Go with Uber-go/fx

#95

Post by ravishi » Thu, Mar 03, 2022, 6:45 PM UTC

otterley wrote: post #35

leoqa wrote: post #32

Earlier quoted context omitted.

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!

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

Re: Dependency injection in Go with Uber-go/fx

#96

Post by lr4444lr » Thu, Mar 10, 2022, 2:09 PM UTC

isbvhodnvemrwvn wrote: post #27

lr4444lr wrote: post #25

Earlier quoted context omitted.

Just come out and say it: DI is an anti-pattern. No implementation of it that I'd ever use was doable without a good config file schema, and at that point I have to ask: why not just have a declarative build system in the first place as the modern generation of Devops tools does? DI just burdens and litters code unnecessarily with awareness of build files.

You, as many people here, are again mistaking dependency injection with dependency injection containers. You don't need containers for dependency injection, most codebases can just wire everything by hand without any problem.

What's an example of what you're talking about? Because the delegator pattern is not CI, and that's the only thing that's coming to mind that you might mean.