block-explorer VS cats-retry

We are proud to release our new and updated explorer 2.0! https://xsnexplorer.io/

The simplest way I got stick to for years is ansible, here you find the necessary scripts to deploy various services, and taking the Scala side shouldn't take you more than a couple of days, after that, you shouldn't worry about the issue anymore.

In our case, we ended up building a simple helper to retry operations in any future, see RetryableFuture.

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