4 ms·

> Almost everyone is rallying around tokio. Sure - just as everyone "rallies" around EventMachine in Ruby. This discussion has been going on for almost 3 year

by 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
  >The "Rust team" isn't picking winners It would be better if they would, though, is what some of us are thinking. Between "totally chaotic third-party libs landscape" and "official lib designed with the language and part of the standard library", picking winners is a great middle ground.

by 15155 10y ago

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
>The "Rust team" isn't picking winners It would be better if they would, though, is what some of us are thinking. Between "totally chaotic third-party libs landscape" and "official lib designed with the language and part of the standard library", picking winners is a great middle ground.