I'm surprised about the selection of monoio. AFAIK it requires the usage of the nightly compiler which I've found to not be a great choice when maintaining a project.
I'm surprised about the selection of monoio. AFAIK it requires the usage of the nightly compiler which I've found to not be a great choice when maintaining a project.
It does require nightly, but it only uses five features, one of which could be removed by adding an external crate, and the others are like, not anything super wild, for the most part. I haven't looked too deeply into the code but they all make sense to me, for example one of them is a standard library API for creating uninitialized containers, which allows you to eliminate a copy.
I have not compared monoio with glommio, which does run on stable. Would be interesting!
It’s not that the features are unreasonable but more that anything that uses it as a dependency also inherits the nightly requirement which makes things a bit more unstable because nightly is a floating version.
I did compare with glommio a bit and disliked the file API in monoio but that’s probably more a matter of taste.
Yeah I hear you. I much prefer staying on stable for that reason. Sometimes (though much more rarely than non-Rust users seem to think) it is unavoidable though, and once you do go into nightly, you can kinda go two ways:
* only use what is absolutely necessary
* go wild and add tons of stuff
As well as there being two kinds of nightly features:
* stuff that's not stable but has a clear path to becoming stable on some time frame
* stuff that's not stable but who knows when that will change, it may never
And to me, this dependency feels kinda closer to choosing the first option from both lists, which is the most conservative way of using nightly.
As already mentioned, we've decived to use monoio, just to have something to begin with, it will take at least a few months to rewrite the core parts to make use of io_uring and thread-per-core approach (if feasible), so staying on the bleeding edge is more like a sandbox for us - we might decide to go with another runtime, like glommio, mfio or something else.
Ah cool! Just to be clear, I think you should do whatever you feel is best for your project. I don't see this in any sort of moral terms, purely engineering ones, and there are good reasons to use nightly just like there are good reasons to use stable.
Monoio seems to be the most performant runtime, and actually easy to use - we have decided to go with "bleeding edge" approach, as it will still take at least a few months to implement io_uring and other optimizations, as we'll have to rewrite some of the core parts and most likely shift towards thread-per-core architecture.
For what it’s worth I don’t believe it meaningfully outperforms glommio. There are some spots where it outperforms glommio but that’s just a missing optimization that could be added. The biggest advantage monoio really has is that it currently has support for other platforms.
Not saying it’s the wrong choice, just highlighting the trade offs.
I’m not sure what you mean by io_uring as glommio/monoio should be hiding the io_uring details behind the runtime.
Of course, they hide the details behind io_uring, it's just that monoio seemed even easier to work with. It's not set in stone, though, actually there are new runtimes being developed as we speak, for example mfio - we'll see what will be our final choice, but we've decided to start with monoio.
Speaking of the other platforms, having the fallback to epoll or kqueue (they've even announced some Windows integration) is nice to have, however, at some point we might just purely focus on Linux development anyway (io_uring only), if there'd be any issues e.g. when it comes to the code design to provide the compatibility across multiple OS.