Hi, I went to a KotlinConf Global event and since ...

# arrow

[Oliver Eisenbarth]

Hi, I went to a KotlinConf Global event and since I wore my Arrow shirt, I got to talk a lot about Arrow.😁
One guy from the local Kotlin User Group told me, that the last thing he'd seen was using suspense instead of IO and that he felt, that this was "abusing coroutines". Tough I've heard this before, I didn't now how to refute this. Have you come across people who feel that Arrow is "abusing the coroutine mechanics". If so, what did you say?

[Youssef Shoaib [MOD]]

It's not anymore. Raise now operates solely using CancellationException, nothing coroutine based at all.

[raulraja]

Arrow works over the notion of continuations in some of the FX lib and concurrent parts, which in Kotlin are implemented via CPS compiler support + coroutines library.
Arrow is about functional programming in Kotlin and not specifically tied to any given technique or school of thought such as those that think that the encoding should be done with Haskell style type classes.
Arrow uses the tools in Kotlin to provide the same level of control over effects by using effect scopes, context receivers and other tools that are more idiomatic in the Kotlin language.
There is a group of functional programmers out there that think that if you don't follow an indirect function based approach and the haskell typeclasses it's not functional and I think that is far from what we are experiencing. 🤷

[streetsofboston]

But I looooove my Monads!!! Where are they?
🙂 😛

[raulraja]

here -> ;

[raulraja]

In a lang where each statement means order of execution ; or implicit ; is flatMap and we have the context scopes that give us the monadic context from which we can exit the continuation with a value. Monads are still there and useful but they are no longer constrained by having a method called flatMap that takes a higher order function to advance. We can still achieve the same with context blocks or context receivers.

[raulraja]

For a more in depth comparison of the style we follow, not just in Kotlin but where Scala is headed I recommend https://twitter.com/raulraja/status/1646582715490205696

[streetsofboston]

(i was being sarcastic 🙂 Love Arrow!)

[raulraja]

There Odersky shows how Scala's new direction is the same foundation Arrow has been using

[raulraja]

@streetsofboston took it that way 🙂 just wanted to share some thoughts

[raulraja]

boundary/break there is the same as effect/raise

[raulraja]

Label -> Raise

[simon.vergauwen]

“Suspend instead of IO” 🤔 but isn’t that precisely what’s meant for 🤯

Arrow doesn’t impose in any way that you need to mark side-effects with suspend, it’s just something that a lot of us like doing because in 99,99% of the cases you want (or need) suspend there anyway at some point in your application.

If he meant it in the sense that Arrow uses Kotlin Coroutines for other things than KotlinX Coroutines, that is exactly what’s meant for. There was a talk about it on KotlinConf, and Kotlin Std also does it in a bunch of places.

There are a quite some miss conceptions out there by either bad experience from “pre 0.12.x”, or from people that have bad memories from other languages and communities.

But there is also a lot of love, which is what counts 😊

[Oliver Eisenbarth]

Thanks everyone! I think I can prepare some arguments for the next time that happens from your answers.🙌❤️

[Oliver Eisenbarth]

Arrow doesn’t impose in any way that you need to mark side-effects with suspend, it’s just something that a lot of us like doing because in 99,99% of the cases you want (or need) suspend there anyway at some point in your application.

TBH I think don't understand that fully myself. Are you saying, that the examples on the documentation page "working-with-typed-errors" that are suspended also could be not? Is moving from

fun Raise<UserNotFound>,user()

to

suspend fun Raise<UserNotFound>.fetchUser(id: Long)

only a coincidence? Sorry for my dumb questions. 🙇‍♂️

[Youssef Shoaib [MOD]]

Theoretically the code could just be blocking. Suspend basically provides the same guarantees as IO. That's btw new since before Raise was EffectScope and it was coroutines-based, but it isn't anymore (that might be the source of those criticisms).

[simon.vergauwen]

That's btw new since before Raise was EffectScope and it was coroutines-based, but it isn't anymore (that might be the source of those criticisms).

This wasn’t entirely the case since there was also EagerEffectScope with @RestrictSuspension.

So it didn’t require suspend, but a separate DSL.

[Youssef Shoaib [MOD]]

That would've made fun EagerEffectScope<...>.fetchUser still suspend though, no? The difference is that it'd be restricted suspension.

[simon.vergauwen]

Yes, but the same is true for https://github.com/JetBrains/kotlin/blob/f810d435f4169f911e2d47f9a6bf38adc407c025/libraries/stdlib/src/kotlin/collections/SequenceBuilder.kt#L53. So I don’t think that counts as abuse, there was an talk on KotlinConf on how Kotlin Coroutines goed way beyond KotlinX. For example also, https://github.com/alllex/parsus
Or Cont in Arrow Analysis but it works more similar to Sequence.

[Oliver Eisenbarth]

Thank you very much Youssef, Simon and Raul!
For the FP versed people I will try to paraphrase what Raul said by saying that Kotlin uses idiomatic Kotlin means for the same ends other languages reach via different ways. For others, I'll remember what Youssef said in the beginning and try to argument that coroutines go beyond KotlinX and are not only meant for concurrency. Learned from this, Thank you.