Async Rust never left the MVP state

Posted by pjmlp 5 hours ago

Async Rust never left the MVP state(tweedegolf.nl)

186 points | 89 commentspage 2

micoul81 1 hour ago|

great article

DeathArrow 3 hours ago||

I like it more how Zig is approaching async with the new IO. It avoids function coloring.

forrestthewoods 3 hours ago||

Love Rust. They simply missed the mark with async. Swing and a miss.

The risk they took was very calculated. Unfortunately they’re bad at math and chose the wrong trade-offs.

Ah well. Shit happens.

lionkor 3 hours ago||

I think Rust has a pretty solid async implementation, compared to other systems languages. I struggle to point out another systems language with a working and actually used async implementation.

swiftcoder 3 hours ago||

> Unfortunately they’re bad at math and chose the wrong trade-offs

They chose the exact same tradeoffs as C++'s async/await (and the same overall model as Python/NodeJS), so I'm not sure what that says about programming as a whole.

nromiun 3 hours ago||

Async in Rust and C++ is nothing like it is in Python or NodeJS. Choose your own runtime is a very different model than having a default one.

Not to mention Tokio (most popular runtime for Rust) is multi-threaded by default. So you have to deal with multithreading bugs as well as normal async ones. That is not the case with most async languages. For example both Python and NodeJS use a single thread to execute async code.

swiftcoder 2 hours ago||

> Async in Rust and C++ is nothing like it is in Python or NodeJS. Choose your own runtime is a very different model than having a default one.

Python still has pluggable eventloops - this is sort of mandatory to interact with weird things like GUI toolkits, and Python's standard event loop was standardised pretty late in the game. Early on there was even an ecosystem split between Twisted and competing event loops implementations.

> For example both Python and NodeJS use a single thread to execute async code

I'd argue this is more a historical artefact of how the languages functioned before futures were introduced, rather than an inherent limitation.

nromiun 2 hours ago||

It is an inherent limitation. Multithreading is not free after all. One of the big pros of async programming is the concurrency you get within a single thread. When you make the async runtime multithreaded by default (like Tokio) you don't get this advantage anymore.

swiftcoder 1 hour ago||

You can put tokio in single-threaded mode if you prefer - it's an explicit performance tradeoff. The multithreaded work-stealing executor has higher throughput at the expense of needing more synchronisation.

Or you can schedule your thread-local tasks in a LocalSet to run them all on the owning thread, while keeping the other threads around to handle tasks that are intentionally parallel.

The general theme here is that tokio (and C++ equivalents) provide you the flexibility to do more things than the native Python/Node runtime does (and yes, the defaults take advantage of this). But the underlying intention is the same (and post-GIL we expect to see some movement in this direction on the Python front as well).

slopinthebag 4 hours ago|

It's so funny that people will do anything to hate on Rust, including nitpicking a few bytes of overhead for a future while they reach for an entire thread or runtime to handle async in their favourite language.

berkes 3 hours ago||

I know the people and the company behind this article. They do anything but "hate on Rust".

You could've deduced that from the fact that someone who puts this amount of energy in a detailed article about intricacies of an area of "foo", quite certainly does not "hate on foo".

slopinthebag 3 hours ago||

Not the article, the comments here man.

The article is fine besides the bait title.

lionkor 3 hours ago|||

It's more that I and people I know love Rust, and enjoy it, and want it to be better. I want it to be relentlessly optimized.

rnijveld 4 hours ago|||

You realize this article talks about Rust on embedded hardware specifically, where you don’t have threads or big runtimes? There is no hate going on here either, just attempts to make things better. Might I suggest you click through to the homepage and I think you’ll figure out the rest.

jjgreen 1 hour ago|||

That's a bit rich given the abuse that Rust evangelists dish out to every other language in the world.

MrBuddyCasino 3 hours ago|||

Nobody seriously tries to run Golang or Java on an MCU. But they do run Rust code.

gspr 3 hours ago||

I _love_ Rust and use it whenever I can. I still find the comments in here to be quite appropriate. Async Rust leaves me with a (subjective!) feeling that something isn't quite right. Not that I know how it _should_ be, but that feeling is very different from the non-async parts of the language that almost always leaves me with a warm fuzzy feeling of joy.

I don't know enough about the domain to be objectively helpful, so it's all wishy-washy feelings on my part. I keep reaching for orchestrating things with threads in Rust where most people would probably reach for async these days. The only language where I've felt fine embracing the blessed async system is Haskell and its green threads (which I understand come with their own host of problems).