cats-effect | The pure asynchronous runtime for Scala | Functional Programming library

I managed to make it work! Thanks to @luismiguel insight, the problem was that the Akka HTTP Marshaller was not able to deal with Cats-Effect IO monad, so the solution was an implementation who unwraps the IO monad using the unsafeToFuture inside the marshaller, that way i was able to keep the Tagless-Final style from point to point, here's the solution:

This implicit fetches the internal marshaller for the type

Let's see the definition for Http[F, G], which is at the core of http4s:

@OlegPyzhcov already provided insight in case you are using CE3, this answer is using CE2 in case that is what you wanted.

The first version of the code was correct, here is a full running example using Ammonite with some style improvements and ensuring a new client is created for each call and evaluation of newClient

For the second approach, you can make it simpler by not forking a Fiber in scheduleAndPopulate and keepPollingUsingFiber. Instead, keep the recursive call, and fork them in the caller. IO is stack-safe, so the recursive call won't blow up the stack.

You could use start to fork each, but it might be simpler to parTupled them. It's a variation of parMapN that forks each effect and gathers their results.

(Also, in your code you don't need to pass the implicit values, like cs, explicitly, the compiler will infer them for you.)

Well, it depends on what exactly you mean by “OK”. I am not aware of any laws restricting the use of the unsafeRunSync method. I also don't think any major religion considers it a sin (though some minor ones certainly might).

That said, calling unsafeRunSync is not referentially transparent and has all the downsides that come with that. Namely, equational reasoning goes out of the window. It also blocks the calling thread if asynchronous processing is involved at any point (and in ScalaJS it won't work at all in such cases). To me, these are sufficient reasons to avoid using it in production code whenever possible. That said, there are situations where it's not possible. For instance, you sometimes need to implement interfaces that expect side effects to be performed, such as java.io.OutputStream. There's not much you can do in that situation, those signatures are the way they are.

It is however not necessary to call unsafeRunTimed to perform an action with a timeout. Just use the race method and a Timer.

One of them is lazy, the other is eager.

I don't know what the exact guarantees are, but in cats effect, fairness is frequently mentioned in terms of the scheduler. That means you may not be able to get the exact ordering you mentioned on the first acquisition of an MVar, but no one should be getting starved, because after your turn you yield your fiber and have to be rescheduled before acquiring the MVar again.

In other words, if you need exact ordering or exact round robin, you're going to have to implement that yourself, but if your requirements are really something like "every eligible fiber gets roughly the same amount of runtime without getting starved" then you get that almost for free.

Consider following examples

Given the following helper methods

Applicative[F].pure doesn't delay the effect. It only lifts a pure value into F. Since you have an Async context bound I would suggest Async[F].delay(println("tick")).

You can easily call it recursively like this: