Damn man, when you guys have discussions like this...
# arrow
t
Damn man, when you guys have discussions like this I feel so dumb
☝️ 3
😔 1
p
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!
r
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
❤️ 2
b
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.
t
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.
p
using IO you can write imperative-looking code by making everything a do block
or in Kotlin terms, suspend functions and fx blocks
and that's enough to be productive using parallelization, thread jumps and such
b
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"
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
p
@Bob Glamm how would you write those with Rx?
b
I wouldn't 😄
mainly because I'm not a fan of Rx
p
request flatmap parse map to domain model flatmap domain operation flatmap response to server
all in a loop
b
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
p
purpose-built here on top of suspension
and arrow gives you the extra tinker bits for threading and error handling for a ny suspending function
some transformations and helpers here and there for atomic references and such
b
Sure, if I'm using an Rx-based framework
or want to wrap in Rx
p
any framework, we have support for suspend, rx, reactor, and bring-your-own
b
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
I have to think that interop with Reactor is more overhead than the proposed interop with any functional type
But tell me if I'm wrong on that!
p
my point is, when using ktor, what's your carry type
how do you jump around threads and parallelize and such
it isn't single-threaded
and whatever machinery you use, we support and enhance all of them
b
sorry, I'm not familiar with the term "carry type"
p
Observable, Flowable, Flux, suspend fun, IO
deferred, launch
b
ahh, ok, Google yielded "Conceal Carry permit types" when I searched for that. Thanks, American Google!
😂 2
p
lol