Great explanation. Would love to listen to more internals of Cat-effects and related libraries? Are there other talks which explain the internal workings of Cats-effects, apart which were skipped?
So, where can I found explanation what is going on under the hood to avoid blocking a platform thread when when a code invokes a real blocking code inside a fiber?
He's just implementing *The Simplest IO* and that's a design decision. You can choose to have a RTS (runtime system) like ZIO does, define it in IO like cats-effect does or just have a single method in your simple API like in this talk. There's not one single way to do it.
Great explanation. Would love to listen to more internals of Cat-effects and related libraries? Are there other talks which explain the internal workings of Cats-effects, apart which were skipped?
this is wonderful, thank you! looking forward to next episode abour blocking and resource safety if possible.
Insanely good explanation of async and concurrency!!
Awesome! Thank you!
Thanks
Just noticed, in `spawn` around 54:00, the return type is `IO[Unit]`, not `IO[A]`. The result of the `IO[A]` is discarded (in `_ => ()`).
So, where can I found explanation what is going on under the hood to avoid blocking a platform thread when when a code invokes a real blocking code inside a fiber?
Here you go: typelevel.org/cats-effect/docs/thread-model#thread-blocking
I found the answer at Thread Model section of Cats Effect doc
30:39 ..why does the API have a def unsafeRunSync(fa: IO[A]) : A ?? the method should be on a IO[A] and not require a IO[A].
He's just implementing *The Simplest IO* and that's a design decision. You can choose to have a RTS (runtime system) like ZIO does, define it in IO like cats-effect does or just have a single method in your simple API like in this talk. There's not one single way to do it.
meow