4 ms·

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 ex

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.
- wtetzner 10y ago
  > You say it like it's a good thing. Why wouldn't it be? Let people experiment. As long as there's a standard, go-to library for applications that need to "just-work", I don't see any reason not to explore new ideas and find potentially better solutions for the future.

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.

wtetzner 10y ago
> You say it like it's a good thing. Why wouldn't it be? Let people experiment. As long as there's a standard, go-to library for applications that need to "just-work", I don't see any reason not to explore new ideas and find potentially better solutions for the future.