I 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 e…
Zio: Type-safe, composable asynchronous and concurrent programming for Scala
11–20 of 21 posts
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#12Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#13Earlier quoted context omitted.
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 e…
I'm holding out hope that ZIO can be the spring for scala. An opinionated framework is sorely needed for a language like Scala which has so many competing styles and libraries that don't naturally work together.
There seems to be a real demand for the Zio ecosystem and I wish it all the success it deserves, but its opinionated approach doesn't necessarily solve a problem that people have.
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#14Earlier quoted context omitted.
I'm holding out hope that ZIO can be the spring for scala. An opinionated framework is sorely needed for a language like Scala which has so many competing styles and libraries that don't naturally work together.
Nowadays many libraries in and around the Typelevel ecosystem work well together. There seems to be a real demand for the Zio ecosystem and I wish it all the success it deserves, but its opinionated approach doesn't necessarily solve a problem that people have.
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#15Earlier quoted context omitted.
Nowadays many libraries in and around the Typelevel ecosystem work well together. There seems to be a real demand for the Zio ecosystem and I wish it all the success it deserves, but its opinionated approach doesn't necessarily solve a problem that people have.
Sure it does. The problem is how to create a stable set of cross cutting technologies that enable you to concentrate on building the thing you want.
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#16I 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 e…
That being said, the sum of the ZIO _ecosystem_ is absolutely a framework, for better or worse.
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#17Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#18Earlier quoted context omitted.
Sure it does. The problem is how to create a stable set of cross cutting technologies that enable you to concentrate on building the thing you want.
I have no problems building the things I want using libraries based on Cats Effect.
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#19Earlier quoted context omitted.
I have no problems building the things I want using libraries based on Cats Effect.
Great. No sure how standardizing on Cats Effect is different than standardizing on ZIO. That's basically my point. ZIO provides a bunch of libraries that work well together.
cats-effect is a meta-abstraction _and_ a concrete implementation of that abstraction. All of its functionality is abstract over the effect type, which for a lot of library use cases is good! (for example, this enables using ZIO with c-e ecosystem libraries; if c-e took the same tactic as ZIO then this wouldn't be possible)
When you get down to the application level, though – essentially the effect type is going to be fixed. I doesn't _have_ to be, but it takes superhuman levels of discipline not to make it that way. And ZIO is built for that – if the effect type is fixed to ZIO, it grants a lot of ergonomic benefits. So, ZIO ecosystem components are built with that in mind, and give a lot of ergonomics and higher-level semantics that aren't possible with c-e (or abstract effect types).
If cats-effect split the meta-abstraction and the implementation into two libraries, I think this debate would be moot. But, having the implementation together with the meta-abstraction makes cats-effect more likely to leak the latter into the former (I think it's gotten a lot better about this lately, though).
Anyway, just saying – both libraries are great, and they're different, and nobody should be made to feel bad about using either one of them.
Re: Zio: Type-safe, composable asynchronous and concurrent programming for Scala
#20Earlier quoted context omitted.
I have no problems building the things I want using libraries based on Cats Effect.
Great. No sure how standardizing on Cats Effect is different than standardizing on ZIO. That's basically my point. ZIO provides a bunch of libraries that work well together.
JDG argues against the "tagless final" pattern and brings some valid points, but in practice they aren't a problem if you don't overdo it. So in my case, I don't see the appeal in switching to a less mature ecosystem, at least based on this premise alone.
Before using Cats Effect/http4s/fs2/... I worked a few years using the Akka ecosystem (Play and then Akka http, streams, clustering, event-sourcing, ...) and while the underlying technology is solid, I was not a big fan of the experience overall. To me, the Typelevel ecosystem has mostly figured out what Scala should look like today.
If people find an answer in Zio, that's great, it doesn't have to be zero-sum.