5 ms·

Asynchronous Programming in Rust

146 points by Supermighty 7y ago

boulos 7y ago
Cool! Having gone through this pain last weekend, I’m a bit wary of examples that are roughly stateless (or at least only do copying between channels). To all rust folks making samples: if you can mix in even a bit of mutable shared state (like a counter, logging, etc.), it goes a long way to showing whether your system can handle scoped threads/tasks, shared state, and straightforward concurrency ergonomically. If you compare and contrast the docs for crossbeam’s scoped threads, Rayon’s scope, and an attempt at DIY via raw thread::spawn, I think you want to see the same clarity on the future/async/await side. Richer examples can really elucidate the pros and cons of different paths.
- yoshuaw 7y ago
  Thanks for the feedback! -- what you're saying makes a lot of sense. I'll mull for a bit on how to add more stateful examples, but agree they might be quite helpful.
jedisct1 7y ago
Async I/O in Rust: don't. Wait until everything gets way more stable that it is now.
- pornel 7y ago
  Someone has to try it out first, before it gets frozen.
  - shadowmint 7y ago
    Sure, but it sucks to be left with code you have to rewrite because you're donating your time to the cause to find problems and smooth the path for other people in the future. Maybe some people are in to that for fun, but the for the majority of people, the message should be: stick with stable folks.
    - Buttons840 7y ago
      Fortunately Rust is one of the closest languages to the "if it compiles it works" ideal, so big refactors aren't as bad as they otherwise would be.
networkimprov 7y ago
This, or whatever it becomes, should have been baked in when the language debuted. Rust had green threads in an early draft, but they were dropped. Hello? Cloud computing (i.e. datacenter software) requires zillions of concurrent "fibers" on a much smaller number of OS threads.
- bluejekyll 7y ago
  Progress takes time; good things take time. Rust is always trying to strike a balance between Zero overhead and ergonomics. In this case, it’s taken a lot of time (not by me, but other extremely devoted and thoughtful people) to experiment with interfaces and create things like Pin that actually allow for async/await to work with shared references between state-machines. This is a complex topic, and being an early adopter of async in Rust, I’m very happy that the wrong thing didn’t land early, but instead we’re getting a very well thought out system.
- steveklabnik 7y ago
  The implementation of those green threads wasn’t so green. Yes, it’s taken some time, but we’ve gone from a frankly pretty bad implementation to a best-in-class one, at least in terms of efficiency. These things are not simple. It would have been nice to have it years ago, but millions of lines of Rust have been written since then without the need for this stuff.
- otabdeveloper2 7y ago
  > Cloud computing (i.e. datacenter software) requires zillions of concurrent "fibers" on a much smaller number of OS threads. As a guy who actually wrote "datacenter software" for over a decade: you don't speak from experience and what you said is false. Basically, OS threads are the smallest and lightest form of concurrency currently in existence. Any userspace 'fiber' will be heavier and slower than actually spawning a pthread. The problem is when you couple pthreads with interpreter runtimes. (Python, Lua, Ruby, etc.) These runtimes (and especially the GC engines they use!) don't play nice with OS threads, so you're forced to invent various rube-goldberg fiber-like contraptions on async primities. The end result is slower, heavier and more brittle than any pthread-only solution, but interpreter runtimes necessarily impose overhead, you learn to deal with it.
chmln 7y ago
Seems a bit thin on the motivation. What are the benefits over threadpool-based executors? Nit - I already see a drawback in requiring macro-based annotations on functions and for loops - something that's not necessary today. Out of all things regarding async programming in Rust, runtime seems like one of the less important aspects. Stabilization, ecosystem, syntax, and even no_std support seem far more important.
- bluejekyll 7y ago
  There’s a big advantage to making the runtime generic, and that’s for portability. For example, it sounds like Fuchsia OS has a custom runtime over it’s own event system. Many libraries are built coupled to Tokio. But if we were encouraged through good tooling with async test interfaces, than most of these libraries would be even more portable.

146 points by Supermighty 7y ago

Cool! Having gone through this pain last weekend, I’m a bit wary of examples that are roughly stateless (or at least only do copying between channels). To all rust folks making samples: if you can mix in even a bit of mutable shared state (like a counter, logging, etc.), it goes a long way to showing whether your system can handle scoped threads/tasks, shared state, and straightforward concurrency ergonomically. If you compare and contrast the docs for crossbeam’s scoped threads, Rayon’s scope, and an attempt at DIY via raw thread::spawn, I think you want to see the same clarity on the future/async/await side. Richer examples can really elucidate the pros and cons of different paths.

yoshuaw 7y ago
Thanks for the feedback! -- what you're saying makes a lot of sense. I'll mull for a bit on how to add more stateful examples, but agree they might be quite helpful.

jedisct1 7y ago

Async I/O in Rust: don't. Wait until everything gets way more stable that it is now.

pornel 7y ago
Someone has to try it out first, before it gets frozen.
- shadowmint 7y ago
  Sure, but it sucks to be left with code you have to rewrite because you're donating your time to the cause to find problems and smooth the path for other people in the future. Maybe some people are in to that for fun, but the for the majority of people, the message should be: stick with stable folks.
  - Buttons840 7y ago
    Fortunately Rust is one of the closest languages to the "if it compiles it works" ideal, so big refactors aren't as bad as they otherwise would be.

networkimprov 7y ago

This, or whatever it becomes, should have been baked in when the language debuted. Rust had green threads in an early draft, but they were dropped. Hello? Cloud computing (i.e. datacenter software) requires zillions of concurrent "fibers" on a much smaller number of OS threads.

bluejekyll 7y ago
Progress takes time; good things take time. Rust is always trying to strike a balance between Zero overhead and ergonomics. In this case, it’s taken a lot of time (not by me, but other extremely devoted and thoughtful people) to experiment with interfaces and create things like Pin that actually allow for async/await to work with shared references between state-machines. This is a complex topic, and being an early adopter of async in Rust, I’m very happy that the wrong thing didn’t land early, but instead we’re getting a very well thought out system.
steveklabnik 7y ago
The implementation of those green threads wasn’t so green. Yes, it’s taken some time, but we’ve gone from a frankly pretty bad implementation to a best-in-class one, at least in terms of efficiency. These things are not simple. It would have been nice to have it years ago, but millions of lines of Rust have been written since then without the need for this stuff.
otabdeveloper2 7y ago
> Cloud computing (i.e. datacenter software) requires zillions of concurrent "fibers" on a much smaller number of OS threads. As a guy who actually wrote "datacenter software" for over a decade: you don't speak from experience and what you said is false. Basically, OS threads are the smallest and lightest form of concurrency currently in existence. Any userspace 'fiber' will be heavier and slower than actually spawning a pthread. The problem is when you couple pthreads with interpreter runtimes. (Python, Lua, Ruby, etc.) These runtimes (and especially the GC engines they use!) don't play nice with OS threads, so you're forced to invent various rube-goldberg fiber-like contraptions on async primities. The end result is slower, heavier and more brittle than any pthread-only solution, but interpreter runtimes necessarily impose overhead, you learn to deal with it.

chmln 7y ago

Seems a bit thin on the motivation. What are the benefits over threadpool-based executors? Nit - I already see a drawback in requiring macro-based annotations on functions and for loops - something that's not necessary today. Out of all things regarding async programming in Rust, runtime seems like one of the less important aspects. Stabilization, ecosystem, syntax, and even no_std support seem far more important.

bluejekyll 7y ago
There’s a big advantage to making the runtime generic, and that’s for portability. For example, it sounds like Fuchsia OS has a custom runtime over it’s own event system. Many libraries are built coupled to Tokio. But if we were encouraged through good tooling with async test interfaces, than most of these libraries would be even more portable.