I’ve been working primarily in Go for the past five years, including some extremely complex projects, and I have never once wished I had dependency injection. It has been wonderful. I have used dependency injection - previously I worked on a C# project for years, and that used DI - but I adore Go’s simplicity and I never want to use anything else (except for JS for UI, via Electron or Wails for desktop).
Edit: If we’re talking about dependency injection in the general sense (separation of concerns, modularization, loose coupling), then yeah I agree that’s kind of critical to writing good, maintainable software. When I hear “dependency injection” I think of frameworks such as Unity, and that is what I was specifically talking about - I am very happy with the fact that I have felt zero need to use any framework like that over the last five years.
Go programmer here: What does Go’s simplicity have to do with dependency injection? What does a language itself have to do with dependency injection?
Reading your post and not being personally familiar with your work, I do wonder, perhaps your “extremely complex projects” wouldn’t be so extremely complex if you practiced dependency injection?
How do you unit test your extremely complex projects if your business logic carries the additional responsibility of creating objects?
What does Go’s simplicity have to do with dependency injection?
In my experience, following Go’s philosophy of simple solutions eliminates the need for complex solutions such as dependency injection.
How do you unit test your extremely complex projects if your business logic carries the additional responsibility of creating objects?
I write modular code that accepts interfaces so I can test the components I want to test. The vast majority of object creation happens at initialization time, not in the business logic. For the projects I’ve worked on, that would be true with or without DI - I don’t see how that’s relevant.
perhaps your “extremely complex projects” wouldn’t be so extremely complex if you practiced dependency injection?
When the CTO says, “Make it distributed and sharded,” I do what I’m told, but that is an intrinsically complex problem. The complexity is in the overall behavior of the system. If you zoom in to the individual execution units, the business logic is relatively simple. But the behavior of the system as a whole is rather complex, and DI isn’t going to change that.
Edit: I was interpreting “using DI” to mean using a DI framework such as Unity, and I would be happy to never need one of those frameworks ever again.
Why is the joke with Java always factories? Factories are really super useful in a dependency injection context.
I’ve been working primarily in Go for the past five years, including some extremely complex projects, and I have never once wished I had dependency injection. It has been wonderful. I have used dependency injection - previously I worked on a C# project for years, and that used DI - but I adore Go’s simplicity and I never want to use anything else (except for JS for UI, via Electron or Wails for desktop).
Edit: If we’re talking about dependency injection in the general sense (separation of concerns, modularization, loose coupling), then yeah I agree that’s kind of critical to writing good, maintainable software. When I hear “dependency injection” I think of frameworks such as Unity, and that is what I was specifically talking about - I am very happy with the fact that I have felt zero need to use any framework like that over the last five years.
Go programmer here: What does Go’s simplicity have to do with dependency injection? What does a language itself have to do with dependency injection?
Reading your post and not being personally familiar with your work, I do wonder, perhaps your “extremely complex projects” wouldn’t be so extremely complex if you practiced dependency injection?
How do you unit test your extremely complex projects if your business logic carries the additional responsibility of creating objects?
In my experience, following Go’s philosophy of simple solutions eliminates the need for complex solutions such as dependency injection.
I write modular code that accepts interfaces so I can test the components I want to test. The vast majority of object creation happens at initialization time, not in the business logic. For the projects I’ve worked on, that would be true with or without DI - I don’t see how that’s relevant.
When the CTO says, “Make it distributed and sharded,” I do what I’m told, but that is an intrinsically complex problem. The complexity is in the overall behavior of the system. If you zoom in to the individual execution units, the business logic is relatively simple. But the behavior of the system as a whole is rather complex, and DI isn’t going to change that.
Edit: I was interpreting “using DI” to mean using a DI framework such as Unity, and I would be happy to never need one of those frameworks ever again.
basically dependency injection