[HN Gopher] Google's Wire: Automated Dependency Injection in Go
       ___________________________________________________________________
        
       Google's Wire: Automated Dependency Injection in Go
        
       Author : nparente
       Score  : 11 points
       Date   : 2023-02-18 17:24 UTC (5 hours ago)
        
 (HTM) web link (nelsonparente.medium.com)
 (TXT) w3m dump (nelsonparente.medium.com)
        
       | procrastitron wrote:
       | Dependency injection frameworks are a horrible idea.
       | 
       | They optimize for the wrong thing; making code easier to write
       | but harder to read and edit.
       | 
       | Writing code is a one time cost whereas reading and editing it is
       | an ongoing effort, so dependency injection frameworks are
       | optimizing for the uncommon case at the expense of the common
       | case.
       | 
       | Compile-time dependency injection frameworks are a big
       | improvement over runtime dependency injection frameworks because
       | you can at least read the generated code, but they are still a
       | lot worse than manual dependency injection when it comes to
       | editing code.
        
         | cookiengineer wrote:
         | I could understand if the environment would depend on network
         | loading speeds, and having to lazy load and cache/inject
         | dependencies only when they are actually used (like in the
         | Browser).
         | 
         | But with go as build environment this kind of contradicts
         | everything that go is good at, so even after reading I'm asking
         | myself for a legit use case for dependency injection in go
         | (other than malware development or hijacking a loaded DLL of
         | another program).
        
         | oftenwrong wrote:
         | I recognise that DI frameworks may have a place when working
         | with large teams and large applications, but otherwise I
         | discourage them for a few reasons.
         | 
         | The prerequisite knowledge problem:
         | 
         | "Manual" DI requires knowing the language. Framework DI
         | requires knowing the language and the framework. This alone
         | makes it harder for new people to approach the codebase if they
         | have not familiarity with the framework, even if they have
         | mastered the language. There are already several DI frameworks
         | for golang, but which ones are your new hires familiar with?
         | 
         | The "how do I do X" problem:
         | 
         | If you want to do something with your dependency graph, it's
         | usually straightforward to express with plain code, but it
         | might not be immediately obvious how to accomplish the same
         | with the framework. For example, having multiple dependencies
         | of the same type. With "manual" DI this is totally
         | unremarkable. With wire, it goes against its mechanism and
         | requires a minor workaround.
         | 
         | The implicit graph problem:
         | 
         | A DI framework the frees you from having to think much about
         | the dependency graph may cause you to accidentally create a
         | messy, illogical graph. It's easy to end up cornered by
         | dependency cycles, for example. With manual DI, a flawed graph
         | is more obvious early on because it's code you have to read and
         | write. Explicit, not implicit.
        
         | etamponi wrote:
         | Thank you for this. I'd even say that dependency injection
         | frameworks eliminate the most important thing of dependency
         | injection: explicit dependencies.
        
       ___________________________________________________________________
       (page generated 2023-02-18 23:01 UTC)