2 ms·

> As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling

> As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. I actually see this as a negative and we've been looking at Uber/Fx for more support. DI frameworks don't do anything you can't do without it, but it takes significantly more experience and technological/organizational maturity that I find the average developer doesn't have to do it without framework support. In the current zeitgeist of being towards the "micro" scale of the spectrum, that "average developer" support is necessary. If you have more modular monoliths or many high quality examples, maybe its better.

jimbokun 2y ago
DI in something like Spring, for example, can make it extremely hard to track where a given dependency is coming from. With the use of annotations and defaults and properties on annotations for selecting a dependency, to sometimes autogenerated classes for which there is no source code. I would much rather have a few lines of straight forward code that set up dependencies explicitly, than deal with opaque semantics and mysterious incantations.
- eximius 2y ago
  I've never really had that trouble. There are typically relatively few places that 1. a given interface is provided via a DI module 2. said modules are included in a binary With decent codesearch, finding the implementation of a particular injection for a given deployed binary is usually a fairly short search. I'm sure there is all sorts of extra voodoo you can get up to, but the straightforward DI case is, well, straightforward.
  - jimbokun 2y ago
    The autogenerated class with no source code was not a hypothetical example. This was something I saw cause a problem in production, where the source code in the stack trace didn't exist.
    - eximius 2y ago
      code generation is a mostly disjoint topic from DI. Granted, some solutions like https://github.com/google/wire https://github.com/google/wire use code generation, but you're exactly right about their pitfalls. If your dev environment doesn't have good support for generated code, it is a nightmare. If you can goto-definition the generated code, then it is suddenly feasible, but perhaps still a bad choice. But the DI frameworks I've used are typically just... normal code files. Uber/fx, Go/Guice, etc
zer00eyz 2y ago
Wow, that's a pretty good take. There is a line here though. I think a lot of people have seen what happens when you set a bunch of JR devs loose in a node/ruby code base with all that tooling. It goes about as well as giving a lead footed suburbanite an F1 car. If you work in an agency (new every week) or in a place where you have a high number of jr devs then a framework makes a fair bit of sense. But at that point are your experienced devs being productive or being babysitters? I think I would rather babysit a bunch of jr devs working in Go where correcting their issues is educational, rather than dealing with babysitting JR devs and high speed stupidity in something like rails...
- eximius 2y ago
  My experience is that there is a great, big in-between where folks are just chugging along and aren't thinking about project/codebase level architectural decisions. Without that active thought and foresight, you end up shooting yourselves in the foot, a bit. With DI frameworks, the _default_ ends up typically being the right thing to do so it unburdens people from a particular slice of cognitive load.

jimbokun 2y ago

DI in something like Spring, for example, can make it extremely hard to track where a given dependency is coming from. With the use of annotations and defaults and properties on annotations for selecting a dependency, to sometimes autogenerated classes for which there is no source code. I would much rather have a few lines of straight forward code that set up dependencies explicitly, than deal with opaque semantics and mysterious incantations.

eximius 2y ago
I've never really had that trouble. There are typically relatively few places that 1. a given interface is provided via a DI module 2. said modules are included in a binary With decent codesearch, finding the implementation of a particular injection for a given deployed binary is usually a fairly short search. I'm sure there is all sorts of extra voodoo you can get up to, but the straightforward DI case is, well, straightforward.
- jimbokun 2y ago
  The autogenerated class with no source code was not a hypothetical example. This was something I saw cause a problem in production, where the source code in the stack trace didn't exist.
  - eximius 2y ago
    code generation is a mostly disjoint topic from DI. Granted, some solutions like https://github.com/google/wire https://github.com/google/wire use code generation, but you're exactly right about their pitfalls. If your dev environment doesn't have good support for generated code, it is a nightmare. If you can goto-definition the generated code, then it is suddenly feasible, but perhaps still a bad choice. But the DI frameworks I've used are typically just... normal code files. Uber/fx, Go/Guice, etc

zer00eyz 2y ago

Wow, that's a pretty good take. There is a line here though. I think a lot of people have seen what happens when you set a bunch of JR devs loose in a node/ruby code base with all that tooling. It goes about as well as giving a lead footed suburbanite an F1 car. If you work in an agency (new every week) or in a place where you have a high number of jr devs then a framework makes a fair bit of sense. But at that point are your experienced devs being productive or being babysitters? I think I would rather babysit a bunch of jr devs working in Go where correcting their issues is educational, rather than dealing with babysitting JR devs and high speed stupidity in something like rails...

eximius 2y ago
My experience is that there is a great, big in-between where folks are just chugging along and aren't thinking about project/codebase level architectural decisions. Without that active thought and foresight, you end up shooting yourselves in the foot, a bit. With DI frameworks, the _default_ ends up typically being the right thing to do so it unburdens people from a particular slice of cognitive load.