[4.x] Monix's main subprojects (e.g., monix-eval, monix-reactive) should no longer depend on Cats and Cats-Effect

[alexandru]

In outlining the Future of Monix I expressed my dissatisfaction with depending on Cats and Cats-Effect directly.

These have been great developments that benefited users, however, as outlined in the blog post, the dependency meant that Monix 3.x and Cats-Effect 3.x could no longer be used in the same project.

For certain projects, this is inevitable — if you relied on libraries making use of Cats-Effect's type classes, while using Monix's Task, even if monix-eval does not depend directly on Cats-Effect, the upgrade would have been tough regardless. However, that's not the whole story. Projects making use of logic described primarily via Observable and Task could have continued to make use of libraries built for Cats-Effect with only a thin integration layer.

Therefore, the project should no longer depend on Cats and Cats-Effect directly. Monix can provide subprojects meant for integration with whatever type-classes we need.

The downside is having to rely on tooling that suggest the proper imports. Or maybe we could deploy compile-time tricks, see for example this article: No More Orphans.

The upside is that, via this change, it should become possible to support multiple Cats-Effect versions at the same time. If a version 4 of Cats-Effect ever becomes available, we'll be ready for it, while continuing to support the current version.

It's not clear to me what will happen with monix-catnap and with monix-iterant.

I want them both to live, but in order to do so, we may have to either keep the Cats-Effect dependency for them, or to switch to our own type-classes (e.g. TaskLike). So at this point I don't know, all I know is that not having dependencies is a virtue in JVM land, due to the runtime's restrictions (JAR hell).

[Avasil]

It's not clear to me what will happen with monix-catnap and with monix-iterant.

monix-catnap - I think it's too early to say because it depends on what is going to be included in monix-execution but it could be nice to keep cats-effect std in mind: https://github.com/typelevel/cats-effect/tree/series/3.x/std/shared/src/main/scala/cats/effect/std and potentially add things there

monix-iterant - I would suggest not to include it in the initial scope and then think hard if it's worth adding it. It's a cool idea but the "pull" based competition is fierce and I feel like people want streaming libraries with many integrations (message queues, I/O, etc.) which increases the maintenance effort a lot. My take on the Monix situation (and past activity) is that it's probably better to limit the scope as much as possible and avoid direct competition when possible.

[alexandru]

@Avasil I agree with your points.

I don't want Monix to depend on the existence of cats-effect std though, so the stuff in monix-catnap may still have a future, but this needs to be digested.

The issue with monix-catnap is that it provides wrappers for stuff that's in monix-execution. For example, there's an monix.execution.AsyncSemaphore that works with Future, which has a correspondent in monix-catnap, with the underlying implementation reused. I think the Future-based stuff still has value, and if the implementation can be reused, there isn't much effort in supplying implementations for Task / IO as well.

At this point, I'm wondering if we can make monix-catnap not depend on Cats-Effect at all 🤔