4 ms·

I really wish Rust/stdlib had been built around a good async io story. Right now it just feels neglected "because the crates ecosystem can deal with it". I mig

I really wish Rust/stdlib had been built around a good async io story. Right now it just feels neglected "because the crates ecosystem can deal with it". I might be wrong here but it always seemed to me that Rust was built to replace C/C++ in critical infrastructure like Firefox, Nginx, Redis, etc. Basically critical network dependent infrastructure. With respect (because I understand the difficulties that come with time constraints/resourcing/building an efficient async API), currently I'm not sure how Rust expects itself to be a viable replacement (let alone the best replacement) language for any of those types of applications.

steveklabnik 11y ago
Well, and again, it doesn't implement the entire web platform, but Servo is already showing significant speed gains, even without AIO. It's really more useful for servers than clients. It's important to remember that IO is truly a library concern in Rust. 1.0 means the language is stable, but there's still tons of libraries to build on top of that language. Holding back the language itself for a library that, while important, is only needed for certain applications wouldn't make a whole lot of sense.
- yazaddaruvala 11y ago
  In this particular context I believe using Servo as an argument is misleading. And actually its not just about "doesn't implement the entire web platform". Servo gains all of its performance wins from parallel rendering. A very effective but entirely orthogonal optimization. Just because one optimization far outweighs the performance wins of another optimization doesn't mean the other should be neglected entirely. Also, Servo's benchmarks run a relatively light workloads, i.e. one page at a time. The argument might be similar to using benchmarks for a parallel web rendering engine (a Servo-like) in Go. It would probably have similar median latencies to Servo. And Go may even scale out better if tabs were sandboxed in goroutines instead of processes. However, ofcourse unlike Servo it would have a higher variance/p90/p99 latencies because of the GC. P.S. I'm not a big fan of Go I was just using it to try and bolster my argument that Servo's current benchmarks shouldn't be used as an argument against async io prioritization. Actually, side note, I would love to hear more flaws about building a Servo-like in Go.
gilgoomesh 11y ago
The absence of async IO in the standard library in Rust 1.0 is probably an artefact of Rust's original intention to use M:N green threads and blocking IO based on libuv: https://www.reddit.com/r/rust/comments/1v2ptr/is_nonblocking_io_possible_in_rust/ https://www.reddit.com/r/rust/comments/1v2ptr/is_nonblocking... The timing of the move away from green threads didn't really offer enough time to implement a stable async IO option before 1.0

steveklabnik 11y ago

Well, and again, it doesn't implement the entire web platform, but Servo is already showing significant speed gains, even without AIO. It's really more useful for servers than clients. It's important to remember that IO is truly a library concern in Rust. 1.0 means the language is stable, but there's still tons of libraries to build on top of that language. Holding back the language itself for a library that, while important, is only needed for certain applications wouldn't make a whole lot of sense.

yazaddaruvala 11y ago
In this particular context I believe using Servo as an argument is misleading. And actually its not just about "doesn't implement the entire web platform". Servo gains all of its performance wins from parallel rendering. A very effective but entirely orthogonal optimization. Just because one optimization far outweighs the performance wins of another optimization doesn't mean the other should be neglected entirely. Also, Servo's benchmarks run a relatively light workloads, i.e. one page at a time. The argument might be similar to using benchmarks for a parallel web rendering engine (a Servo-like) in Go. It would probably have similar median latencies to Servo. And Go may even scale out better if tabs were sandboxed in goroutines instead of processes. However, ofcourse unlike Servo it would have a higher variance/p90/p99 latencies because of the GC. P.S. I'm not a big fan of Go I was just using it to try and bolster my argument that Servo's current benchmarks shouldn't be used as an argument against async io prioritization. Actually, side note, I would love to hear more flaws about building a Servo-like in Go.

gilgoomesh 11y ago

The absence of async IO in the standard library in Rust 1.0 is probably an artefact of Rust's original intention to use M:N green threads and blocking IO based on libuv: https://www.reddit.com/r/rust/comments/1v2ptr/is_nonblocking_io_possible_in_rust/ https://www.reddit.com/r/rust/comments/1v2ptr/is_nonblocking... The timing of the move away from green threads didn't really offer enough time to implement a stable async IO option before 1.0