sbt-revolver VS interop-cats

Another thing to look into is sbt-revolver, this will shorten the turnaround time on whatever machine is running sbt. I remember it being pretty helpful when I was working with scala.js. Good luck!

SBT. It's not because of the pseudo-scala config language, that looks especially alien next to braceless Scala 3 code. Or the weird symbolic operators. The big problem is correctness; in almost every project I've had to use spray-resolver because I've encountered weird bugs because SBT reuses the same dirty JVM. I really thing Drip would help here. I'll keep using SBT because it has the best Scala ecosystem support and great plugins like sbt-crossproject. It would also be great to be able to write build.sbt files in modern, regular Scala.

If you're using http4s, don't use ZIO. Yes, ZIO has an interop-cats module, so you can do this. But using http4s means you're working in the conceptual framework the Typelevel ecosystem is based on (and what interop-cats does can be characterized as "describe ZIO's implementation in those terms, so the Typelevel ecosystem can make heads or tails of it.") This is essentially all cost and no benefit: you can't avoid understanding the Typelevel ecosystem if you use http4s (at least, no more than you can by using cats-effect), and you don't get any of the value proposition of ZIO (interop-cats gives you Typelevel typeclass instances for the RIO type alias, which means your error channel is rooted in Throwable, and you're faced with the most complex part of the ZIO ecosystem: ZLayer, which the Typelevel ecosystem doesn't use and doesn't need). Finally the ZIO ecosystem is still quite immature, and this brings us to documentation. There is not (yet!) anything comparable to:

These are necessarily oversimplifications. In particular, the ZIO ecosystem offers the relevant instances of cats-effect typeclasses to support use of the ZIO type in the cats-effect ecosystem.

However, ZIO continues to offer cats-effect type classes and I certainly have no doubt cats-effect 3 continues to benefit from John's contributions. Furthermore, I likewise don't doubt the value of the ZIO ecosystem generally, and John's success in building the ZIO community speaks for itself. I personally have chosen to remain closer to the other, let's say "classical," pure FP ecosystems, partially for historical (or, if you prefer, "sunk cost") reasons, but partially because I'm satisfied the value of the Haskell/Typelevel/PureScript/fp-ts/etc. interplay warrants it.

It seems that zio/interop-cats faces a similar issue.