i have an android kotlin project that relies heavi...

# arrow

[liminal]

i have an android kotlin project that relies heavily on rxjava. as far as a kotlin projects go, it’s using a lot of FP constructs (stream manipulations, immutability is important, etc.) do you think throwing arrow-kt in the mix would be helpful? does anyone successfully use this combo?

[pakoito]

Arrow doesn’t provide a solution for streams yet, so Rx is not replaceable in this case.

What it can improve is using coroutines with rx, so your code is cleaner https://arrow-kt.io/docs/integrations/rx2/#observable-comprehensions

[liminal]

Thanks, Paco. Not using coroutines and I am happy with rxjava for now. Was just wondering how arrow could add to the overall ‘doing things functionally’ to avoid race conditions etc.

[pakoito]

So, on the big scale, your architecture depends on what we’re calling “effects”. Meaning state, network requests, painting UIs, etc. Using an Rx architecture end2end, something like MVI, already gives most of the benefits of FP: immutable values, cross-thread operations, and streams avoid races depending on how you combine them. See the FunctionalAndroidReference project I made years ago: https://www.pacoworks.com/2017/03/11/about-memory-management-in-fully-reactive-apps-at-droidcon-bytes-february-17/ https://www.pacoworks.com/2017/03/16/headless-development-at-mobos-librarymaking-updates-and-plans-for-2017-2/

What Arrow can give you, if you’re already using Rx like that, is a collection of APIs to work with data on the small. These are Option, Either, the extension functions for collections, and sub-libraries like Optics or serializing JSON with Helios. These help you doing transformations such as List<Observable<A>> to Observable<List<A>>, or modifying a deeply nested POJO field that’s contained in a list of POJOs of a parent type and so https://arrow-kt.io/docs/optics/dsl/#each

[pakoito]

basically operations that are an extension of the standard library

[pakoito]

another example would be the Arrow Query Language: https://arrow-kt.io/docs/aql/intro/

[pakoito]

which as you can see it’s like LINQ or SQL-for-collections

[pakoito]

in the future we’d like to have a streams library that’ll be accompanied with a set of interfaces that describe how all stream libraries work. We currently have them for “single result” APIs such as rx.Single, for Project Reactor, kotlinx.coroutines, and our own implementation.

[pakoito]

that way you should be able to just use the interfces and swap the implementation at will, so it’s easier to migrate between version 2 and 3 of Rx, or Reactor on the backend, or kx.coroutines

[liminal]

Thanks a lot, Paco! Tons of useful advice here

[raulraja]

James, Arrow can help you bring imperative syntax to all your flatMap style transformations through the use of binding

[raulraja]

many people use Arrow with Rx or Reactor framework and bind over compositions of observables or other IO like data types using binding

[thanh]

Hey Raul, can you please post a gist or code snippet about using bind over compositions of observables? It sounds interesting for me. Thanks!

[pakoito]

@thanh https://arrow-kt.io/docs/integrations/rx2/#observable-comprehensions

[thanh]

Thanks Paco!