Hi <@U025VMN369X> , Arrow’s ecosystem is currently...

# arrow

[raulraja]

Hi @Jascha Smacka , Arrow’s ecosystem is currently the same as KotlinX Coroutines or Kotlin in general since it embraces suspension and continuations. This means you don’t need to choose libraries specific to Arrow for other purposes like serialization, persistence, you could just use for example KotlinX serialization, Exposed or any other libraries that integrate with suspend fun.

There are no ambitions to compete against those as in most cases they are purely functional or offer a means to just use suspension which is equivalent as being wrapped in IO[A] plus the additional powers like direct syntax that continuations offer natively.

In contrast to other langs like Scala where there is no native IO and most FP programs are written depending on heavy frameworks here instead we just rely on suspension. This means that if you want to make a library compatible with Arrow, you could definitely use Arrow to build and provide utilities like Either, comprehensions, parZip etc but if your library does not need those and you just use suspend fun for all IO related ops then it’s still compatible 100% with arrow and the rest of Kotlin’s libraries.

In Scala and others the discipline is about writing code over F with the type class abstractions these libraries provide or sticking to the boxed data types framework like Zio pack.

In Arrow the discipline is just use suspend fun when you need to perform IO or anything that need to be effect protected.
IMO Kotlin already has better dependency injection and support for FP interoperability of libraries and programs through receiver funs, inline and suspension (eliminating transformers), compiler optimized continuations and soon multiple scoped functions which in my opinion cover most of the features you find in other Scala libraries in a boxed form, here in a more performant and ergonomic syntax.