A modern programming language that makes developers happier.

kotlinlang

How is the recommended typeclassless DI technique different from the not-recommended Cake pattern from Scala?  Swap out extension functions for regular ones, and are they basically the same?

traits in Scala are not like Interface conformance by delegation. Traits can have initialized fields and they get linearized to support the illusion of multiple inheritance because they support backing fields. That is what it’s conversome about cake. Cake suffers from initialization order and any issues about lazy properties. In the JVM you have to guarantee all superclasses are initialized before your class.

DI with extension functions is like wiring with implicits in Scala

in Kotlin you don’t need Reader, etc because you have top level extension functions that can scope the context without function composition, the compiler provides the implicit receiver that can be constrained by subtype bounds  to express whatever you want to depend on where the finale module satisfies all deps.

Thanks for your detailed explanation <@U4UGS5FC7>.

I think you're saying that typeclassless DI avoids the problems of Cake DI because interfaces that group extension functions together, and on which the final modules depend, are prohibited by Kotlin from containing property initializers.

In contrast, the problems of Cake DI stem from this very ability to have initialized fields in traits, leading to complexities of trait linearization and field initialization order.

Have I understood you correctly?

additionally is more than the notion of typeclasses it’s implicits

Most people in Kotlin dislike the word implicit because of the Scala history of complexities but receiver functions or extension functions are functions with one implicit argument that is polymorphic and can be materialized at use sites

So the lang already supports through extension functions, suspensions and nullability and ultimately delimited continuations simple DI and monadic idioms than nested Haskell or Scala

It’s the biggest issue with all FP devs coming to Kotlin and I went through that too, replicating the unergonomic haskell and scala style, but we learned from those days.