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.
ZIO (the core library) is not really a framework. It's still a library for an IO monad – it's just a pretty different IO monad, in that it absorbs environment (e.g. `ReaderT`) and error (e.g. from `MonadError`) into one data type, and the cases where you don't care about one of those are just type aliases. And it makes use of variance to give (usually) really ergonomic operations on these things. Disclaimer: I use it, and I'm a fan – I'll leave it up to the docs to really sell it; just wanted to take issue with the "framework" notion.
That being said, the sum of the ZIO _ecosystem_ is absolutely a framework, for better or worse.
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.
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.
I think there's room for both things, and we don't really have to (passive-agressively) squabble about which is better.
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.
The core difference is that Cats Effect is a fairly extensible effect type, with a full type class hierarchy. It's easy for compatible libraries to use and provide only what they need.
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.
Macbooks from 2019 have 4 thunderbolts 3 ports and 1 mini jack. And that's all.
If you want to power the device, you do it through a thunderbold. If you want to connect a USB that is not USB C, you have to use adapter and/or USB HUB. So you would have to connect to your USB through adapter/hub, and if for some reason whatever installer wouldn't support this you would be screwed (but I guess most of the time it would be doable, just inconvenient).
Seeing how .Net is being sold to enterprises without such libraries I would say that they exist because business happily buys into any promise that something increases productivity even if that is just salesmen's lies. But it requires good salesmen not good engineers.
Why Java devs automatically assume that every new language is made to overthrow Java/C#? They might still to provide better development in a particular domain. Go or Python or JacaScript are good at rivaling Java at mainstream language, and so what?
A language feature alone doesn't replace an ecosystem with 25 years of production experience across platforms that aren't even supported by Go.
After getting generics, Go still needs to offer JFR/JMX/VisualVM like monitoring and dynamic code loading capabilities (Go plugins are very limited), JEE/Spring like Web tooling, Liferay/AEM/Magnolia like CMSs, an OS of its own and real time GC, card chips, M2M hardware gateways, printer enterprise configuration appps, and plenty of other use cases that many on HN seem unaware of its existence in enterprise scenarios.
2.14 was supposed to be a stepping stone between 2 and 3, released only so that migration could be easier. They skipped it because apparently source code differences between valid 2.13 and 3.0 aren't that great. From what I saw it is mostly about migrating macros, the rest most likely would still work.
Previous maintainer left EPFL so nothing was happening there. But Scala Center took over the project so they will start maintaining it. AFAIR snnouncement was on Gitter by the same guy who maintains Scala.js. I guess it will take some time for them to catch up with the rest.
Presumably lower memory usage due to not running in a separate process. On a low-end PC this is a completely valid concern. Chrome is memory hungry. Running one instance might be viable. Running 2, 3 or 6 probably isn't (and you can always choose a less memory-hungry browser).
It makes me question, is there any way to run a slim browser for these kind of tools?
It would be cool to have a tool that would:
* run a very slim browser tab for each tool
* I cloud load/save sites into tools (So I can really run them offline)
* Could have a shortcut or a starting page that's just links to my saved tools
Considering this tool uses JavaScript rendering, I'm not sure you could get away with a "slim browser". You're going to need all the bloat that makes CSR work.
Saw this on Hacker News a short while back and it was pretty easy to set up. Might be pretty close to what you're looking for. It aims to be a sort of a replacement for what Electron does, without embedding a full browser.
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.