3 ms·
Rust has definitely been a pleasure to work with. I have been experimenting with a Future & Stream [1] abstraction in Rust that would allow easily describing co
by carllerche 12y ago
Rust has definitely been a pleasure to work with. I have been experimenting with a Future & Stream [1] abstraction in Rust that would allow easily describing complex concurrent and async operations and to allow easy composition, not unlike ES 6 promises.
The interesting thing is that, thanks to Rust's ownership system, it is easy to discover when handles to a future value go out of scope. This allows the library to reuse internal resources to make the overhead of using the library as light as possible.
For example, a Stream is modeled as a sequence of futures (more specifically a future of the next value and a new stream representing the rest of the values, kind of like lazy-seq in clojure but async), but instead of allocating one future for each iteration of the stream, the same internal structure is reused while still being able to expose this API.
[1] https://github.com/carllerche/eventual https://github.com/carllerche/eventual
- jbandela1 12y agoJust looked at eventual. It seems really interesting. I looked at Rust's std Future and was turned off by the fact that is blocking.
- Ygg2 12y agoRust is blocking, there was mio crate which brought non-blocking IO operations.
- carllerche 12y agoWell, Rust doesn't have any opinions regarding blocking or not. Currently, std::io implements blocking IO, but as you pointed out, Rust allows libraries to implement non-blocking / async paradigms.
- steveklabnik 12y ago"Rust is so low-level that IO is a library concern, not a language concern," as I like to say.
- Ygg2 12y agoBut standard IO is blocking, correct? But Rust being so low level to not care about IO is Awesome :)
- steveklabnik 12y agoWe're starting off by only having blocking IO in the standard library, yes.
- jamwt 12y agoWe're using eventual (and syncbox and mio) at Dropbox in our rust stack. All of Carl's stuff is awesome.