May I ask,
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.
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.
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.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.
Why not EventMachine? / Why not Celluloid?
Why not Twisted? / Why not gevent?
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.
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.
I don't believe the language needs to dictate something. It might help, sure, but there's no reason that is a requirement.
For the sake of compatibility, a blessed option should be offered.
The AIO situation today in Rust looks identical to Ruby, Python, and C++.
And eventually a standard interface will be offered. Just not before it's ready.
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.