
Asynchronous Programming in Rust - Supermighty
https://blog.yoshuawuyts.com/runtime/
======
boulos
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
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
Async I/O in Rust: don't. Wait until everything gets way more stable that it
is now.

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

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

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

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

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

~~~
the_why_of_y
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](http://erlang.org/doc/efficiency_guide/processes.html)

[2] [https://www.microsoft.com/en-us/research/wp-
content/uploads/...](https://www.microsoft.com/en-us/research/wp-
content/uploads/2009/09/multicore-ghc.pdf)

