Asynchronous Programming in Rust | Hacker News Reader

Asynchronous Programming in Rust

blog.yoshuawuyts.com

146 pointsSupermighty16 comments

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.

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.

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

Someone has to try it out first, before it gets frozen.

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.

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.

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.

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.

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.

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.

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.

> 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.

A "fiber" could be a specific state in an async state machine (e.g. a Node.js program) or a distinct stack on a M:N threads mapping (e.g. a Go program).

Either is far lighter weight than an OS thread.

What userspace fibers are you referring to?

I don't have experience with Python, Ruby, or Lua, but IIRC Python has an async mode not unlike Node.js.

Incorrect.

If you don't have to provide POSIX thread semantics, then a user space thread can be much smaller than a OS thread; for example, an Erlang process can be as small as 1.2 KB [1], and a thread in GHC's runtime can be even smaller than that [2, section 4].

With both of these, the programmer writes synchronous code that blocks on IO, and the runtime is responsible for turning that into async IO operations at the OS level.

[1] http://erlang.org/doc/efficiency_guide/processes.html

[2] https://www.microsoft.com/en-us/research/wp-content/uploads/...

You have basically written datacenter software for a decade that may be a few orders of magnitude slower or more inefficient than it needed to be. pthreads is not fibers.

Context switching between fibers can be extraordinarily fast because the kernel is not involved. I have some experience in the matter.

Rust used to have green threading as a language feature - it was only dropped because the language-based support was considered clunky, unduly restrictive and ultimately not necessary. This is reimplementing the same use cases in library form, with only minimal support in the form of a custom syntax once the async/await feature goes stable.

Reply on news.ycombinator.com