this post was submitted on 10 Jun 2023
10 points (100.0% liked)

Scala

340 readers
1 users here now

founded 1 year ago
MODERATORS
 

I tend to prefer Cats and that's the more commonly used ecosystem at work, but I've heard that the more framework nature of ZIO can be really comfy. I've also used Play, which had some nice things but is starting to feel like it's showing its age and the rough spot Lightbend is in.

I'm curious to hear what everyone else is using and your hot takes.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 year ago (2 children)

I only have limited time with ZIO, and used Cats without IO, but ZIO seems to be a little bit easier to grasp. I like that it kinda does everything that Option/Either/IO does in one, makes me feel like I won't be dealing with as much nesting, and I wont need the monad transformers too. At my job we used Future instead of IO and monad transformers were used a lot. They weren't too bad, but every now and then i'd step back and ask "is this really the best?" I'm not in a Scala job right now, I'm really hoping that in the future there will be just one library for this kind of thing, I hate having divided ecosystems.

[–] alexelcu 5 points 1 year ago

Sharing from my personal experience — with the Typelevel libraries, you don't really need monad transformers if you don't like them.

For dependency injection, personally, while being a big fan and contributor of Typelevel, I prefer to use Scala as an OOP language, too, as OOP is already great for dependency injection. And I'm always surprised by the lengths people go to avoid passing parameters to constructors or to functions. Although I will say that the use of Resource for managing the lifecycle of resources is a Scala super-power.

For errors, there are different approaches, no one size fits all, but personally, I never use EitherT or OptionT, and that's a false choice being presented by these 2 communities. You don't have to pick between EitherT or ZIO because you can choose neither.

Domain / input errors have to be designed with care, and you usually don't need short-circuiting for those. And as an alternative, what you can do instead is to design errors out of existence. I'm sharing some design advice for that here: https://alexn.org/blog/2022/04/18/scala-oop-design-sample/

[–] [email protected] 2 points 1 year ago

Probably just the nature of where I work and the Scala circles I'm in, but until I asked the question here it seemed like Cats was in the lead for market share.