3 ms·

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

by 15155 11y 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 11y 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 11y 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
      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.
nathansizemore 11y ago
> Why not X? 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.

by 15155 11y ago

pcwalton 11y 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 11y 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
    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.

nathansizemore 11y ago

> Why not X? 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.