CODEWITHSUNDEEP
multithreadingscalafunctional-programmingscala-catsmonix
WeiChing 林煒清
WeiChing 林煒清

Reputation: 4469

What is lost after converting Monix `Task` to Cats `IO`?

This simplified case is where my question happen at...

object Main extends IOApp{
 def run(args:Seq[String]): IO[ExitCode]={
    Task{...}
     .to[IO]
     .as(ExitCode.Success)
 }
}

Another option is Await.result(task), however which sounds not quite line up with IOApp's practice.

what i know

According to this great post Monix vs Cats Effect
I see differences between Task IO are:

question and my opinion

What I lost after I convert Monix Task into Cats IO?

It seems to work fine, with Task.gather and timeout-- all those Task specific things.
So What I lost in conversion ?
If no, then no reason to have more than one data type created.

So given the differences is that means that I lost the scheduling fairness after conversing Task to IO ?

Well I should have verified it by myself but I don't known how to test it the fairness.

Upvotes: 10

Views: 834

Answers (1)

Daenyth
Daenyth

Reputation: 37441

Monix Task isn't updated for cats-effect 3, nor is it likely to ever be, so at this point it's a moot question - if you want to use the current ecosystem, you use IO

The monix author is a major contributor to cats-effect, and at this point there's little to no functionality present in monix task which can't be also done with IO.

Upvotes: 0

Related Questions