Scala's Futures constantly dip back into their ExecutionContext even when unnecessary; basically every single method on a Future causes it to go back to the ExecutionContext. This means they can incur bookkeeping or at worst thread switching overhead for no good reason.

For example, `map`ping over a completed Future has absolutely no need to go back to the ExecutionContext. Even `flatMap`ping multiple Futures together doesn't necessarily need an ExecutionContext if you offer a separate API to allow `Future`s to switch between threads (this also means that Futures must be delayed and can't run immediately).

These are the big things that make things like ZIO and cats-effect IO faster (there are then other smaller things that differentiate those two from each other).

As it already has been mentioned - Future's poor performance is mostly due redundant context switches on pretty much any operation. If you do `future.map((i: Int) => i + 1)` it can be executed on a different thread, which doesn't make much sense. It was the case in 2.11 stdlib and they're doing lots of improvements in this area, but Future still lags behind all widely-used "IO monads".

But put aside performance, any day of the week I'd choose ZIO (or Cats Effect IO or Monix Task) over Future even if ZIO was 10x slower. Amount of safety and composability "IO monads" give is outstanding.

> zio has excellent performance, featuring a hand-optimized, low-level interpreter that achieves zero allocations for right-associated binds, and minimal allocations for left-associated binds.

> The benchmarks [1] project may be used to compare IO with other effect monads, including Future (which is not an effect monad but is included for reference), Monix Task, and Cats IO.

> As of the time of this writing, IO is significantly faster than or at least comparable to all other purely functional solutions.

https://zio.dev/docs/overview/overview_performance

[1] https://github.com/zio/zio/tree/master/benchmarks