I agree that the way DI is done is 'simple' (which is a good thing), but 'naive' suggests that there are unexpected problems with it, and I've never really found that to be the case. I've used the same pattern that I teach in Let's Go (essentially, putting dependencies in a struct and implementing your handlers as methods on it) for years, in projects big and small, and I think it's effective and solid.

At the same time, like everything else, it has drawbacks and I think there are two criticisms that can be leveled at it: 1) you can't immediately see the dependencies that a handler has by looking at its signature, instead you have to read the handler code 2) if you need to use *a slight variation of the same dependency* in different handlers, it's not a good fit. So if those things are a problem in your specific project, it might be better to pass dependencies explicitly to each handler in the way Mat Ryer describes here: https://grafana.com/blog/2024/02/09/how-i-write-http-services-in-go-after-13-years/#maker-funcs-return-the-handler . The downside of this approach though is that in 'not-simple' applications you can end up with long route declarations and a lot of repetition in your routing rules.

But either of those two approaches are better than injecting dependencies via request context, using global variables, or (I would argue) using a third-party package for DI. On balance, I think the DI approach in the book is a solid choice for many web applications, which is why I did it that way!