Don't misunderstand, I'm all for competing implementations. I just feel like it would be helpful to lay out a comparison for everyone else's understanding/decision making process.
Well, hyper is a lib for dealing with the HTTP protocol. If being cross platform did not matter, hyper could be build atop of this.
I did not go the route of mio because I wanted to learn the entire process of working with epoll by doing it myself. I've learned a lot, and would not have that knowledge if I just built atop of mio. Mio must also provide a unified abstraction across platforms, where I was free to experiment and change at will during the building process.
I'm clearly not pcwalton@ but my thoughts would be: It would be a cool experiment to verify the Mio interface.
i.e. If an entirely isolated re-implementation of async-io in Rust can benefit from or easily standardize to a common interface, that gives the interface far more validity as a good/simple/generic interface.
This is a really sad situation unfortunately. I was hoping Rust wouldn't head down this road.
To preempt: a systems language shouldn't dictate these high-level matters, but there certainly should be one "blessed solution" vs. a sea of incompatible libraries.
Go doesn't have this problem, Node.js doesn't have this problem, Elixir doesn't have this problem. Sad deal.
> To preempt: a systems language shouldn't dictate these high-level matters
But you cited a whole bunch of languages that do dictate this. Those languages don't have those problems because you can't write competing implementations of low-level async I/O in those languages.
And there certainly are competing, incompatible implementations of relatively low-level functionality in Golang, for example fasthttp: https://github.com/valyala/fasthttp
I'm all for standardizing on one solution when the time comes. Rust will have an async I/O story. But right now nothing is mature enough yet to begin that process. Rushing to standardize something that is not yet ready is the worst of all possible options.
Basically all async I/O code in the Ruby ecosystem uses EventMachine.
That's not the point: more of an ecosystem is built around the stdlib's blocking I/O than mio. New projects everyday are built around things that will eventually be incompatible.
I wanted to use Rust and learn epoll through working with it directly.
> I was hoping Rust wouldn't head down this road.
To my knowledge, Rust does not have a std async story. I hope it will, and I believe libs like mio will help flush out platform agnostic ideas and a tested API.
> To preempt: a systems language shouldn't dictate these high-level matters
All of your cited example languages are _not_ systems language? Node.js isn't even a language? It could be listed above with the rest of your async I/O options across several languages.
Why not Hyper?
Why not Mio?
Don't misunderstand, I'm all for competing implementations. I just feel like it would be helpful to lay out a comparison for everyone else's understanding/decision making process.