what does suspend have to do with it

# arrow

[sam]

what does suspend have to do with it

[raulraja]

Suspend enforces error handling to be controlled by IO instead of blowing up uncontrolled. When you do suspend you have guarantees that all your exception handling is surrounded by the IO continuation allowing you to recover from it and it guarantees this all the way up to the place you call runBlocking or similar whereas in normal functions that is not the case.

[sam]

I suppose I meant that a.map { throw Exception() } is just as bad as a suspend that throws an exception. But I'm getting more interested in this IO and why I should use it. I guess to me suspension is a key part of the kotlin platform and so I am intrigued as to why fx is a better solution. Is there a write up somewhre?

[raulraja]

fx is not a better solution because it builds on suspension. Suspension in Kotlin just defines some basic stuff int he std lib like startCoroutine. The CoroutineX core is a entire separate lib for async and concurrent. The base of suspension is Kotlin effects system which any lib can use to model its own effects and async/concurrent stuff. What I mean to say is that Fx does not compete with suspension because it uses suspension if anything it would compete with Coroutines Core

[sam]

Sorry yes I am conflating coroutines and suspension, although I know that's not the same thing.

[raulraja]

So Arrow Fx rethinks concurrency, async and controlled effects in a pure FP way in contrast to Coroutines Core which has other design goals

[sam]

Yes, that's what I thought. I'd like to know why it's better and how easy it it is to use (easy in the sense of syntactic overhead)

[raulraja]

it has the same syntactic overhead as coroutines core except effect which forces you to deal with effects. Cancelation is automatic in Fx and cooperative in Coroutines Core and Fx can guarantee safe resource acquisition and release despite async boundaries and cancelation because it uses a lazy always model whereas in Coroutines core the model is eager

[raulraja]

so they fire by default immediately like Scala futures

[raulraja]

and we hold back until the last moment

[raulraja]

so we can then state all IO functions are pure and composable without fear because they always represent delayed programs that run as a whole single composition (unless you call unsafeRun)

[sam]

Ok

[sam]

Is this available in 0.9 or in 0.10

[raulraja]

It;s already available but we are making it a lot better in 0.10

[raulraja]

so far the available docs are https://arrow-kt.io/docs/effects/fx/

[sam]

ok thanks

[sam]

time to read

[raulraja]

including a bunch of examples for async and concurrent stuff https://arrow-kt.io/docs/effects/fx/async/

[sam]

I assume then that in 0.10 or at some point in the future, arrow is going to go "pure functional" in the sense of a lot of stuff won't work with suspend anymore (like we've been discussing)

[raulraja]

yes and in addition we are adding a compiler plugin that tracks function purity so it lets you know when you are doing nasty stuff outside of suspend such as making blocking IO calls or in general anything that returns unit or throws exceptions (opt in)