4 ms·

> using asyncio Don't hold your breath. Unfortunately, the community seems to be going the way of Ruby/Python/C++: massive fragmentation.

by 15155 10y ago

steveklabnik 10y ago
What evidence do you have of this? Almost everyone is rallying around tokio.
- bluejekyll 10y ago
  Yeah tokio and futures-rs rock. Have there been talks of futures becoming part of std?
  - steveklabnik 10y ago
    Many feel that it's likely that the future trait itself could become part of libcore. It's still far too early days to tell, though.
    - 15155 10y ago
      > the future trait itself could become part of libcore _Please_ make this so. > still far too early I've waited 3 years, more time probably couldn't hurt.
- 15155 10y ago
  > Almost everyone is rallying around tokio. Sure - just as everyone "rallies" around EventMachine in Ruby. This discussion has been going on for almost 3 years now. It's great that tokio is making community headwinds, Twisted, Gevent, Celluloid, EventMachine all did too. The problem is, they've never reached critical mass, and their respective languages refused to bless them as "official." > What evidence do you have of this? The issue is inter-library compatibility. https://github.com/tailhook/rotor https://github.com/tailhook/rotor https://github.com/tokio-rs/tokio https://github.com/tokio-rs/tokio Totally incompatible, even though they build on the same low level library. https://github.com/mitsuhiko/redis-rs https://github.com/mitsuhiko/redis-rs Oh wow, a great redis library - objectively the most popular. Completely incompatible with all of the above AIO implementations. Let's take it to the extreme: - Incompatible memcached client implementations: - https://github.com/aisk/rust-memcache https://github.com/aisk/rust-memcache (sync) - https://github.com/zonyitoo/memcached-rs https://github.com/zonyitoo/memcached-rs (sync) - https://github.com/samphippen/decachedmem https://github.com/samphippen/decachedmem (tokio, partially implemented) - Incompatible redis client implementations: - https://github.com/tokio-rs/tokio-redis https://github.com/tokio-rs/tokio-redis (async via tokio) - https://github.com/mitsuhiko/redis-rs https://github.com/mitsuhiko/redis-rs (sync) - https://github.com/AsoSunag/redis-client https://github.com/AsoSunag/redis-client - Incompatible HTTP client implementations: - https://github.com/matt2xu/async-http-client/ https://github.com/matt2xu/async-http-client/ (tokio, new) - https://gitlab.com/imp/requests-rs.git https://gitlab.com/imp/requests-rs.git (hyper, sync) - https://crates.io/crates/reqwest https://crates.io/crates/reqwest (hyper) - https://crates.io/crates/request https://crates.io/crates/request The list goes on. There are countless libraries implemented with synchronous I/O, there are countless (good) popular libraries implemented with non-Tokio-based concurrency primitives. Let me just say it: I really, really like Rust. But I cannot feasibly use it for network/server-related tasks until a single solution is blessed by the Rust team. The "let's let the community handle standardizing async IO and concurrency" approach has _never_ worked in the somewhat brief history of programming languages. A blessed solution though? - Erlang, Golang, Node/JS* All work flawlessly. I would use Rust full-time for every server-related task if I could, but I've been observing for 3 years and unfortunately haven't seen much development after the abandonment of builtin green threading. *- codestyles sometimes incompatible, but there was _never_ a litany of sync libraries or otherwise fundamentally incompatible systems.
  - steveklabnik 10y ago
    > just as everyone "rallies" around EventMachine in Ruby. You can't really compare things this way. Very few people even use EventMachine, as it has significant issues. You can't just show that rotor and tokio are two different libraries; you've claimed that there's significant ecosystem fragementation. That's a very different claim. The same goes for the other three sets of links below: that you can find a bunch of GitHub repositories does not mean that there's actual fragmentation. Writing a memcached or Redis client is a good way to learn a language, even: I've known two people who independently did so for memcached + Rust, tossed them up on github, and that's it. (one of those is one of the links you've provided above, even.) > Oh wow, a great redis library - objectively the most popular. Completely incompatible with all of the above AIO implementations. Because it's synchronous. Once tokio has an actual 0.1 release of the full stack, which is to happen any day now, you'll see more consolidation. > until a single solution is blessed by the Rust team. Two of three of tokio's core team members are Rust core team members. We had a full talk on it at RustConf, and it was mentioned in the keynote. Mozilla has sponsored development of it in places.
  - kibwen 10y ago
    > their respective languages refused to bless them as > "official." Tokio is literally developed by 1) the Rust developers and 2) contractors paid by Mozilla to work on Tokio. It's as official as Cargo is. :P
  - jdub 10y ago
    The "Rust team" isn't picking winners, but they do happen to be contributing to and creating the leading solutions. There is a lot of energy around futures and tokio, very early on in the story of Rust. Sure, Rust has already been around for a while, but 1.0 was only last year. If you like Rust, and you want to use it for network and server related tasks, get involved. Write the redis, memcache, HTTP clients of your dreams. Rally the people who've solved those problems in Rust (and elsewhere) in the past. Please try to state your concerns (or better yet, ask questions) in a more thoughtful manner.
    - coldtea 10y ago
timClicks 10y ago
Rust is a magnet for creative, intelligent people. There are bound to be lots of implementations for things like low-level I/O because lots of people want to explore the relationship between the OS, the application and the hardware. That is different than fragmentation in the sense you're implying. The Rust community is pretty unified, esp. as its communication channels are well defined. For asyncio, I am pretty sure that Tokio will be the tool for most applications.
- 15155 10y ago
  > That is different than fragmentation in the sense you're implying. It is! But there are a mass of completely incompatible, overwhelmingly popular libraries. > For asyncio, I am pretty sure that Tokio will be the tool for most applications. When?
  - bluejekyll 10y ago
    > When? Tokio was only released along with futures like 3 months ago? It takes time to rebuild software on top of that. It definitely took me time to port from directly using MIO to using tokio. After evaluating others options, I do believe tokio will be the default for most people.
  - kibwen 10y ago
    Tokio is already eating the ecosystem, voluntarily. The authors of the only other two competitors, Rotor and GJ, told me at Rust Belt Rust that they're planning on deprecating their projects and throwing in with Tokio (perhaps largely thanks to the fact that the Rust/Mio devs asked them both for their input during the design of Tokio).
- coldtea 10y ago
  >There are bound to be lots of implementations for things like low-level I/O because lots of people want to explore the relationship between the OS, the application and the hardware. You say it like it's a good thing.
  - 10y ago
Matthias247 10y ago
I agree it's an issue. Java and C# also suffer from it. In Java probably each webserver implements it's own network framework on top of NIO and in the end you have dozens of incompatible event loops runing. However it's not an easy issue to solve for a general purpose language, unless you want to tie all those IO semantics (and probably a big runtime environment) directly to the language. C++ and Rust don't want to do that, since they want you to be able to use the language even on bare metal with zero runtime. What you can do as a library developer for these languages is to try to make them as integretable as possible into all kinds of surrounding environments. I normally would try to make my library usable for blocking calls as well as in a nonblocking way within an external eventloop. You can do that by spawning your own thread/eventloop, handle all the library logic in there and provide thread-safe external APIs that communicate with our eventloop. Framework development (in the sense of Netty/Tokio/etc) is harder. If often won't be possible to develop code that runs in multiple frameworks.

> using asyncio Don't hold your breath. Unfortunately, the community seems to be going the way of Ruby/Python/C++: massive fragmentation.

by 15155 10y ago

> using asyncio Don't hold your breath. Unfortunately, the community seems to be going the way of Ruby/Python/C++: massive fragmentation.

steveklabnik 10y ago

What evidence do you have of this? Almost everyone is rallying around tokio.

bluejekyll 10y ago
Yeah tokio and futures-rs rock. Have there been talks of futures becoming part of std?
- steveklabnik 10y ago
  Many feel that it's likely that the future trait itself could become part of libcore. It's still far too early days to tell, though.
  - 15155 10y ago
    > the future trait itself could become part of libcore _Please_ make this so. > still far too early I've waited 3 years, more time probably couldn't hurt.
15155 10y ago
> Almost everyone is rallying around tokio. Sure - just as everyone "rallies" around EventMachine in Ruby. This discussion has been going on for almost 3 years now. It's great that tokio is making community headwinds, Twisted, Gevent, Celluloid, EventMachine all did too. The problem is, they've never reached critical mass, and their respective languages refused to bless them as "official." > What evidence do you have of this? The issue is inter-library compatibility. https://github.com/tailhook/rotor https://github.com/tailhook/rotor https://github.com/tokio-rs/tokio https://github.com/tokio-rs/tokio Totally incompatible, even though they build on the same low level library. https://github.com/mitsuhiko/redis-rs https://github.com/mitsuhiko/redis-rs Oh wow, a great redis library - objectively the most popular. Completely incompatible with all of the above AIO implementations. Let's take it to the extreme: - Incompatible memcached client implementations: - https://github.com/aisk/rust-memcache https://github.com/aisk/rust-memcache (sync) - https://github.com/zonyitoo/memcached-rs https://github.com/zonyitoo/memcached-rs (sync) - https://github.com/samphippen/decachedmem https://github.com/samphippen/decachedmem (tokio, partially implemented) - Incompatible redis client implementations: - https://github.com/tokio-rs/tokio-redis https://github.com/tokio-rs/tokio-redis (async via tokio) - https://github.com/mitsuhiko/redis-rs https://github.com/mitsuhiko/redis-rs (sync) - https://github.com/AsoSunag/redis-client https://github.com/AsoSunag/redis-client - Incompatible HTTP client implementations: - https://github.com/matt2xu/async-http-client/ https://github.com/matt2xu/async-http-client/ (tokio, new) - https://gitlab.com/imp/requests-rs.git https://gitlab.com/imp/requests-rs.git (hyper, sync) - https://crates.io/crates/reqwest https://crates.io/crates/reqwest (hyper) - https://crates.io/crates/request https://crates.io/crates/request The list goes on. There are countless libraries implemented with synchronous I/O, there are countless (good) popular libraries implemented with non-Tokio-based concurrency primitives. Let me just say it: I really, really like Rust. But I cannot feasibly use it for network/server-related tasks until a single solution is blessed by the Rust team. The "let's let the community handle standardizing async IO and concurrency" approach has _never_ worked in the somewhat brief history of programming languages. A blessed solution though? - Erlang, Golang, Node/JS* All work flawlessly. I would use Rust full-time for every server-related task if I could, but I've been observing for 3 years and unfortunately haven't seen much development after the abandonment of builtin green threading. *- codestyles sometimes incompatible, but there was _never_ a litany of sync libraries or otherwise fundamentally incompatible systems.
- steveklabnik 10y ago
  > just as everyone "rallies" around EventMachine in Ruby. You can't really compare things this way. Very few people even use EventMachine, as it has significant issues. You can't just show that rotor and tokio are two different libraries; you've claimed that there's significant ecosystem fragementation. That's a very different claim. The same goes for the other three sets of links below: that you can find a bunch of GitHub repositories does not mean that there's actual fragmentation. Writing a memcached or Redis client is a good way to learn a language, even: I've known two people who independently did so for memcached + Rust, tossed them up on github, and that's it. (one of those is one of the links you've provided above, even.) > Oh wow, a great redis library - objectively the most popular. Completely incompatible with all of the above AIO implementations. Because it's synchronous. Once tokio has an actual 0.1 release of the full stack, which is to happen any day now, you'll see more consolidation. > until a single solution is blessed by the Rust team. Two of three of tokio's core team members are Rust core team members. We had a full talk on it at RustConf, and it was mentioned in the keynote. Mozilla has sponsored development of it in places.
- kibwen 10y ago
  > their respective languages refused to bless them as > "official." Tokio is literally developed by 1) the Rust developers and 2) contractors paid by Mozilla to work on Tokio. It's as official as Cargo is. :P
- jdub 10y ago
  The "Rust team" isn't picking winners, but they do happen to be contributing to and creating the leading solutions. There is a lot of energy around futures and tokio, very early on in the story of Rust. Sure, Rust has already been around for a while, but 1.0 was only last year. If you like Rust, and you want to use it for network and server related tasks, get involved. Write the redis, memcache, HTTP clients of your dreams. Rally the people who've solved those problems in Rust (and elsewhere) in the past. Please try to state your concerns (or better yet, ask questions) in a more thoughtful manner.
  - coldtea 10y ago

timClicks 10y ago

Rust is a magnet for creative, intelligent people. There are bound to be lots of implementations for things like low-level I/O because lots of people want to explore the relationship between the OS, the application and the hardware. That is different than fragmentation in the sense you're implying. The Rust community is pretty unified, esp. as its communication channels are well defined. For asyncio, I am pretty sure that Tokio will be the tool for most applications.

15155 10y ago
> That is different than fragmentation in the sense you're implying. It is! But there are a mass of completely incompatible, overwhelmingly popular libraries. > For asyncio, I am pretty sure that Tokio will be the tool for most applications. When?
- bluejekyll 10y ago
  > When? Tokio was only released along with futures like 3 months ago? It takes time to rebuild software on top of that. It definitely took me time to port from directly using MIO to using tokio. After evaluating others options, I do believe tokio will be the default for most people.
- kibwen 10y ago
  Tokio is already eating the ecosystem, voluntarily. The authors of the only other two competitors, Rotor and GJ, told me at Rust Belt Rust that they're planning on deprecating their projects and throwing in with Tokio (perhaps largely thanks to the fact that the Rust/Mio devs asked them both for their input during the design of Tokio).
coldtea 10y ago
>There are bound to be lots of implementations for things like low-level I/O because lots of people want to explore the relationship between the OS, the application and the hardware. You say it like it's a good thing.
- 10y ago

Matthias247 10y ago

I agree it's an issue. Java and C# also suffer from it. In Java probably each webserver implements it's own network framework on top of NIO and in the end you have dozens of incompatible event loops runing. However it's not an easy issue to solve for a general purpose language, unless you want to tie all those IO semantics (and probably a big runtime environment) directly to the language. C++ and Rust don't want to do that, since they want you to be able to use the language even on bare metal with zero runtime. What you can do as a library developer for these languages is to try to make them as integretable as possible into all kinds of surrounding environments. I normally would try to make my library usable for blocking calls as well as in a nonblocking way within an external eventloop. You can do that by spawning your own thread/eventloop, handle all the library logic in there and provide thread-safe external APIs that communicate with our eventloop. Framework development (in the sense of Netty/Tokio/etc) is harder. If often won't be possible to develop code that runs in multiple frameworks.