https://kotlinlang.org logo
Title
h

Hugo

03/24/2023, 2:21 AM
We’ve just open sourced Quiver, a library that extends functionality provided by Arrow. Feedback, issues, and pull requests welcome ❤️
j

jem

03/24/2023, 3:47 AM
We've been using this internally since mid-2021 and finally took the time to open source it.
s

stojan

03/24/2023, 8:41 AM
interesting
any reason you are not using nullable types instead of option?
d

David

03/24/2023, 9:06 AM
It would be great to see some examples of you use quiver and the benefits of it.
j

jem

03/24/2023, 11:16 AM
We do use nullable types in small, isolated cases. But, perhaps speaking for myself here, I appreciate the readability of a monadic type. It's valuable that both union and optional types have the same look and feel.
Opening Quiver was the first step in hopefully opening up other libraries that use it, so hopefully we can provide examples then.
f

Fred Friis

03/24/2023, 4:11 PM
my team also prefers Option to Kotlin's nullable types. Option is much more clear and idiomatic FP than Kotlin's kind of not great implementation of nullable types. Granted, Option.map and flatMap and nullable type ?.let{} are functionally equivalent but the former just reads so much better, and we want not just functor and monad but applicative as well, no? Eg given a List<Option>, we can use applicative to declaratively and with referential transparency etc etc (you know the usual FP sales pitch) turn it into an empty list if it contains a single non-populated option, or a list of Foo if all options in the list are populated. With Kotlin nullable types I don't think you could do it as declaratively and elegantly. Actually, even if you could, it's kind of beside the point... To me, the point is, Option has been designed from scratch to be an FP style Maybe type with all that comes with that in terms of it being a functor, applicative functor, monad etc etc whereas while Kotlin nullable types in some ways are functionally equivalent, a nullable type doesn't implement a Functor interface, or a Monad interface, or an Applicative interface, and when it behaves like it does, it's mostly kind of by accident driven by a pragmatic need, not any real understanding of reusable, lawful FP abstractions. (from an old thread discussin this at https://github.com/arrow-kt/arrow-core/issues/114)
d

dave08

03/26/2023, 6:44 AM
@jem Do you have anything for the alpha versions (or the upcoming 1.2.x/2.0?), this library seems very interesting, but we're currently using the Arrow alpha... which changed a lot.
h

Hugo

03/26/2023, 6:47 AM
@dave08 a WIP PR has been raised by @simon.vergauwen to support 1.2.0 https://github.com/cashapp/quiver/pull/26
s

simon.vergauwen

03/26/2023, 5:52 PM
I am personally surprised by the heavy use of Option, but I've recently also encountered some issues due to nested null in generic code 😅 It even resulted in me making 2 bug fixes against them in Quiver. I'm looking forward to working together with the Quiver team to facilitate all usages, so that we can solve everyones needs together for FP in Kotlin. To that end I'd love to get feedback on my questions, and remarks in the PR shared by @Hugo. Also, we plan to release 1.2.0-RC at the end of this week with the final deprecations to 2.0.0. It will be more clear in the deprecation message, and in the release post but I am inviting all of you already to check it out (or do so on an alpha versions) and let us know if any of the APIs critical to you are being deprecated. So we can consider moving them to Quiver, or can keep/move them in Arrow-core if the community consider them core to fp in kotlin_._ The release post wil also explain the rationale of why some APIs are being deprecated. We care about the success of functional programming in Kotlin, and is also why we kept
Option
around when it was originally marked for deprecation pre-1.0.0. (Thanks to a discussion started by @mitch at the time🙏). Thanks in advance all for your support of Arrow and FP in Kotlin ❤️ :kotlin-intensifies-purple: :arrow-intensifies: