My understanding of Loom is, that it is loosely inspired/similar to GHC's runtime. In both every blocking call into a system call is replaced with an equivalent

My understanding of Loom is, that it is loosely inspired/similar to GHC's runtime. In both every blocking call into a system call is replaced with an equivalent asynchronous system call and some internal thread will manage all those things to wait for. While the operating system is processing the asynchronous request the lightweight thread which made a seamingly blocking call is put aside and some other lightweight thread can execute on the same OS/level thread. Since the JVM comes with all the blocking call in its own standard libraries, it can rewrite them all internally. Every third-party library that uses the normal Java standard library will benefit from this under the hood replacement of blocking systems call with non-blocking system calls. Only when you use other native libraries you have to be careful to use mostly non-blocking functions. Therefore Loom allows programmers to think and program with blocking calls, but they get the performance characteristics of non-blocking calls. That is awesome. And there is no need to use function colouring or type-level encoding of blocking/non-blocking code.