Live data from Hacker News

Dependency injection in Go with Uber-go/fx

vincent.composieux.fr

11–20 of 96 posts

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

#11
post #6
post #2

I've used dependency injection heavily in Java in previous jobs, and, later, spent a few years doing Golang at another job. I never missed it. What does dependency injection give you that a simple combination of Singletons, Constructors, and Factories doesn't? I feel like the only thing you get is the ability to combine multiple independent dependency trees without having to make a sane structure. Kind of like, what…

Agree. I really can only imagine this being useful for an organization that publishes dozens of different libraries that a "product team" needs to use such as logging, database access, secret managers, etc. At that point, speaking the common language of a DI framework might be easier. For example, rather than have to read the GoDoc for every single constructor i'm supposed to use, I can just see how to use my DI fram…

There's nothing special about DI frameworks there. If a client library has some sane defaults preferred by the devs, then call a constructor that sets the defaults for you. You don't need DI for that.

IME at tech megacorps, DI just obfuscates and distracts, shifting the focus onto understanding the accidental complexity it introduces instead of dealing with the intrinsic complexity of the dependency relationships.

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

#12
post #2

I've used dependency injection heavily in Java in previous jobs, and, later, spent a few years doing Golang at another job. I never missed it. What does dependency injection give you that a simple combination of Singletons, Constructors, and Factories doesn't? I feel like the only thing you get is the ability to combine multiple independent dependency trees without having to make a sane structure. Kind of like, what…

> What does dependency injection give you that a simple combination of Singletons, Constructors, and Factories doesn't?

Easy refactoring of an interface/constructor? I've been using go for a while, and I decided to follow the advise of not using a DI for my project. Every time I refactor a constructor, it is a fun hunt to make the same changes everywhere I'm using that constructor.

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

#13
post #5

Earlier quoted context omitted.

I've found DI pretty useful when building frameworks, it gives you a sort of generic plugin system. Plus you can hide it from consumers if that makes sense. If you're just building applications I'm not sure it's worthwhile.

The argument I always hear is DI makes your code more testable. Which is probably true in some cases, but I find most of my code is pretty testable without it. Haven't run into any tests I've wanted to build where I couldn't.

How do you test the code which determines when to fire the torpedoes, without actually firing the torpedoes every time you run the tests?

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

#14
post #13

Earlier quoted context omitted.

The argument I always hear is DI makes your code more testable. Which is probably true in some cases, but I find most of my code is pretty testable without it. Haven't run into any tests I've wanted to build where I couldn't.

How do you test the code which determines when to fire the torpedoes, without actually firing the torpedoes every time you run the tests?

By using a mock?

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

#15
post #5

Earlier quoted context omitted.

I've found DI pretty useful when building frameworks, it gives you a sort of generic plugin system. Plus you can hide it from consumers if that makes sense. If you're just building applications I'm not sure it's worthwhile.

The argument I always hear is DI makes your code more testable. Which is probably true in some cases, but I find most of my code is pretty testable without it. Haven't run into any tests I've wanted to build where I couldn't.

I think that's a side-effect of how code must be written to work with dependency injection, to make the injection actually possible, IMO it's not the DI itself that makes it testable.

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

#16
post #4
post #2

I've used dependency injection heavily in Java in previous jobs, and, later, spent a few years doing Golang at another job. I never missed it. What does dependency injection give you that a simple combination of Singletons, Constructors, and Factories doesn't? I feel like the only thing you get is the ability to combine multiple independent dependency trees without having to make a sane structure. Kind of like, what…

I came here to ask a similar question. I’ve spent most of my career writing C# where DI is prevalent. Over the Christmas holiday I picked up golang a bit. When I went to learn about DI for golang it seemed very counter to the principles of the language so I simply moved on. What am I missing out on?

Do you distinguish between dependency injection (frameworks) and general inversion of control?

Because what I think of dependency injection is extremely common in golang - they made interfaces satisfy structurally rather than nominally so that consumers could specify interfaces which anyone is free to satisfy. That the consumer owns the interface (packages shouldn't export interfaces for concretes they implement) is a pretty core tenet, and goes hand in hand with good dependency injection (IoC).

DI frameworks are extremely rare (and IME even more painful to use), because injecting your dependencies explicitly is straightforward. But injected they should be.

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

#17
post #13

Earlier quoted context omitted.

The argument I always hear is DI makes your code more testable. Which is probably true in some cases, but I find most of my code is pretty testable without it. Haven't run into any tests I've wanted to build where I couldn't.

How do you test the code which determines when to fire the torpedoes, without actually firing the torpedoes every time you run the tests?

Just fire them and do a ROLLBACK

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

#18
post #2

I've used dependency injection heavily in Java in previous jobs, and, later, spent a few years doing Golang at another job. I never missed it. What does dependency injection give you that a simple combination of Singletons, Constructors, and Factories doesn't? I feel like the only thing you get is the ability to combine multiple independent dependency trees without having to make a sane structure. Kind of like, what…

Please don't confuse DI with DI containers. With DI you still have all the responsibility.

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

#19
post #13

Earlier quoted context omitted.

How do you test the code which determines when to fire the torpedoes, without actually firing the torpedoes every time you run the tests?

By using a mock?

How do you convince the when-to-fire-logic to act on a mock, if the torpedo implementation is not provided from outside it?

I'm wondering if I have the terminology understood differently to other people, because to me, DI == IoC. DI Frameworks are build on top of the concept that dependencies will be injected, but doing it explicitly in your start-up code is the same thing to me.

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

#20
post #15

Earlier quoted context omitted.

The argument I always hear is DI makes your code more testable. Which is probably true in some cases, but I find most of my code is pretty testable without it. Haven't run into any tests I've wanted to build where I couldn't.

I think that's a side-effect of how code must be written to work with dependency injection, to make the injection actually possible, IMO it's not the DI itself that makes it testable.

Are you sure you are not mistaking dependency injection with dependency injection containers?
Post reply on HN