Zio: Type-safe, composable asynchronous and concurrent programming for Scala
1–10 of 21 posts
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#2I heard there was some sort of schism between John De Goes and Typelevel a while back? Does that still affect the Scala fp community?
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#3I heard there was some sort of schism between John De Goes and Typelevel a while back? Does that still affect the Scala fp community?
Yes!
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#4The readme as well as the homepage mention "100x the performance of Scala's Future"
What makes scala's Future perform poorly, and how does zio avoid that? I feel like they tried really hard to present the project in terms of what it can do for you, and I get that. But if there's some real conceptual insight underlying that 100x improvement, where could I read about that?
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#5I heard there was some sort of schism between John De Goes and Typelevel a while back? Does that still affect the Scala fp community?
From a political perspective, yes for sure. From a technical perspective, less so. The Cats ecosystem and ZIO are meaningfully different with their designs that the two evolving separately isn't so bad in my opinion.
The Scalaz/Cats schism was worse in the sense that they were largely the same (at least at the time) which led to a lot of duplicated effort.
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#6The readme as well as the homepage mention "100x the performance of Scala's Future" What makes scala's Future perform poorly, and how does zio avoid that? I feel like they tried really hard to present the project in terms of what it can do for you, and I get that. But if there's some real conceptual insight underlying that 100x improvement, where could I read about that?
[deleted]
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#7The readme as well as the homepage mention "100x the performance of Scala's Future" What makes scala's Future perform poorly, and how does zio avoid that? I feel like they tried really hard to present the project in terms of what it can do for you, and I get that. But if there's some real conceptual insight underlying that 100x improvement, where could I read about that?
> 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.
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#8The readme as well as the homepage mention "100x the performance of Scala's Future" What makes scala's Future perform poorly, and how does zio avoid that? I feel like they tried really hard to present the project in terms of what it can do for you, and I get that. But if there's some real conceptual insight underlying that 100x improvement, where could I read about that?
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).
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#9I heard there was some sort of schism between John De Goes and Typelevel a while back? Does that still affect the Scala fp community?
Typelevel and ZIO take completely different approach to certain things. Even if everyone would be holding hands and singing, they would still argue in discussions on GH.
Typelevel and Cats wants everything to be a pluggable library. Everything should be configurable, hardcoding things is avoided. You are in charge of every single effect.
ZIO is basically a type-safe, compile-time, IO-monad-based framework, managing error handling, side effects and dependency injection. It is opinionated, and libraries integrating with it share its opinions. Some people consider this a FP, type safe Spring Framework.
Both can be integrated if you know what you're doing. Both have plenty of people to push things forward. At this point history between JDG and TL is irrelevant to the community. People involved in past dramas still don't like each others but they don't interact with each other during development, so just don't use Twitter and you won't even notice.
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#10The readme as well as the homepage mention "100x the performance of Scala's Future" What makes scala's Future perform poorly, and how does zio avoid that? I feel like they tried really hard to present the project in terms of what it can do for you, and I get that. But if there's some real conceptual insight underlying that 100x improvement, where could I read about that?
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.