Search code examples
kotlinfunctional-programmingarrow-kt

Why use Arrow's Options instead of Kotlin nullable

I was having a look at the Arrow library found here. Why would ever want to use an Option type instead of Kotlin's built in nullables?

Solution

  • Disclaimer: If you really want to have a detailed talk about why Arrow is useful, then please head over to https://soundcloud.com/user-38099918/arrow-functional-library and listen to one of the people who work on it. (5:35min)

    The people who create and use that library simple want to use Kotlin differently than the people who created it and use "the Option datatype similar to how Scala, Haskell and other FP languages handle optional values".

    This is just another way of defining return types of values that you do not know the output of.

    Let me show you three versions:

    nullability in Kotlin

    val someString: String? = if (condition) "String" else null

    object with another value

    val someString: String = if (condition) "String" else ""

    the Arrow version

    val someString: Option<String> = if (condition) Some("String") else None

    A major part of Kotlin logic can be to never use nullable types like String?, but you will need to use it when interopting with Java. When doing that you need to use safe calls like string?.split("a") or the not-null assertion string!!.split("a").

    I think it is perfectly valid to use safe calls when using Java libraries, but the Arrow guys seem to think different and want to use their logic all the time.

    The benefit of using the Arrow logic is "empowering users to define pure FP apps and libraries built atop higher order abstractions. Use the below list to learn more about Λrrow's main features".