@NicolasRinaudo

A few thoughts:

There are several definitions of "direct-style". Ox calls itself direct-style, but doesn't have a separation between description and action. This means it isn't compositional in a useful sense (alternatively, you have to be more careful than you should to make it compositional). Taking the first example from the home page, you cannot refactor

```scala
def computation1: Int = { sleep(2.seconds); 1 }
def computation2: String = { sleep(1.second); "2" }
val result1: (Int, String) = par(computation1, computation2)
```

to

```scala
def computation1: Int = { sleep(2.seconds); 1 }
def computation2: String = { sleep(1.second); "2" }

val c1 = computation1
val c2 = computation2
val result1: (Int, String) = par(c1, c2)
```

and have it work as you'd expect under RT. I think this loss of local reasoning is actually very important. It's really fricking hard to ensure you don't run `Futures` (or Ox computations; they have the same model of executing immediately) at the wrong time in a large code base.

The corollary of this is that I think you undervalue the ability to compose `IO`. When you write code to, say, handle errors or run stuff in parallel or race multiple fibers, you can be sure it will actually happen the way you write it, not that some bullshit like "oh this already ran before we got here" will change the semantics.

OTOH, there are other formulations of direct-style where the unit of composition changes from `A => F[B]` (i.e. monadic) to `F[A] => B` (direct-style, where `F` is required "capabilities"). Now that effects have an explicit representation in the type system you can still leverage types to help you (cf Ox where a computation has no types AFAIK) and it's still composable because nothing runs until you provide the capabilities.