Compile-Time DI vs. Run-Time DI

I don&#x27;t understand why you need a framework for dependency injection in Go. I&#x27;ve written Go for years and I just use the `main` package to instantiate and wire up everything. It&#x27;s really straightforward, easy to debug, and there&#x27;s nothing to generate. It&#x27;s all type checked at compile time.<p>I&#x27;m not trying to rain on the author&#x27;s parade. I genuinely don&#x27;t understand the benefit—especially in relation to the complexity of adding an extra dependency and layer to my application.

What this blog post does not address is the joy of configuring DI with XML files &#x2F;s<p>Isn&#x27;t it bizarre how software developers have taken runtime DI to such extremes that it was considered a good idea to configure services in XML or YAML -- basically another language, that has to be parsed, can be malformed, etc?

Your point of breaking things as early in the process really is the winner.<p>Catching things early and often. Tooling that shifts things further left in the pipeline is my go-to default.

DI is Dependency Injection.

Java has a fairly nice compile time DI framework in Dagger. However, it feels like it is missing a compile time version of the rest of the web stack: compile time routing and compile time template compilation, for example. Does anyone have any suggestions to fill out this stack?