Yeah as I alluded to, libraries are the thing that hamper this style. You don't control all the code in your application. But it's not too hard to work around.

I also think language-supported thread locals are superfluous in this style. Instead, just create a single object that runs into a single thread. Then you don't pass the object to any other threads. The members are automatically thread locals.

If you have N threads, then you have N objects confined to those threads. There doesn't need to be a separate concept of thread-local IMO.

Yeah, this is a huge benefit, especially in a language like Go where concurrency is cheap and common.

>I'm just passing dependencies through constructor and it works just fine.

Eventually its gets unwieldy when you have lots of classes. I've worked on old code in that style (DI w/o a library), it produces a lot of boilerplate. Piles and piles of "container" classes filled with deps getting passed around gets real old, real fast.

I strongly encourage people to use a framework like guice.

There are two parts to the problem. The first is that many languages (like Java) require a bit more boilerplate than others (like JSON) to express a composition of objects. The other problem is that complex applications have a very large number of compositions, so the overall pain is the product of the number of compositions and the boilerplate per composition. The number of compositions is a necessary evil--a framework won't fix it, but a framework can fix the per composition cost by moving the compositions into a cleaner language. Go solves this problem without a framework simply by having convenient syntax for composition.

> Eventually its gets unwieldy when you have lots of classes.

Yep, if application started to grow, it'll require significant refactoring at some stage. But many application won't grow and using framework for something like 5 services looks like overkill for me.