Damn man, when you guys have discussions like this...

# arrow

[Tim Fennis]

Damn man, when you guys have discussions like this I feel so dumb

[pakoito]

Not dumb, it takes time to get there. Took me months just to get started, and doing some of the implementations in Arrow to fully understand. You’ll get there!

[raulraja]

Agreed with @pakoito and also @Tim Fennis feel free to ask anything about any term or concept that isn't clear and we'll do our best to make it more approachable

[Bob Glamm]

I've been attempting to understand it off and on for a couple of years and still haven't quite gotten there yet. If Kotlin was my day-to-day work (instead of Java) I think it would go faster. The good news is that the concepts readily transfer between Kotlin/Arrow, Scala/Cats, Haskell, OCaml, etc.

[Tim Fennis]

I read “Learn you a Haskell” and it really helped me understand this stuff a lot better. But it doesn’t get you much further then using Maybe and some basic IO stuff. Don’t really know where to go from here.

[pakoito]

using IO you can write imperative-looking code by making everything a do block

[pakoito]

or in Kotlin terms, suspend functions and fx blocks

[pakoito]

and that's enough to be productive using parallelization, thread jumps and such

[Bob Glamm]

I think I'm with Tim on this. There's a gap between basic structures and "hey, implement this web back-end that processes HTTP requests and does CRUD- and complex-level database work, maybe with some scheduled jobs in the background"

[Bob Glamm]

That's part of the reason I asked about type interop between Scala/Cats & Kotlin/Arrow. Some of these libraries (like http4s, fs2, monix, doobie) already exist as useful functional libraries but are not strictly in the Kotlin/Arrow ecosystem

[pakoito]

@Bob Glamm how would you write those with Rx?

[Bob Glamm]

I wouldn't 😄

[Bob Glamm]

mainly because I'm not a fan of Rx

[pakoito]

request flatmap parse map to domain model flatmap domain operation flatmap response to server

[pakoito]

all in a loop

[Bob Glamm]

I mean, I get your point - it's relatively straightforward to (say) wrap something like ktor, but to abandon purpose-built and tested things seems silly

[pakoito]

purpose-built here on top of suspension

[pakoito]

and arrow gives you the extra tinker bits for threading and error handling for a ny suspending function

[pakoito]

some transformations and helpers here and there for atomic references and such

[Bob Glamm]

Sure, if I'm using an Rx-based framework

[Bob Glamm]

or want to wrap in Rx

[pakoito]

any framework, we have support for suspend, rx, reactor, and bring-your-own

[Bob Glamm]

That's a lot of wrapping/unwrapping, though. If I have seamless type interop then I can (for instance) use http4s and doobie seamlessly instead of wrapping/unwrapping from Reactor + Spring

[Bob Glamm]

I have to think that interop with Reactor is more overhead than the proposed interop with any functional type

[Bob Glamm]

But tell me if I'm wrong on that!

[pakoito]

my point is, when using ktor, what's your carry type

[pakoito]

how do you jump around threads and parallelize and such

[pakoito]

it isn't single-threaded

[pakoito]

and whatever machinery you use, we support and enhance all of them

[Bob Glamm]

sorry, I'm not familiar with the term "carry type"

[pakoito]

Observable, Flowable, Flux, suspend fun, IO

[pakoito]

deferred, launch

[Bob Glamm]

ahh, ok, Google yielded "Conceal Carry permit types" when I searched for that. Thanks, American Google!

[pakoito]

lol