New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task/IO interoperability proposal #1355

Closed
alexandru opened this Issue Apr 12, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@alexandru

alexandru commented Apr 12, 2017

Hi folks,

Right now the Scala ecosystem is noticing a proliferation of IO and Task types for dealing with side-effects. For one because of the (unfortunate) community fork that happened, but also because when speaking of handling side-effects, there's potential for innovation, since there are multiple ways to describe your run-loop and its capabilities. There's also the unfortunate matter of projects having to pick their dependencies and users who suffer from it.

Plus there's always the standard scala.concurrent.Future and Twitter's own Future, that are eager in nature, can't be used for suspending side-effects, being inadequate for describing referentially transparent code, but third-party APIs do expose Future-enabled APIs, which can then be converted to Task / IO.

The Java world actually faced the same problem with proliferation of multiple solutions for streaming, for example Akka Streams, RxJava, Reactor, etc. and came up with Reactive Streams and now Flow in Java 9 (a competing interface probably because Oracle suffers from NIH, but I don't really know).

These APIs, even though they are ugly and OOP, specify a communication protocol meant for middleware that allow users to use their favorite streaming library and still have their stuff working with say web frameworks that understand this protocol, without having to build conversions by themselves, which are always error prone.

I would like to propose a collaboration on something similar, the primary use-case being seamless conversions between types, since that's the number 1 problem that users have when using combinations of libraries.

I have started such a project at: https://github.com/effects4s/effects4s

The goals of the project are:

  1. to describe a bunch of type-classes meant for middleware - this means no fancy operations or encoding or syntax defined, just basic type-classes (currently 5 building up to Async, but can be negotiated)
  2. once 1.0.0 is released, then effects4s-core should be set in stone, thus providing binary backwards compatibility, in addition to being small, making it very trustworthy as a dependency
  • speaking of which, I've set up a different organization with the purpose to allow other people to join as owners if there's interest and if this kicks off I have the intention to provide Sonatype and PGP key access, as to share the maintenance burden; doing this with the sole purpose of achieving interoperability, don't care about anything else

As a visual representation of the hierarchy:

image

Quick links to the (currently) defined type-classes:

(Edit: those laws are not pure, because they need to observe side-effects or non-termination and the purpose is to provide a useful TCK, which is also a good argument for not having such type-classes in scalaz-core)

My hope is to make scalaz-concurrent and scalaz-effect provide Async and Eventual instances for scalaz.concurrent.Task and scalaz.effect.IO. And maybe to and from conversion functions expressed for Task and maybe IO as well, since that's what users want in my experience.

If there's interest, I can submit an initial PR for you to see exactly what this involves. In the project's tests, I'm also describing a Task-like type and so you can see its Async implementation.

Sorry for the long prose. I'm opening this issue to ask if there's any possibility of this happening.

@aloiscochard

This comment has been minimized.

Contributor

aloiscochard commented Apr 12, 2017

I salute the brave and noble effort here!

IIRC @tpolecat had some abstraction over effect in Doobie, he might have some interesting stuff to share with you.

Good luck

@alexandru

This comment has been minimized.

alexandru commented May 24, 2017

Closing due to lack of interest.

@alexandru alexandru closed this May 24, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment