`fpdart` / `ZIO` integration?

[SandroMaglione]

Hi @tim-smart

Sandro here (fpdart's author) 👋

I took a look at you ZIO implementation and it looks really promising. I think there is some overlap with fpdart's API (on effects, IO, Task, TaskEither, etc.).

This situation looks similar to fp-ts + effect-ts: fp-ts originally providing IO, Task, TaskEither (just like fpdart), while effect-ts with Effect (ZIO).

I think it could be interesting considering a consolidation of both our implementations (fpdart + ZIO). I really like the ZIO approach:

• One class for all effects (ZIO instead of IO, Task, etc.). This makes easier (possibly) to explain one concept ZIO instead of many different classes
• Easier to maintain (one implementation instead of many similar method in different effects)
• Aligned with effect-ts and ZIO (Scala), possibly sharing some documentation and resources

What I would suggest is a possible integration of ZIO inside fpdart (for a possible v1.0 release?).

@tim-smart what do you think about this? Am I correct about the similarities between ZIO and fpdart's effects? Is there something that the ZIO implementation is missing compared to fpdart's effects?

[tim-smart]

Hi, I'm definitely open to the idea.

Yes - the ZIO type encapsulates all the IO / Task classes from fpdart, as well as ReaderTaskEither.

It is heavily inspired by effect-ts, but it doesn't have the fiber runtime as it would take a lot of engineering effort to maintain - and I don't have the time to do it.

The scope of this project is quite a bit larger than fpdart - probably my only concern. The goal was to provide something that has all you need to build any kind of app. Including:

• Functional programming primitives (thanks fpdart). Mostly for Option / Either, as well as things like Unit and Tuple2
• Immutable data types (from fast immutable collections)
• State management - you can use Ref's for this, as well as the bundled nucleus package (lightweight riverpod)
• ZIO and all the primitives that come with it for implementing business logic

I think fpdart having a more focused scope is probably a good thing, I'm not sure if you would want all this in the project.

[SandroMaglione]

I would keep to scope of fpdart to just the integration with ZIO. This would mean removing the current IO / Task classes from fpdart and replace them with ZIO and equivalent (correct?).

Regarding immutable data types, I had a discussion with the creators of fast_immutable:collections a while ago. fpdart doesn’t aim to provide immutable data types (currently), since it's more focused on core datatypes for fp.

In practice the work would consist in mapping the current IO / Task implementation of fpdart to your ZIO implementation:

1. Remove IO / Task (and derived classes) from fpdart
2. Integrate ZIO inside fpdart
3. Make sure that the previous IO / Task tests in fpdart work the same with the new ZIO equivalents (plus some possible new addition and deprecations/removed methods)
4. Make the new Do Notation work also inside ZIO

You already did a great work with adding doc comments inside ZIO. The very last step would be adding more articles and documentation to allow people to get started with ZIO (and possible migrations from the previous implementation).

What do you think about this plan? Am I missing something?

[tim-smart]

There is also all the primitives that come with ZIO as well, like ZIOQueue, Semaphore, Ref, Runtime, Layer. Were you thinking of merging those in as well?

Some of them probably need a bit more usage to find the best API's.

Do notation is already implemented here: https://github.com/tim-smart/elemental/blob/main/packages/elemental/lib/src/zio.dart#L184

Then there is also the flutter integration package, and the isolate package. I guess it is not quite clear where to draw the line here.

With the effect ecosystem, we have seperated the FP primitives from the Effect library to keep the boundaries clean.

[SandroMaglione]

I would keep Flutter and isolate separate, possibly in another (future) package.

I think I would prefer having fp primitives and ZIO in one place (fpdart), since I generally use them together in nearly all cases. Nonetheless, this may be only me.

At the same time, I am seeing many projects using fpdart only for Either and Option. I think this is because Effects and how to use them are less well-known (and harder to understand).

I would like to introduce more people to all the ecosystems (primitives + Effects), which is a possible argument in favour of keeping them together.

What do you prefer between having primitive+Effect all in one package vs 2 separate packages? What do you think would be the benefits of one solution over the other?

[tim-smart]

Our company is slowly moving away from dart / flutter, so I will have likely have less or no time to maintain this package.

So if you want to integrate it into fpdart that is fine, but you will need to be comfortable maintaining it and fixing any bugs. I'll be available to answer questions and help out here and there of course :)

[SandroMaglione]

It works. I will be first releasing the Do notation in fpdart (v0.6.0) and then I plan to start the integration of your ZIO inside the package. My intention is to move as above:

Remove IO / Task (and derived classes) from fpdart Integrate ZIO inside fpdart Make sure that the previous IO / Task tests in fpdart work the same with the new ZIO equivalents (plus some possible new addition and deprecations/removed methods)

Thanks @tim-smart 🙏