A modern programming language that makes developers happier.

kotlinlang

*We are sunsetting Kodein DI.* :orange_heart:

Kodein DI will go into maintenance mode: no new features, but we will keep maintaining the current version and fix issues when necessary. Our focus moves to *Inara*, a new library I introduced today.

*Why?*

I created Kodein in 2015, as the KOtlin DEpendency INjection framework. It was the very first non-JetBrains Kotlin/Multiplatform library to be published. In 2018, Arnaud Giuliani introduced Koin, and by 2020 it was clear Koin was winning the DI library race, thanks to Arnaud's great work and dedication. We discussed internally whether Kodein was still worth maintaining, and we decided to keep it: it still had its loyal user base.

Since 2022, however, I have grown to dislike the paradigm that libraries like Kodein and Koin use, so I stopped using them entirely. I want to understand what is going on in my code, and to control how it behaves. A traditional DI container made me uncomfortable: its runtime graph resolution algorithm, and its famous "ask me a type, and I'll give you an instance from context" paradigm. I created Kodein, yet I now believe it to be detrimental to the Kotlin Multiplatform ecosystem.

*What is different in Inara*

Inara is a *Kotlin Symbol Processor* (KSP) that writes a thin layer of interface-based modules for you, resolved *at compile time* with simple Kotlin syntax.

• _No runtime overhead_: a dependency either exists in a module interface, or it does not.
• _Explicit discriminators_: you request `NetworkModule.httpClient()`, not just any `HttpClient`. The meaning of a dependency comes from the member's name.
• _Composable modules_: modules are interfaces, so `interface AppModule : NetworkModule, DatabaseModule` just works.
• _Light presence_: your business classes do not know about the modules. `@DIFactory` builds them from a module for you (no more uggly `KodeinAware`).
• Bindings are values, with native support for suspend bindings, extension and overwrite, and per-module scoping.

Inara is also opinionated, which is the biggest change in philosophy: *no mutable modules, no global modules*. With Kodein, I wanted a "universal" tool, and I made concessions along the way (especially by adding new behavior every time I was asked to). A good tool is defined as much by what it does not do as by what it does. In short, I want to write code that is, in order of importance, correct, isolated, idempotent, and only then easy to write.

That is why we see more future in Inara: Kodein was my first library, and Inara is the one I would write today.

*Links*

• <https://kodein-koders.com/en/blog/inara-inject-your-dependencies-at-compile-time/|Announcement article: Inara: Inject your dependencies at compile time>
• <https://github.com/kosi-libs/Inara|Inara on GitHub>
• <https://kosi-libs.org/inara|Inara documentation>

*Moving to Koin*

If you like how Kodein worked and how it architected your modules and applications, we warmly encourage you to migrate to Koin. It supports everything Kodein does, and much more, with better optimizations and integrations. Here is a guide to get started: <https://blog.insert-koin.io/introducing-the-koin-migration-skills-0b4be9c819cc|Introducing the Koin migration skills>.

*Thank you*

A heartfelt thank you to every developer who trusted us with Kodein DI over the years: for using it, for reporting issues, for your contributions and for your patience. Kodein exists because of you, and we are very grateful.

I would love to hear what you think of Inara. Questions and feedback are very welcome in this channel!

Do you have an idea on timeline to reach a 1.0 release?