Arrow 2.0

[serras]

This is a PR to track breaking changes to be included in Arrow 2.0.

Proposing new changes

If you would like to propose a feature or change for inclusion in Arrow 2.0, you can either:

• Open a PR against the arrow-2 branch,
• Create an issue tagged with "Arrow 2.0".

One of our goals is to make Arrow simpler to use, so you should expect some amount of discussion for new or breaking APIs.

Breaking changes

• Remove Validated and move methods to Either<NonEmptyList<E>, A> ⇨ Feature/remove validated #2795
• Remove parTraverseXXX variants, and add parMapAccumulating⇨ Introduce parMap and deprecate parTraverseXXX #2863
• Rename parTraverse to parMap ⇨ Introduce parMap and deprecate parTraverseXXX #2863
• Removals ⇨ PR: Remove Tuple10 to Tuple22, Const, Eval, computation blocks, and arrow-continuations #2784
  • Reduce Tuple22 to Tuple9
  • Remove Const and Eval
  • Remove deprecated computation blocks
  • Remove arrow-continuations
• Separate CircuitBreaker and Schedule into its own package ⇨ PR: Arrow Resilience #2885
  • Breaking changes to CircuitBreaker and Schedule
• Implement a new API for Effect based on catch ⇨ PR: [Arrow 2.0] Effect without suspending shift #2797
• Bring documentation up to date
• Clean-up Resource ⇨ PR: Clean-up Resource for Arrow 2.0 #2786
• Returning Nothing from shift instead of being polymorphic #2810 (comment)
• Simplify optics hierarchy to Traversal/Optional/Lens/Prism ⇨ PR Simplify optics to Traversal/Optional/Lens/Prism #2873
• Remove test modules ⇨ PR Remove test modules #2874 (backported to 1.1.4)
• NonEmptyList is now a value class ⇨ PR Implement NonEmptyList using value class #2911
• Remove deprecated methods in Either and Ior
• Remove deprecated Semigroup and Monoid

Migration

• Migration script for changing imports for breaking APIs if the signatures are compatible

Exploration

• Review API to see what we can skim of the public API
  • Either#replicate, Either#find, etc.
• Explore making Effect<E, A> a typealias for suspend Shift<E>.() -> A ⇨ [Arrow 2.0] Effect without suspending shift #2797
  • Rename Shift to Raise (or CanFail) based on user feedback
  • Add recover API for Option & Ior and catch for Result.

PRs closed without merging

• Boxing-free Option type ⇨ PR: value class impl of Option (called Maybe) prototype #2780
• Explore the use of context receivers ⇨ according to [PROPOSAL] Effect as typealias #2782 (comment) this should not be followed, since context receivers are not supported in Kotlin Multiplatform
• Review padZip variants when Kotlin zipAll gets into Kotlin Sttd #2483 (zipAll hasn't made it yet to the standard library)

[lenguyenthanh]

Should we set the minimum version of Kotlin for v2.0, so we know which features we can includes to v2.0. I believe should mostly include stable kotlin features.

[kyay10]

Draft PR for Boxing-free Option type: #2780. That PR is for Arrow 1.x though because it includes Deprecated functions and functions for Validated and Effect etc, so I'll make another PR against Arrow 2.0.

[nomisRev]

@lenguyenthanh that is a great suggestion!
I’m sure we’d all love to use newer features, but we need to prefer stability for downstream libraries and projects. It’s important for long term success.

We should probably prefer releasing major versions in the future to adopt new language features such as context receivers, or sealed value classes.

I suspect development of Arrow 2.0 will take quite some time, so 1.7.x or maybe 1.8.x could be a good candidate. Or should libraries prefer older versions? Is there any documentation oriented for library authors that you know of?

[nomisRev]

@kyay10 thanks for taking the time for making the PRs, and doing the investigation 🙏

[serras]

@lenguyenthanh @nomisRev I would suggest targeting the 1.7 series of the compiler, so we can make use of the new context receivers. As you point out, maybe when we release Arrow 2.0 an ever newer version would have come out, so I think that’s a safe bet.

[Atternatt]

@nomisRev @serras I asked the Kotlin channel for an estimation of the official release of context receivers. They estimate the release in Kotlin 1.9

[Atternatt]

would it make sense create streamable object like Kotlin flows but with Either or Validated behaviors and operators? (perhaps it's a stupid question)

[codependent]

I'd like to bring up the possibility of offering a high level class like Scala's ZIO to model an effectful program. What do you think about it? Does it make sense in the context of Arrow?

[nomisRev]

Hey @codependent, thanks for the suggestion. Is there any reason or use-cases that you would prefer a ZIO data type over what currently is possible in Kotlin with Effect + suspend + Kotlin/Arrow Fx Coroutines ?

I don't think a class like ZIO makes sense in Kotlin (unrelated to Arrow) because the philosophy of Kotlin is to build independent features that should conveniently compose together, and therefore there is no need to implement concrete classes to combine different concerns. I.e. KotlinX Coroutines takes the same approach with Structured Concurrency and its API.

For example the equivalent of ZIO#parZip.

object Error

fun one(): Effect<Error, Int> = effect { 
  delay(100)
  1
}

effect<E, A> {
   parZip(
     { one().bind() },
     { one().bind() }
   ) { x, y -> x + y }
}.fold({ fail("Never results in Error") }, { println(it) }) // 2

We can easily nest parZip inside effect, and effectively "mix" their abilities. Afaik ZIO offers their model because it aims to provide a simpler model to monad transformers, an issue which we don't have here.

When Kotlin releases context receivers, you can also drop the Effect return type completely as well (including other wrappers in the return type). Resulting in clearer code and more Kotlin idiomatic code, with very little APIs you need to learn.
This model also covers all use-cases that ZIO covers, and solves all issues that ZIO aims to solve.

[codependent]

When Kotlin releases context receivers, you can also drop the Effect return type completely as well (including other wrappers in the return type). Resulting in clearer code and more Kotlin idiomatic code, with very little APIs you need to learn. This model also covers all use-cases that ZIO covers, and solves all issues that ZIO aims to solve.

@nomisRev I was suggesting it since the only aspect that bugged me (just a little bit) is that Arrow offers different monads (Either, Validated, Option...), that usually are present in the return types of the business services, forcing us to convert (transform) them from one to another in our logic definition. ZIO's approach differs in which it aims to provide a One-Monad-For-All and define the program logic just based on it.

I misunderstood the introduction of the Effect runtime as way to move to an Arrow "super monad", but as you kindly explained that wasn't necessarily the case.

In any case, as you pointed out, context receivers will definitely make our Kotlin code more idiomatic and clearer and Arrow isn't really missing anything feature-wise compared to ZIO. Thanks for your explanation.

[nomisRev]

@codependent maybe as a clarification on the StackOverflow answer (and let me know if you think I should update my answer accordingly).

I misunderstood the introduction of the Effect runtime as way to move to an Arrow "super monad"

Effect offers a way to move to a "super monad", as it's the most abstract implementation. However, Arrow doesn't force you to use Effect.

We suspect there are many people in the Kotlin community that would rather work with suspend fun myFunction(): Either<MyError, A> rather than:

context(EffectScope<E>)
suspend fun myFunction(): A

Given that both are isomorphic to each-other there is no strong technical argument to which is better.

the only aspect that bugged me (just a little bit) is that Arrow offers different monads (Either, Validated, Option...), that usually are present in the return types of the business services, forcing us to convert (transform) them from one to another in our logic definition.

With Arrow 2.0 we want to streamline this more. Reducing the API surface, and optimising for the context(EffectScope<E>) case since the Either users will also benefit from that. Hence also the tasks to remove Validated, and other redundant data types for Arrow 2.0. As a way of unifying duplicated use-cases between different data types. This should improve your frustration with the different monads. So I am looking forward to your feedback when we're making such changes. If you're interested I can tag you in relevant PRs (If I don't forget 🙈).

[codependent]

@nomisRev I’ll be glad to have a look at those changes. Apart from those small details, Arrow is a fantastic library that improved noticeably with each version, congrats for the awesome work 👍

[nomisRev]

Here it goes @serras @kyay10. If everything blows up.. just point at me :D

[nomisRev]

Did you experience problems with the build again @serras ?

[nomisRev]

@serras this was my fix, d5b188c. It's super weird this started failing..

I would not go for this fix, this has a nested checkAll so this runs 1000x1000=100_000? 🤔

cc\ @kyay10