sbt-tpolecat VS cats-retry

I'm awed by the maturity of the Scala 2 compiler. Every minor version in the 2.13 series adds a new linting improvement. You can see that if you have sbt-tpolecat in your project. I'm always happy to see that some option from Wartremover is no longer used.

Note that this assumes that non-Unit values are silently thrown away, which you should always configure scalac, preferably via sbt-tpolecat, not to allow.

sbt-tpolecat to automatically provide reasonable Scala compiler settings.

Start with settings strict compiler flags if you haven't already, for instance using sbt-tpolecat. This will help you remove the most obvious warts in your codebase.

However, after a while, I found that most of the things I needed were already covered by the compiler. And that Rob's (aka tpolecat) list of compiler options provided all the ones I needed for my style of coding. I Then learn that there was this sbt plugin that managed the list for me and also took care of changing the options according to the Scala version.

Sorry, have nothing useful to contribute (although I'd recommend you to set a restrictive set of scalac flags, for example from sbt-tpolecat, to let compiler help you), but just wanted to praise the Scala team and remind us of all those "Python 3 situation" rants we've saw 2 years ago and how silly they look now.

To try to answer the top-level question "Why are effects better for retries than Future?" I would say "because the effect types rest on a runtime that supports cancellation and error-handling with rigorous algebraic semantics." If we look at cats-retry, for example, we find implementations that require a Monad and a Sleep instance or a MonadError and a Sleep instance. The Sleep typeclass, probably unsurprisingly, just exposes a sleep effect. But look at the companion object: the only instance of the typeclass it provides is for type constructors with a cats-effect Temporal instance. IO has such an instance. Future does not, and cannot.

cats-effect has a Supervisor that allows you to do exactly that, with basically the same semantics. You can then have fire-and-forget or managed semantics at will, depending on your use case, and even retry logic