<https://link.medium.com/Ys8QmOVWUjb> After reading this article I feel Kotlin should have supporte...

# feed

[nilTheDev]

https://link.medium.com/Ys8QmOVWUjb

After reading this article I feel Kotlin should have supported DI natively in the language. Any thoughts?

[uli]

Some features can very well be implemented ontop of a language.
The Kotlin designers are exceptionally good at finding the minimum required language support to enable higher level libraries to enable modern software development.
Coroutines is a perfect example here. The kotlin compiler comes with one feature for coroutines: suspend functions. Ontop of that there is very slim support in stdlib. Every thing else (async, launch, produce, …) comes as an extra package. Not part of the language while other languages like C#, JavaScript, … have e.g. async as a language feature, adding extra complexity to the core language.

[Fleshgrinder]

It's the old batteries included discussion. There's no right or wrong here, it's a design decision. Kotlin and Rust are going down the no batteries included road and try to provide an extensible language that allows anyone to extend the language in any direction. Personally I prefer this route. Go and Python are on the other side of the spectrum.

[mikehearn]

Avaje Inject provides a very nice DI library using source code generation/kapt. The latest versions make me think there's not much for language integration to add.

[Javier]

it is not kmp

[mikehearn]

No, it's a Java library. If you want to make native binaries with it you'd need to use GraalVM, or run the generated code through j2k

[mikehearn]

(I personally don't have much interest in KMP for this sort of reason - too many useful libs that aren't available and you can make native binaries in other ways)

[Matteo Mirk]

the most “no batteries” of all languages has always been LISP 😉