RFC: future of this project

[armanbilge]

tl;dr Epollcat will be upstreamed into Cats Effect / FS2. Does anyone want to use it as a standalone project (without Cats Effect)? If so, where should it live, and who will maintain it?

---

Firstly, I am truly pleased by how well this project has demonstrated the potential of Scala Native and its ecosystem. Major libraries such as http4s Ember, Skunk, and SNUnit all run on the Epollcat runtime, and as a result can be used together simultaneously in a single application! Big thanks to everyone involved, particularly @LeeTibbert and @lolgab 👏

Thanks to Epollcat's success, as of typelevel/cats-effect#3314 I have begun upstreaming its codebase directly into Cats Effect and FS2. This has a number of advantages, specifically:

1. I/O will work in Cats Effect and FS2 out-of-the-box, without any additional configuration.
2. We can directly implement FS2 I/O APIs without shimming JDK NIO and its various warts.
3. It can be deeply integrated with the multi-threaded runtime we are developing for Scala Native 0.5.

Thus development will continue there, the Typelevel Native stack will no longer need Epollcat, and personally I will not be able to develop or maintain it further.

However, this project still has important value, as a dependency-free, pure Scala event loop for Scala Native that offers an implementation of AsynchronousSocketChannel for Linux and macOS. Is there anyone who is interested in using it standalone?

One proposal is that we remove the Cats Effect dependency from this codebase and contribute it to the scala-native-loop repository as an alternative, non-libuv-based event loop implementation.

[armanbilge]

tl;dr Epollcat will be upstreamed into Cats Effect / FS2.

This work is now complete.

https://github.com/typelevel/cats-effect/releases/tag/v3.6.0-RC1
https://github.com/typelevel/fs2/releases/tag/v3.12.0-RC1

In the near future, I will make one last release deprecating EpollApp and archive this repository.