I think you’ve misunderstood me. I’m not saying that automatic solving removes the design problem. No, it doesn’t. But it makes you lot more scalable so you may design bigger and better things. The same applies to managed memory — it doesn’t remove the design problem but it greatly reduces your burden and let’s you design bigger and better things.

And exactly the same arguments work against managed memory — “we need control, in case we design/code better we don’t need it, we don’t believe that runtime remove the very hard problem of proper design/managed runtimes are inevitably slower/overhead is too high/managed runtimes offload many tasks which can be solved by compiler to runtime/…”.

I wouldn’t say the managed memory analogy can be stretched to cover this case. Using managed memory is a completely different way to code, and much more influential on your coding style than the way you wire dependencies. Also, here we are contrasting a “basic” approach using Scala constructs only, with a more “advanced” approach using a library to manage the graph for you.

That said, for the time being, I can’t see how using distage or any other library makes it easier to properly design module boundaries. It’s very possible that it’s my lack of experience or understanding, or the type of projects that we’re working on.

Also I’m not sure what do you mean by saying “coupled”. As you correctly noticed distage is non-invasive and can be replaced with other wiring mechanisms. But other existing wiring mechanisms cannot support the patterns we need.

Coupled to writing your service in Scala and using distage to create the service object graph. I’d say that’s quite limiting, and I suspect it might be a warning light for others. A JVM-level mechanism would probably be better here.

And yes, while our ideas are extremely simple and distage is just a model illustration for them, most of the people just don’t want to listen because “DI cannot work” or something like that.

I’d be happy to read more about that! Your ideas might be good, but I think they need more talks/blogs which would try to explain things from the ground up. You have good reference documentation, but that’s different from tutorials or trying to explain the basics.