4 ms·

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 comparis

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.

nathansizemore 10y ago
Of course! 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.
- pcwalton 10y ago
  Is it possible to stay compatible with mio's interface, perhaps via something layered on top?
  - nathansizemore 10y ago
    I'd have to look into it, haven't checked out mio in months, but I don't see any reason why it couldn't be compatible with it. Any particular reason?
    - yazaddaruvala 10y ago
      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.
15155 10y ago
Why not Boost? / Why not libuv? 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.
- pcwalton 10y ago
  > 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 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.
  - 15155 10y ago
    > But you cited a whole bunch of languages that do dictate this 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++.
    - pcwalton 10y ago
      No, it doesn't. Basically all async I/O code in the Rust ecosystem uses mio. And eventually a standard interface will be offered. Just not before it's ready.
      - 15155 10y ago

nathansizemore 10y ago

Of course! 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.

pcwalton 10y ago
Is it possible to stay compatible with mio's interface, perhaps via something layered on top?
- nathansizemore 10y ago
  I'd have to look into it, haven't checked out mio in months, but I don't see any reason why it couldn't be compatible with it. Any particular reason?
  - yazaddaruvala 10y ago
    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.

15155 10y ago

Why not Boost? / Why not libuv? 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.

pcwalton 10y ago
> 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 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.
- 15155 10y ago
  > But you cited a whole bunch of languages that do dictate this 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++.
  - pcwalton 10y ago
    No, it doesn't. Basically all async I/O code in the Rust ecosystem uses mio. And eventually a standard interface will be offered. Just not before it's ready.
    - 15155 10y ago