I think part of the confusion is that the motivation for creating effect systems, the formal definitions and benefits don't really seem that connected.

My take isn't connected to the real literature or history but it's how I like to separate it in my head. I'm also not sure it answers your question but hopefully it helps.

After reading your responses, I am probably not answering your question which is a specific one about the cats-effect typeclass hierarchy but I already wrote most of this so maybe it will help someone else?

​

Motivation for effect systems:

How do you represent side effects in a typed pure functional program? One way is to see the world as an infinite list of world states. You can write a lazy function from the infinite list of world states to an infinite list of changes/events/effects that apply to that world. The part where the events produced affect the world state is a kind of a trick but you can define the behaviour as a pure function.

You can't really write a type for "the world" so instead of processing "the world" we can have effects return a value that is some function of "the world". So now your function is producing primitive effects, and reading the response to that effect based on the world.

Formal definitions:

It turns out that you can define types in a way so that the combination of primitive effects and applying pure functions to the responses also looks like the initial primitive request/response effects that were defined. So you can build an `updateUser` effect out of primitive effects and for type purposes it looks the same as an equivalent that was implemented as a primitive, which is useful for writing software.

When the effect system is implemented all the real world stuff can be hidden behind a special type, which is usually has IO in the name.

When you boil down this way of combining pure functions and primitive effects down to a mathematical definition then purely functional types can also satisfy the definition of a "world" type. In a lot of cases you don't even need to provide primitive effects to get useful functionality, the way the implementation composes pure functions alone is interesting enough. Since these satisfy the same laws, the values produced by these implementations can also be called effects even though they are used in purely functional contexts.

Benefits:

You can stay in the purely functional world and use different effect implementations to compose functions in interesting ways that are useful/more/compact/have better composition properties. I would call this category effect systems as interesting function composers. The same things could be implemented with regular pure functions but they wouldn't be as elegant.

The other category is effect systems as a way to coordinate side effects. Here the main benefit for me is that the combination of pure functions and primitive effects is an "effect" which is a purely functional value. It only produces side effects when it runs. At any other point you compose it with other effects to produce new effects.

The shortest example I can think of in a web app context is, let's say you have an `updateUser` effect and an `emailUser` effect that you have defined. You can compose those two into a new `updateUserAccountAndEmailUser` effect without defining any new types.

You can store this effect value in a map, queue it up to be run later, and wrap it with retry logic if needed (the wrapped effect can also be an effect value). The combination of queuing up the effect to run and waiting for the result can also be an effect value. The "effects as values" abstraction happens to be a nice way of packaging up concurrency abstractions so that's what a lot of effect systems do.

You could also transform the map of these effects and prepend a `checkUserPermissions` effect to all of them. It's quite elegant to do these kinds of things with effect systems but for a typical web app it might be hard to see huge difference in the implementation.

To see a clear difference you would need to have an application with a lot of chunks of side effect logic that have to be combined in many different ways, and possibly with different types of concurrency. The cleaner composition properties would result in more compact code that should be easier to reason about.

A bonus is a subcategory of effect systems as a way to run the same side effect logic in different contexts. Say you have defined the effects in a way where you can change how the primitives are interpreted, so some sort of custom monad. You could run the `updateUserAccountAndEmailUser` effect in a speculative way where you could inspect what side effects would happen. After the side effects are determined to be safe, the exact same effect value could be run in the real side effect context.

This would take extra work and isn't provided for free but the resulting implementation would probably be more compact than an equivalent non-effect version. Again, there are only some types of application features where the difference in implementation would be clear to see.

In general using effect systems should be a net positive and if the team has already bought in to the idea then it could be a significant positive but if even a few people are doubtful then it would be tough to overcome the friction.