Wow I'm not a fan of the "changing grain of Kotlin...

# arrow

[CLOVIS]

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.

[CLOVIS]

It's really weird to me to do a talk on functional error management in Kotlin without even being aware of Arrow.

[streetsofboston]

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.

[streetsofboston]

Maybe they will still get there later in the talk 🙂

[CLOVIS]

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)
}

[streetsofboston]

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

[CLOVIS]

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

[CLOVIS]

Great, now they're complaining about the lack of typeclasses, using almost exactly the example used by the context receiver KEEP

[CLOVIS]

So they do know about KEEP-87 and context receivers, but don't know about the library which is more or less their origin?

[streetsofboston]

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

[streetsofboston]

Ah... hahahahaa just when I pressed the enter key 🙂

[CLOVIS]

…let's see what they say.

[CLOVIS]

"Trying to say we should use optional instead of nullable" → the optional documentation literally says the opposite

[streetsofboston]

Patience is a virtue 🙂

[CLOVIS]

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

[streetsofboston]

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

[CLOVIS]

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

[streetsofboston]

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 🙂

[CLOVIS]

Oh, so they're selling a book

[CLOVIS]

"Everything will change, be worried, buy our book!"

[CLOVIS]

After spending 30 minutes saying things that are just wrong?

[Emil Kantis]

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 😁

[CLOVIS]

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

[CLOVIS]

It's actually impressive how the "changing grain of Kotlin" talk has an opposite conclusion to almost the entire conf (on error management, on Loom vs Coroutines, on testing…)

[Oliver Eisenbarth]

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.

[streetsofboston]

@Oliver Eisenbarth You can find that video here:

https://www.youtube.com/watch?v=03T-ARIo0t8&amp;t=25880s▾

[CLOVIS]

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

[CLOVIS]

And stuff like the Resource plugin or Saga are literally the spirit of structured concurrency

[Stylianos Gakis]

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.

[CLOVIS]

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?