The Koin roadmap flew through all channels in recent days. I read it for some reason and thought longer than I should have.
Purely as a developer of a developer I understand the author. He's doing some cool things, KMP there, some optimizations, writing compiler plugins, processing annotations, integrating with Compose. Dream job practically. But as a user I and Koin are on completely different poles it seems. Because why the hell do I need all this in a library for DI? You invented the problems yourself and now you're heroically solving them.
It all started with the fact that it was a slightly smarter map of classes to their instances. Solved the problem of complexity of popular Daggers at that time on one hand and the impossibility of calling constructors of system classes directly on the other hand. Added its own nuances, like the fact that at all interviews they started to suffocate with questions about service locators, but took with its "simplicity". Since then a lot of water has flowed, all kinds of Hilts appeared, which thanks to Google's marketing machine and solving the first of the problems became the de facto standard for beginners. And I even approve of this compared to Koin, even though I don't like both of them.
If we don't touch on some fundamental questions, then it just seems that Koin over time turned into some magical spaceship with its own language, different ways to do the same thing, and still without guarantees that it won't fall apart in flight.
And it's still needed exclusively to get a dependency "from somewhere", without thinking at all from where. That is, to sweep under the rug the complexity of our dependency graph. Like so that these dumb developers (including you) don't even turn on their head how shitty this graph is implemented. And this is still at the cost of runtime safety. 😢
I have exactly the same complaints about Dagger etc., by the way. But it's many times easier to refactor if it so happened and you got such a project. Singleton will singleton around, all viewmodels of the application listed in one file, AppComponent for thousands of lines and all in this spirit - this is straight base.
And if we dig deeper? To the first line of documentation Why Koin? - Koin provides an easy and efficient way to incorporate dependency injection into any Kotlin application. You know what else provides an easy and efficient way to inject dependencies? Constructor parameters. In bare Kotlin. Without any DSL and smart API. ðŸ¤
By the way, we have Koin on our work project. We haven't touched it to seriously redo something in the last two years, because it's not worth it. And if you start a project from scratch and can afford to use constructors - there's not a single reason to drag this nightmare to yourself. Start, damn, an object with all dependencies, and that will be better.