Wow I'm not a fan of the "changing grain of Kotlin" This is their example of "the ideal situation that we doesn't exist in Kotlin", where Arrow 1.0 is almost character for character that, and Arrow 2.0 is even shorter to write without needing wrapper types.

Hmmm... just started watching this as well. I agree with you. either { ... } or effect { ... } comprehensions with some additional .bind() calls (instead of <-) works well in Arrow.

And that's in 1.0! In 2.0 you don't even need

bind

in this example, nor the wrapper return type:

context(Raise<Error>)
fun handlePost(request: HttpRequest): HttpResponse {
    val json = request.readJson()
    val command = json.toCommand()
    val resource = loadResource(request)
    val outcome = performCommand(resource, command)
    outcome.toHttpResponseFor(request)
}

Right! With context receivers, that is no longer needed... But that is still experimental (context receivers) 🙂

Sure, it's experimental, but you can't make a talk about "this is not possible in Kotlin", when 1) a major library has been doing this for years, and 2) they have an experimental version that's even better

Maybe they get to Arrow later, when circling back to the 'grain' with the new 'context' receivers

…let's see what they say.

Patience is a virtue 🙂

Oh, so they do know everything they've said is wrong?

I don't think so... in the beginning they assumed something like Arrow didn't exist and circled back to where it does.

They did spend 10 minutes saying it's not possible, including libraries

Not sure... I thought they meant some of the constructs would go against the 'grain' of the language. But I'd need to rewind a bit for confirm this 🙂

Oh, so they're selling a book

I bought the book a while back. Haven't read it yet so can't comment on the content, but Duncan's videos are actually kind of interesting and he's obviously a skilled craftsman. Unfortunately he doesn't seem very immersed in the Kotlin ecosystem. He did a video on property testing without mentioning Kotest for instance, which hurt a bit 😁

Compare to Kevlin Henrey's talk right now, which started by "I'm not a Kotlin guy" (not: "I'm going to show you what's idiomatic in Kotlin"), which has examples with pretty good Kotest usage

I've read the book and thought it was great. But I felt that "Some other result libraries would let use abuse coroutines (...) to get the same effect as the earlier early returns (...)" (p. 342) is a take on Arrow. I love Duncans videos - especially the latest with Lukas Eder of JOOQ - but I would really like to know, if he has seen the latest Arrow API and if he thinks, that this is abusing coroutines and why so.🤔 BTW didn't get to see the talk, but will do once they're uploaded.

@Oliver Eisenbarth You can find that video here:

I would really like to know, if he has seen the latest Arrow API and if he thinks, that this is abusing coroutines and why so

Considering the KotlinX.Coroutines team themselves have praised Arrow for their inventive usage, I wouldn't say it's abuse

Just watched it myself to see if what you are saying is true. They made a comment about using option instead of nullables because... Monads. Literally not what arrow is suggesting, at least not anymore. Talking about ever increasing indent using arrow. Again, solved with

either {}

and the likes. And a comment that said "bending language features to find a way to achieve the goal" which I assume they meant what Oliver mentions above. What a weird experience to watch that talk as someone who does actually use arrow and the latest APIs. The problem is that for someone who doesn't, they may just watch this and think "oh okay, so let's not use Arrow then". That was definitely not fun to watch. I guess our best place for feedback is the kotlinconf app which let you write a comment about each talk.

They also seem to be strongly anti-coroutines, and... Well I don't think there's anything more idiomatic than coroutines, short of the standard library?