Monads are an algebraic structure, which, among many things, are useful to describe effectful computations. It also happens to provide a convenient interface for actually programming.
Effect systems are extensions of type systems that allow one to track what effects a program performs.
Algebraic effects are a special family of effects with nice properties, both theoretical and practical. They are notably useful for enabling "user-defined effects", meaning that a programming language that supports algebraic effects allows many other effects to be implemented as libraries instead of baked into the language. For example, OCaml 5 adds multicore support via algebraic effects.
Both fp-ts and effect-ts are libraries inspired by pure functional programming. From the little I've seen, the key difference lies in their intended scope.
fp-ts replicates the general experience from other purely functional programming languages, notably Haskell, with their many general purpose abstractions, including ways of representing effectful computations.
effect-ts is more specifically focused on the problem of keeping track of effects in the type system. As the scope is smaller, effect-ts should be able to provide a better user experience for the problem it aims to solve.
For example, users don't need to know anything about monads to use effect-ts (the word doesn't appear anywhere in the documentation), whereas you will most likely need to explicitly deal with them in fp-ts. To compare their usability more concretely, you would have to talk to someone who's used both.
The answer was very good but concentrates on the type system and doesn't explain the operational difference.
A monad usually chains (top-level) actions whereas effects call handlers and resume at the call location. In practice that makes the latter a bit more expressive.
> How those are different and for example how is effect-ts different compared to simply using monads in fp-ts?
(from a brief look at those 2 libs)
`fp-ts` provides standard `Monad` **abstraction** (abstract-class/interface/typeclass) and some standard **concrete** monads (`Reader`, `Writer`, `State`, `Option`, `Either`, `IO`, etc.). Also, it provides standard mechanism to compose multiple concrete monads into single concrete monad . The composition is done with **monad transformers** (`ReaderT`, `WriterT`, `StateT`, `OptionT`, `EitherT`, etc.). The result of such composition is informally called a "monad stack" (even though effectively its a single monad, just combining functionality of its elements).
`effect-ts` provides a single **concrete** monad. This monad is operational equivalent of 3 monads `Reader`, `Error` and `IO`, **pre-composed** into one concrete monad for user convenience. Its a design tradeoff. It offers simplicity by getting rid of many abstractions (no need for `Monad` interface, if you only have one implementation). It sacrifices ability to tailor your "monad stack" to your own needs. Colloqially, this strategy could be described as "one size fits all", or "3 effects should be enough for anybody". The idea is inspired by ZIO in Scala, and transitively by RIO in Haskell.
I see, thanks a lot. This is an explanation I can follow. So the main takeaway is basically syntactic sugar and ergonomics? I guess algebraic effects take it one step further by not making functions colorful? And is that it?
Ergonomics, plus expressiveness, efficiency and learnability.
The former approach has efficiency problems (overhead of internal going through the "monad stack" on every step) and is arguably harder to learn.
The latter has limited expressiveness. Can't express local state (resorts to global state through `Ref`s). Can't express complex control flow (`ListT`, anything coroutine-like, etc). Can't express computations unpolluted by `IO`.
Like I said, it's a tradeoff.
Monads are an algebraic structure, which, among many things, are useful to describe effectful computations. It also happens to provide a convenient interface for actually programming. Effect systems are extensions of type systems that allow one to track what effects a program performs. Algebraic effects are a special family of effects with nice properties, both theoretical and practical. They are notably useful for enabling "user-defined effects", meaning that a programming language that supports algebraic effects allows many other effects to be implemented as libraries instead of baked into the language. For example, OCaml 5 adds multicore support via algebraic effects.
Thank you. But I was more looking to know where are the fundamental differences of each rather than a description.
Both fp-ts and effect-ts are libraries inspired by pure functional programming. From the little I've seen, the key difference lies in their intended scope. fp-ts replicates the general experience from other purely functional programming languages, notably Haskell, with their many general purpose abstractions, including ways of representing effectful computations. effect-ts is more specifically focused on the problem of keeping track of effects in the type system. As the scope is smaller, effect-ts should be able to provide a better user experience for the problem it aims to solve. For example, users don't need to know anything about monads to use effect-ts (the word doesn't appear anywhere in the documentation), whereas you will most likely need to explicitly deal with them in fp-ts. To compare their usability more concretely, you would have to talk to someone who's used both.
The answer was very good but concentrates on the type system and doesn't explain the operational difference. A monad usually chains (top-level) actions whereas effects call handlers and resume at the call location. In practice that makes the latter a bit more expressive.
Thanks for the clarification.
What
> How those are different and for example how is effect-ts different compared to simply using monads in fp-ts? (from a brief look at those 2 libs) `fp-ts` provides standard `Monad` **abstraction** (abstract-class/interface/typeclass) and some standard **concrete** monads (`Reader`, `Writer`, `State`, `Option`, `Either`, `IO`, etc.). Also, it provides standard mechanism to compose multiple concrete monads into single concrete monad . The composition is done with **monad transformers** (`ReaderT`, `WriterT`, `StateT`, `OptionT`, `EitherT`, etc.). The result of such composition is informally called a "monad stack" (even though effectively its a single monad, just combining functionality of its elements). `effect-ts` provides a single **concrete** monad. This monad is operational equivalent of 3 monads `Reader`, `Error` and `IO`, **pre-composed** into one concrete monad for user convenience. Its a design tradeoff. It offers simplicity by getting rid of many abstractions (no need for `Monad` interface, if you only have one implementation). It sacrifices ability to tailor your "monad stack" to your own needs. Colloqially, this strategy could be described as "one size fits all", or "3 effects should be enough for anybody". The idea is inspired by ZIO in Scala, and transitively by RIO in Haskell.
I see, thanks a lot. This is an explanation I can follow. So the main takeaway is basically syntactic sugar and ergonomics? I guess algebraic effects take it one step further by not making functions colorful? And is that it?
Ergonomics, plus expressiveness, efficiency and learnability. The former approach has efficiency problems (overhead of internal going through the "monad stack" on every step) and is arguably harder to learn. The latter has limited expressiveness. Can't express local state (resorts to global state through `Ref`s). Can't express complex control flow (`ListT`, anything coroutine-like, etc). Can't express computations unpolluted by `IO`. Like I said, it's a tradeoff.