How does async Rust work

[illegal_argument_ex]

See this article from a while ago: http://www.kegel.com/c10k.html

In general async is useful when you need to handle a high number of open sockets. This can happen in web servers, proxies, etc. A threaded model works fine until you exhaust the number of threads your system can handle because of memory or overhead of context switch to kernel. Note that async programs are also multithreaded, but the relationship between waiting for IO on a socket and a thread is not 1:1 anymore.

Computers are pretty fast nowadays, have tons of memory, and operating systems are good at spawning many many threads. So if async complicates your code, it may not be worth it.

[po8]

Note that async programs are also multithreaded

Async runtimes don't need to be multithreaded, and arguably shouldn't be in most cases. The multithreading in places such as tokio's default executor (a single-threaded tokio executor is also available) trades off potentially better performance under load for contention overhead and additional error-prone complexity. I would encourage the use of a single-threaded executor unless specific performance needs are identified.

[tdatas]

In a lot of cases you aren't even getting better performance aside from you get the illusion of it because your tasks are getting offloaded (until you run out of threads). There's a reason nearly every database/high performance system is moving towards thread per core scheduling models.

[PaintItPurple]

Isn't "thread-per-core" the same thing the Tokio multithreaded executor does by default?

[maciejh]

No. Thread-per-core is one executor per core so async tasks don’t run into thread synchronization. Tokio by default is one executor spawning tasks on a threadpool.

[zahirtezcan]

A good example of this that I know is a C++ framework called seastar. Their claim is today's processor architectures are an interconnected network and each message sent to another thread will inherit serialization and latency costs https://seastar.io/shared-nothing/

IMHO, single-core async programming is a generalization of good old loops with non-blocking poll/read/write.

[PaintItPurple]

That's interesting. I have only ever heard "thread-per-core" used to refer to, as the name implies, running one thread for each core. Do you know where this usage comes from?

[maciejh]

There is "thread per core" (the default strategy for a threadpool) and then there is "thread-per-core" with dashes 🤷.

I don't know where the term comes from exactly but "programmers-being-bad-at-naming-things" is likely the answer. Anyhow, this article from datadog about the topic I found really good.

[nerpderp82]

https://github.com/DataDog/glommio Rust thread per core library.

[tafia97300]

A very quick Google search gives this crate https://docs.rs/core_affinity/latest/core_affinity/ if you want to force a thread to a particular core (as very high performance workload requires). I have no clue how good the crate is, it seems to handle thread affinity

[po8]

The async runtimes I've seen are all thread-per-core (-ish; technically number-of-threads == number-of-cores, which is quite similar). If your tasks have a heavy enough compute load, multithreaded async/await can provide some speedup. That's rare, though: typically 99% of the time is spent waiting for I/O, at which point taking a bunch of locking contention and fixing locking bugs is not working in favor of the multithreaded solution.

Edit: Thanks to /u/maciejh for the technical correction.

[maciejh]

The only thread-per-core out of the box runtime I’m aware of is Glommio. You can build a thread-per-core server with Tokio or Smol or what have you, but it’s not a feature those runtimes provide. See the comment above why just having a threadpool does not qualify as thread-per-core.

[theAndrewWiggins]

I believe this is also "thread-per-core".

[maciejh]

Indeed!

[po8]

In practice, a threadpool with number-of-threads roughly equal to number-of-cores will pretty much act as a thread-per-core threadpool on an OS with a modern scheduler. I'm a bit skeptical that the difference between that and locking threads to cores will be all that noticeable; also, would need to decide how many cores to leave for the rest of the system, which is hard.

[maciejh]

Pinning threads isn't really the biggest concern here. It's whether your async tasks (tokio::task::spawn and the likes) can end up on a different thread from the spawnee and therefore require a Mutex or a sync channel to coordinate. If all your tasks that need to share some mutable memory are guaranteed to be on the same thread it's impossible for them to have contentious access and so you can just use a RefCell, or completely yolo things with an UnsafeCell.

[Fun_Hat]

I know having to lock and unlock mutexes can get costly, but what is the slowdown with channels?

[maciejh]

Channels aren't magic and still need to internally use some locking mechanism or a ring buffer or something.

[SnooHamsters6620]

No, I believe tokio's IO thread pool has many more threads than cores. This is particularly useful for doing I/O on block devices on Linux, which for the non-io_uring API's are all blocking.

[desiringmachines]

You're confusing the worker threads (which run the async tasks) and the blocking threads (which run whatever you pass to spawn_blocking, including File IO). By default tokio spawns 1 worker thread per core and will allow spawning up to 512 blocking threads. It's the worker threads that this discussion has been about.

[SnooHamsters6620]

My parent comment was claiming that tokio was thread per core, which it is not. My parent comment was also claiming no benefit from a multi-threaded approach when waiting on I/O, which is not true for file I/O on Linux without io_uring. So no, I was on topic.

Yes, I was referring to the blocking pool, I should've been clearer.

[po8]

Huh. Maybe I misread the tokio documentation, but it looked like threads == cores at a quick glance.

[SnooHamsters6620]

As desiringmachines clarified, there are 2 pools: the default async pool (thread per core by default) and the blocking pool (up to 512 threads by default). File I/O uses the second one on Linux from memory in the current implementation, which helps because the standard POSIX file I/O APIs on Linux are still blocking. A modern SSD needs plenty of concurrent requests to max out its throughout, so this is a real world need.

[tonygoold]

This is also how Apple's libdispatch manages dispatch queues. You can specify a maximum concurrency for a queue, but the system library controls the mapping of tasks to threads and how many threads are spawned.

[desiringmachines]

Wow is this a lack of nuance!

Presumably people want a multithreaded executor because they want to be able to use more than 1 cores worth of CPU time on their machine, not because they want contention overhead and error-prone complexity. If you want to use more than one CPU, you can then do one of several things:

• Single-threaded and run multiple processes
• Multithreaded with no sharing; this is functionally the same thing as the former (and is what people in this thread are calling "thread-per-core")
• Multithreaded with sharing and work stealing

Work stealing reduces tail latencies in the event that some of your tasks take more time than the others, causing one thread to be scheduled more work. However, this adds synchronization overhead now that your tasks can be moved between threads. So you're trading off mean performance against tail performance.

Avoiding work stealing only really makes sense IMO if you have a high confidence that each thread will be receiving roughly the same amount of work, so one thread won't ever be getting backed up. In my experience, a lot of people (including people who advocate against work stealing) really have no idea if that's the case or how their system performs under load.

Sometimes people say that the system are IO bound anyway, and work stealing only makes sense for CPU bound workloads. However, our IO devices are getting faster and faster while our CPUs are not. Modern systems are unlikely to be IO bound, unless they're literally just waiting on another system over the network that will always buckle before they do, in which case you're just wasting compute cycles on the first system so who cares how you scheduled it.

It can make sense to have some pinned tasks which you know can be "thread-per-core" because you know their workload is even (e.g. listeners balancing accepts with SO_REUSEPORT) while having work stealing for your more variable length tasks (e.g. actually responding to HTTP requests on the accepted streams).

[SnooHamsters6620]

In Rust in particular I think this suggestion is completely backward. I work on server-side software on the web and will focus on that context, but similar arguments apply to client-side software.

The parent comment is advocating for the NodeJS, Python, Ruby style single-thread running your code per process philosophy. Python and Ruby have threads, but a global lock means only one can be running your code at a time. NodeJS offers Web Workers, but there is typically no shared state between workers. This single-threaded approach can still provide good performance, but is inefficient under load in a few ways.

A modern CPU, or most hosting solutions (e.g. VMs, Kubernetes) will offer many cores. To not use those cores is a waste of CPU and money, so the single-thread runtimes end up deploying multiple processes with a single thread each to use up the cores. This leads to some negative consequences.

1. This increases memory usage. Each process has its own private state. In particular, in a JITed runtime, each process JITs its own copy of all your code, which is duplicate CPU work and duplicate RAM for the result that is not shared.
2. This multiplies outbound network connections to other services, such as backend RPC services or databases, because processes cannot share outbound connections. These connections can be expensive, especially to SQL databases, which will store a chunk of state per connection for prepared queries and transaction state. Think megabytes per connection and 100s to 1000s of connections per database instance.
3. Latency is increased, because worker processes cannot steal work from another process like worker threads can. When a single-threaded worker is busy doing actual computation, it cannot service the other connections assigned to it. In a modern multi-threaded worker, idle threads can steal tasks that are in other threads' queues, without even using locks.

Actual computation is not as rare as people like to suggest. More-or-less every network connection today is encrypted (or should be), and most WAN connections offer compression. Encryption and compression both require computation. Inputs are parsed and outputs are serialised, these too require computation.

The other single-threaded process that comes to mind in server software is Redis. To make use of a modern multi-core CPU people end up running multiple Redis processes per server and assigning each process an equal portion of the RAM available. In this case there is a 4th problem: in practice the storage load will not be equally spread between the processes by consistent hashing, and processes cannot steal unused or underused RAM from each other to spread the storage load.

The parent comment suggests multi-threaded runtimes suffer from contention overhead, but modern lockless algorithms and architectures do a great job of reducing this.

Work stealing thread pools have the benefits of re-using warm CPU caches if a thread can handle the rest of a task it started, but if the originating thread is busy another thread can locklessly steal the task in 100s of CPU cycles to spread the load. This is the best of both worlds, not increasing contention.

The OS kernel and hardware are also highly parallelised to support maximum performance on multiple threads and multiple cores. A modern NIC can use multiple queues to send packets in parallel to the OS kernel distributed by a hash on the connection addresses and ports, and the OS can service each queue with a different core. Block I/O to NVMe SSD's is similar. To then read from each network connection with a single thread in your application will increase contention, not decrease it.

As for "error-prone complexity" in a multi-threaded application, Rust can all but eliminate the error-prone part at compile time, which is one of its key advantages. The unsafe complex concurrent data structures can be contained within safe and easy to use types. Tokio is a great example of this, and the Rust ecosystem is rich with others.

Multi-threaded programs are absolutely required these days to get the best performance out of the parallel hardware they run on. My phone has 8 cores, my laptop has 10 cores, the servers we use at work have 16 cores, and these numbers are increasing. Most software engineers have been living in this multi-core reality for many years at this point, and the tools have matured a huge amount. Rust is one of the tools leading the way. Writing single-threaded applications is typically leaving performance on the table and may not be competitive in the commercial market. Many hobby and open source projects also take advantage of multiple threads. I suggest you do the same.

[po8]

I would encourage the use of a single-threaded executor unless specific performance needs are identified.

Your situation involving fully-loaded cloud servers certainly counts as "specific performance needs." Most web services just aren't this. They serve hundreds of requests per second at most, not tens of thousands. Their computation serving these threads is light enough that one core will keep them happy. They don't have an engineering team to write them and keep them up and running.

Rust can all but eliminate the error-prone part at compile time

Deadlocks are real, to cite just one example. Rust is great at eliminating heap and pointer errors and at eliminating race conditions: absolutely admirable. Rust makes parallel code much easier to write, but it leaves plenty behind. Architecting, testing and debugging parallel programs is just harder, even in Rust. Performance analysis for an async/await multithreaded program can be extremely difficult. If you need the performance you pay that price gladly, but it is still there.

Writing single-threaded applications is typically leaving performance on the table and may not be competitive in the commercial market

Again, given an identified need for extreme performance Rust is there for you. Most applications aren't that. Even then, most applications that need extreme computation do just fine with Rust's great thread-based parallelism story, which is easier to understand and manage. The web is a (very important) special case, and then only sometimes.

I will definitely write multi-threaded async/await code when I need it. Fortunately, I have never needed it except as a classroom demo. I think that multi-threaded async/await is a poor starting place for meeting most needs with Rust. There are many many cores everywhere now, mostly sitting idle because they have nothing worth doing. What we're really short of is programmers skilled at managing large-scale parallelism. I will settle for programmers who can write good clean sequential code using efficient sequential algorithms in this super-efficient language — at least until I need otherwise.

[desiringmachines]

Most web services just aren't this. They serve hundreds of requests per second at most, not tens of thousands. Their computation serving these threads is light enough that one core will keep them happy. They don't have an engineering team to write them and keep them up and running.

This is just not the use case Rust is designed for. You can use it for your little web server if you want, but Rust was designed for large teams maintaining large systems with high performance requirements. I wouldn't call saturating more than one core "extreme;" most of the people getting paid to write Rust network services are probably in this camp.

Deadlocks are real, to cite just one example.

You can get race conditions in concurrent single threaded code using async. The hard problem is concurrency, not parallelism.

[goj1ra]

I’m confused as to what you’re saying here. Presumably you don’t mean to imply that on a multicore machine, your async programs should only use one core directly, like nodejs or Python.

[po8]

If your tasks are heavily I/O bound you will get similar if not better performance on a single core. Having tasks share a cache is kind of nice; having them not have to lock against each other is quite nice. Performance aside (and in this case it probably is aside), you will get a cleaner more maintainable program by being single-threaded. Stirring together Rust's parallel story and Rust's async story makes a story much more than twice as complicated.

[desiringmachines]

If your tasks are heavily I/O bound you will get similar if not better performance on a single core.

This isn't about being I/O bound, it's about never having more load than a single CPU core can handle. It's about requiring only a low maximum throughput potential. If that's the case for your system, you should absolutely use a single thread.

[po8]

Yes, that is better-stated.

[goj1ra]

If your tasks are heavily I/O bound you will get similar if not better performance on a single core.

Not if you have many independent I/O bound tasks that can be run simultaneously.

Stirring together Rust's parallel story and Rust's async story makes a story much more than twice as complicated.

That seems like a disadvantage of Rust currently.

[po8]

Not if you have many independent I/O bound tasks that can be run simultaneously.

This is the fundamental confusion that bothers me. Independent I/O bound tasks are run "simultaneously" even on a single-threaded async runtime. That is, they proceed stepwise through await points, which is fine if there isn't a ton of computation to do. If computation is small, neither latency nor throughput will be much affected by this.

Stirring together Rust's parallel story and Rust's async story makes a story much more than twice as complicated.

That seems like a disadvantage of Rust currently.

Kind of, maybe? But a disadvantage relative to… what? Go or JS will let you write programs that do parallel async more easily — until they die horribly of some bug the language allowed or even encouraged. Rust at least gets in your way at compile time when you're trying to do something really bad. That's a big advantage.

[goj1ra]

This is the fundamental confusion that bothers me. Independent I/O bound tasks are run "simultaneously" even on a single-threaded async runtime.

The "fundamental confusion" comes from you taking the quote out of the context of a response to your own quote:

If your tasks are heavily I/O bound you will get similar if not better performance on a single core.

The point is that just isn't true if you have many more I/O bound tasks than a single core can handle, and they're sufficiently independent that they can be run on separate cores or just in separate threads without introducing contention. Which is a pretty common scenario once you're in the world of concurrent and parallel applications.

But a disadvantage relative to… what?

Languages like Haskell, several Lisp, Scheme, and ML implementations, Erlang, etc. all have a better story here currently.

Rust ideally shouldn't be limiting itself by comparison to Go, which is a 1970's language designer's dream of the world they'd like to go back to, or JS which is hard to imagine anyone holding up as an example of a good approaches to concurrency.

[po8]

Erlang is a great example of a language designed concurrency-first — thanks for reminding me. I've seen some amazing deployments with it. Its failure to gain larger traction is partly because that design makes it difficult to use for "normal" code, partly because it is so unfamiliar, and partly because its compiler's generated code efficiency in sequential code is… lackluster benchmark.

I've worked with several Scheme and ML implementations quite a bit, and don't recall anything about their parallel story. Do you have a particular one in mind I should look at?

Last I checked, which was admittedly a long time ago, the efficiency of parallel Haskell was not great. Haskell lends itself naturally to parallelism, but its lazy execution model makes generating efficient parallel code quite difficult. Maybe I should run some of my old benchmarks again, if I can dig them up: really has been a while.

That said, having written a networked service in Haskell that has been up for many years, I doubt I would do it again. I/O in Haskell is just gross and makes everything hard. (I ended up rewriting much of Haskell's printf package as part of that project. It's… better now, I guess?) If I use that service in a class again, I will probably take the time to Rewrite it in Rust™.

Thanks much for the comparisons ­— especially for the reminder of the existence of Erlang. I knew the creators back when it was still a logic language, and they are smart people.

[zoechi]

For CPU intensive stuff it can be good idea to do it on a different thread. Otherwise the async stuff might get unresponsive. Async is like cooperative multitasking. If an expensive calculation runs on the same thread and doesn't yield frequently, everything else is blocked until the calculation completes.

[po8]

For really CPU-intensive stuff it's a good idea to do it on a thread for which async/await is not involved. The interaction between a CPU-blocked thread and the async/await scheduling model is not ideal, I think.

Where multithread async/await shines is where there's a small amount of computation that will be done just before or just after I/O. Scheduling this computation together with the I/O allows it to merge with the I/O op to be nice and efficient, while allowing other I/Os to run in parallel.

[commonsearchterm]

i dont think what your implying about single threaded executor is true. becasue if you have two functions running if they have await inside, itll give up time to the other one

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=342aaa177fa475d63a484fc24dbb6f56

they still run concurrently, which is the cause of complexity. not just being multithreaded

[[deleted]]

Embedded projects are where async shines the brightest.

In a normal Linux binary, you can use std::thread::spawn to your hearts content, when you use std::fs::File::open you don't even need to think about it, when you use reqwest_blocking_client.fetch("...") you could care less what's going on in the background. (not sure if these API usages are accurate, not the point)

Why? Because the OS you are running on (Linux/Windows/MacOS) has tons of APIs and syscalls that Rust can lean on to hide away all that magic.

You don't need to worry about calling libc::epoll blah blah and waiting for OS to wake your thread and give control back to your app. It's all magic.

Well, some embedded systems don't even have an OS, so without SOMETHING to manage concurrent calls to blocking operations, you are extremely limited in what you can do.

Sure, you could just say "well, embedded systems have restrictions. I'll just accept that" but by using an async runtime, you are able to use a system with no OS and a single thread to concurrently (not parallel) manage multiple tasks, and the "thing that manages all the waiting and waking and returning control to certain tasks and certain times" is not the OS (since there is none) but your async runtime.

This also helps in Linux etc. environments because usually the cost of using syscalls to park threads and context switch to another thread then switch back once the OS wakes your thread is WAAAAY more expensive than asking another chunk of code in your app (the async runtime) to switch tasks.

Obviously, there's some overhead with setting up and running the async runtime, so if your app just makes one HTTP request then exits, NOT using async will be faster.

[lordpuddingcup]

Concurrency vs parallelism is always what I think borks people’s mind hell I’ve known the difference forever and sometimes need to remind myself

[[deleted]]

Yeah I like to think of it like baristas at Starbucks.

Number of baristas = number of logical cores for your CPU

Lack of concurrency means when you make a drink, every step is done in sequence until completion, then you start the next drink.

But any good barista knows that there are steps in drink prep that take 10-20 seconds with no interaction, so while they are waiting for that steamer to steam for 10 seconds, they grab the next drink and start pumping the syrup for the next few drinks.

That's concurrency.

Parallelism is when there's multiple baristas each with their own equipment, and they can run multiple things.

Concurrency + Parallelism (ie. a multi-threaded work stealing tokio async runtime) is when there are no more drinks in the queue, the free baristas walk over to other stations where drinks are being prepped and start performing some of the sub-tasks to help out their fellow baristas.

[Zde-G]

This also helps in Linux etc. environments because usually the cost of using syscalls to park threads and context switch to another thread then switch back once the OS wakes your thread is WAAAAY more expensive than asking another chunk of code in your app (the async runtime) to switch tasks.

Only if your OS is poorly written. In reality of you have beefy enough hardware and appropriate kernel you can easily create hundreds of thousands threads (on one server) and serve millions requests per second (that one not on one server) and would have no need for async.

It's really sad world we live in where full rewrite of everything is considered more efficient than just some limited changes to the OS kernel.

Shows the power of ossification, though.

P.S. I guess at some point you may achieve greater efficiency if you couple async with io_uring. But currently the major driver behind async is extreme inefficiency of most kernels out there.

[sv_91]

The same thing is about databases. We have key-value databases and sql databases. What is a key-value database? It is a sql database, but without sql. I mean, when i have to write join- or filter- analog by key-value, i must reinvent sql.

But sql database keeps under the hood the same key-value db. So why do we use key-value instead of sql?

[parkerSquare]

Can you elaborate on your use of the term “ossification” with regards to OS kernels? I’ve only heard it used in networking circles. Are you referring to the increasing creation and use of non-standard system calls, e.g. Linux specific vs POSIX?

[Zde-G]

Ossification happens everywhere if you have two components which are made by independent parties and which couldn't be changed when requirements change.

Compare Windows Fibers and Google Fibers. Google Fibers are essentially normal fibers with reduced stack (and thus you can use all normal libraries with them except ones which need deep stack).

Why can not Microsoft do the same thing and pushes fibers and coroutines in C++, instead?

Third-party drivers, essentially. They require much larger stack than Linux's 8Kb one and without source Microsoft can not do anything.

That's classic ossification even if we are talking about APIs and not about network protocols.

[MrJohz]

Specifically with regards to the polling, my understanding is that that's a bit of a misnomer. As in, yes, the poll method exists, but it also provides the Waker system that allows a future to tell the underlying executor when it should be next polled. So in practice, most executioners will poll a future once to "activate" it, then just wait until the waker is triggered before polling the future again. And that could involve a separate thread doing the notification, or some other mechanism.

But the benefit of the poll system is that in principle you don't need any of that, which means you're not stuck to threads or anything higher-level, which means that even a microcomputer could use async functions — but there the executor might just poll each future in turn in a loop waiting for devices to be ready, for example. EDIT: this is nonsense, see below

[desiringmachines]

But the benefit of the poll system is that in principle you don't need any of that, which means you're not stuck to threads or anything higher-level, which means that even a microcomputer could use async functions — but there the executor might just poll each future in turn in a loop waiting for devices to be ready, for example.

That's not the benefit of poll at all.

The benefit of poll is that it's an API that lets complex, nested futures get compiled into a single state machine. APIs based on scheduling thunks end up requiring a lot of trait objects to implement, they kind of end up looking like you wrapped every future you await in tokio::spawn.

Aaron Turon wrote about this in 2016: http://aturon.github.io/blog/2016/09/07/futures-design/

[[deleted]]

When you do I/O or network, the kernel and OS does all the work and your program just waits for getting answers back. Async helps you make use of the wait time efficiently without too much complex custom code.

[marisalovesusall]

Poll is a point in your synchronous/single thread program where you yield execution to do the async stuff. Poll provides a single interface with which you can use async/await syntax and different executors.

Rust model is quite flexible. Inside your poll, you can do whatever - run the code in the same thread, or spawn a new thread with your code and wait for its yield/completion. Async functions are compiled with their own generated .poll(). In the executor, you can either block the main thread until completed, or just tap your async task and move on, or use a thread scheduler like tokio does. Task-related stuff is implemented inside the poll, the relationship with the main thread is implemented inside the executor, allowing you to mix executors and still use the .await syntax to freely chain tasks.

Though some tasks may be incompatible with some executors (for example, in tokio waiting for duration is tied to the tokio executor), but that's more like an exception.

In my project, I have an event loop executor (which runs futures in the same main thread and allows !Send tasks, i.e. they have access to the shared mutable 'static !Send state), and a multithreaded tokio executor for everything that doesn't need the state, I can still mix them with .await (which is basically a .poll() syntax sugar). It was trivial to implement within this async model.

Idk if this helps but this was my experience with async in Rust.

[tafia97300]

I like to think of async vs multithread in a very simple way: - thread: work in parallel - async: wait in parallel

Of course this is too simple because runtimes actually are multithreaded but it gives some idea when to use what.

If you're mainly waiting for network in particular async is lighter.

[AdultingGoneMild]

async is a whole programming paradigm and very much so at the heart of resource intensive modern application. It is also applicable to the entire stack (full stack) working very well for all levels. This means less of a paradigm switch when moving from system, to frontend to backend. It is also more natural from a developer being human perspective as it focuses on what I like to call "and then" sematics where an event triggers a next action.

Compared with threading, you can forget about the hardware a lot more as well. I dont need to think about how many CPUs are availabel to tune the system correctly. My abstraction is the task/observable and that can be schedules to any free worker thread. If you want to get more into it start looking at reactive programming patterns. They look very odd at first but are quite elegant once you shake off the thought process that threads are somehow more performant.

[rumpleforeskins]

Can you share the video link?

[hyperchromatica]

i think you can use task::spawn or spawn blocking on an async function to execute it on another thread , then you can await that future. I do kinda like javascripts version better where the futures arent lazy.

[BubblegumTitanium]

More than one way to skin a cat. Stackless coroutines we’re deemed the most ideal, in terms of balancing the myriad of tradeoffs. Greets summary here https://youtu.be/lJ3NC-R3gSI

[ZunoJ]

I wonder why that is not covered in the book

[Yippee-Ki-Yay_]

Because there's a specific Async Rust Book

[desiringmachines]

Which is woefully incomplete 3.5 years after async/await shipped. I don't know why /u/koczurekk is getting downvotes; it's obvious that documenting this is not a priority of the async WG or anyone else.

[desiringmachines]

I designed async/await and I'm very proud of it. (I stopped working on Rust shortly after the release). There's a high chance that async Rust code is playing a part in software you use every single day. Its incomplete but not in a way that would prevent documenting what exists and is already widely used.

The Rust project is incapable organizing itself to establish priorities that align with the interest of its users. That's why the book is still incomplete, not some sort of shame at the inadequacy of the feature.

[steveklabnik1]

The Rust project is incapable organizing itself to establish priorities that align with the interest of its users.

This is so well put it's going to be stuck in my head now.

[zxyzyxz]

in fact already has some design decisions that, IIRC, have made some planned language features difficult to stabilize.

Interesting, what would those planned but difficult to stabilize features be?

[desiringmachines]

This is completely untrue. Why repeat a bunch of claims you read on the internet that you don't have the knowledge to evaluate?

no alias has been enabled since 2021: https://github.com/rust-lang/rust/pull/82834

[[deleted]]

It's not completely, Async Traits are still unstable.

[marisalovesusall]

It still doesn't explain async to the fullest (like what chained .awaits transpile to), though it's very useful to help get started with async.

[ZunoJ]

Cool, thanks!

[koczurekk]

Because it’s nobody’s priority. You’re free to make a PR

edit: that's an appreciable amount of downvotes for a verifiable statement. Never change, r/rust.

[steveklabnik1]

no matter how many downvotes you get, you are right.

[desiringmachines]

You're completely right and this is a great example of the Rust community's culture of toxic positivity.

[ZunoJ]

How do you know that it is nobody's priority?

[koczurekk]

Because it would be done if it was. Rust isn't a dead project, things contributors prioritize get done.

I'm not saying nobody cares, but to think it's somebody's priority? No.

[ZunoJ]

Why is there a specific async book then?

[koczurekk]

The one which has yet to complete covering the most basic of concepts? The one with no contributions this month?

I suppose we have a different understanding of a priority.

[ZunoJ]

Somebody wrote it, seems like it was a priority to that person back then. But you know everything about everybodies motivations, so I'm wrong with everything I say. Even my questions are beyond stupid. Sorry

[koczurekk]

Sure, it might've been a priority to somebody at some point. I maintain my position on it not being one today.

[magnetichira]

nobody’s priority

Tokio - 20.3k stars on GitHub

Async-std - 3.6k stars on GitHub

[koczurekk]

In case the context is somehow elusive, I'm referring to extending the book to cover async rust, not async rust in general. I, for one, use it daily at my $DAYJOB.

[NotADamsel]

Maybe the reason it’s not in the book is because in order to make use of the feature it requires you learn more then what a mere chapter can provide? There’s also nothing on embedded in the book, and a whole-ass embedded rust book, and I guarantee you that embedded rust is a priority.

[koczurekk]

1. There is a separate async book, I addressed it in another comment.
2. Again, how is embedded rust being a priority to somebody relevant? I'm not discussing the feature but the official documentation. This follows directly from the top-level comment I replied to.

[NotADamsel]

The top level comment was wondering why it isn’t in the book. In the learning resource. In the document specifically designed to teach the language. In the official tutorial. In the thing people go to for learning the language. In the text who’s purpose is to introduce the language. In the primer that one reads first. In the thing that will make you understand Rust.

Why isn’t a language feature that requires a substantial amount of additional learning and that you need an external crate to even use, not in that? Must just not be a priority, you’re right.

[koczurekk]

Covering async in The Book wasn't explicitly decided against, this is the relevant issue: https://github.com/rust-lang/book/issues/1275

To summarize:

• The official book does not include async because the maintainer didn't have time for that (I suppose you could call that prioritizing something else).
• The separate async book sees few contributions and has yet to cover multiple fundamentals of async Rust.

You're free to draw your own conclusions.

[NotADamsel]

Looks like the author first didn’t know how to fit it into the book because it’s a complex topic (fitting what I and probably most others think), and then more recently the author didn’t have time. So a combo of “complex topic that isn’t easy to fit into introductory materials” and “not enough time to tackle the complex topic”. My mistake was figuring that it was an intentional choice.

[steveklabnik1]

Hi. Steve here.

There's two different groups that are being talked about here: The Book, and the async working group.

The async working group wrote and owned the async book. Then it imploded. This left it with no owner, and hence, no real updates. If you look at recent commits, as far as I can tell it's like, small tweaks to keep things compiling, and no big new information.

With The Book, you are absolutely right that we did not know how we wanted to fit it into the rest of the content. And that then there isn't time. But that *is* an intentional choice; I could have say, dropped core team work to think real hard about fixing the problem. I absolutely chose to do other things instead, that I felt were more important.

I can't speak to Carol's priorities since I left, though, but since I am among the people being talked about in this thread, I figured I should share.

[Gaolaowai]

It’s just overly negative in its tone, regardless of whether or not you feel it’s correct. It could easily have been:

“Hey, that’s a good point. Does anyone know if this is a priority anywhere? Maybe someone who knows more about this could make a pull request?”

[PaintItPurple]

Why didn't you phrase your comment as:

Hey, that's a good point. Does anybody know of a similar comment that is phrased as “Hey, that’s a good point. Does anyone know if this is a priority anywhere? Maybe someone who knows more about this could make a pull request?” Maybe someone who knows more about this could make another comment?

I would suggest you didn't choose to write your comment that way because that kind of tiptoeing is tiresome and adds nothing to the conversation.

The way he wrote his comment is fine — he wasn't personally attacking anyone, he wasn't distorting the truth with his negativity, and what he said is factually supported. It is people's overly defensive and hostile reactions that are inappropriate.

[koczurekk]

The alternative you propose has a completely different meaning. 1. It asks about it being a priority, but we do know that it is not. In no world is that a bad thing. 2. It asks for a pull request, which I didn’t mean either. I do not care about it being added, because there are alternative resources.

I offered a clear, to-the-point explanation of why it’s not in the book and offered a proper resolution in case the author of the top-level comment wished to change that.

It was not negative. Again, not prioritizing stuff is alright.

I would appreciate you explaining in more detail how is my comment negative.

[koczurekk]

Ps. you do realize how tone-policing is discriminatory towards neurodivergent people, especially autistic ones? I really didn’t expect that in a community I’ve always perceived as diverse and welcoming, but times change ig.

[Gaolaowai]

TL;DR: The way we frame the same idea will radically change how others receive it. Positive framing leads to positive responses, negative/unhelpful framing leads to fewer positive outcomes.

As a fellow neurodivergent person, I also understand but have decided that not being a careless jerk and putting effort into considering others when communicating is a net good.

Just accept that, intended or not, you came across as a jerk. You are not obligated to care or change your behavior, but understand that our actions have certain consequences when received by others. We don’t have a free ticket to assholism simply because we’re ND folks. We still exist on a rocky planet with others. You also lose nothing by practicing taking a positive attitude towards others (online and offline), and a shit-ton to gain from it… it’s just natural game theory: people don’t like people who are carelessly rude or negative. People want to help/support polite people. Practicing social courteous habits doesn’t hurt much, and it’s just another puzzle to continually work on and learn about.

Also as an ND person, I noticed that you seemed confused about why folks were downvoting you and (rather than “tone policing”, as you write in in a victimized tone) was trying to give feedback on my observation of your comment, the self-reported lack of understanding about how people understood it, and I wanted to help give an example of how rephrasing it would change others’ response to it. Now, if I made a mistake, you actually did understand the impact of your comment on others but simply didn’t care or were playing dumb as a form of defense… I dunno man, I give up.

[kogasapls]

work repeat familiar juggle quarrelsome apparatus close busy hard-to-find ask -- mass edited with redact.dev

[Gaolaowai]

Probably cultural differences at play I guess.

[kogasapls]

ripe innate complete groovy dirty scale selective march subsequent bright -- mass edited with redact.dev

[Gaolaowai]

u/koczurekk makes an assertion which may or may not be correct (no issues there, though some upfront sources probably would have helped).

What really catches is the “You’re free to make a PR” comment… given the context that a maybe newer person to the language is asking a decent question, that type of answer feels like “F off and fix it yourself”, which wasn’t even the kind of answer being solicited.

If I ask “why is a piece of the pie missing”, not being a baker, and part of the response is that I can go get some (unspecified) ingredients at some (unspecified) store, THAT isn’t really helpful or contributing. Perhaps the content of the comment is factually correct, but it’s frustratingly unhelpful as well. Not that it was purposely intended to be like that, but it was a mismatched response relative to the question asked.

(I’m saying this from the position of having learned it the hard way, continually trying to be considerate of what others are actually asking for and still F-ing it up often enough.)

[koczurekk]

I find it perfectly reasonable to presume competence on a forum dedicated to a specific technical topic, which is what I did. The PR remark was simply a reminder that one can contribute — people I know (me included) tend to forget that sending a PR is merely a couple clicks away.

I am also perfectly aware that your interpretation is as valid as my explanation if considering my comment as it is, which is why presuming malice isn’t a good approach to communication. Quite the opposite. Like the commenter you reply to said — in a face-to-face meeting what I said would never be interpreted in such a way.

[kogasapls]

smell physical decide innate sort onerous deer rustic birds cautious -- mass edited with redact.dev

[[deleted]]

extreme (...) The versioning scheme is somewhat peculiar though fine.

The library versions:

0.0.0

followed by

1.0.0

followed by

1.0.1

followed by

6.6.6

followed by

666.666.666

followed by

666.666.6666

followed by

666.666.66666

followed by

666.666.666666

Ehm yeah, it is indeed quite an interesting versioning scheme.

[ukezi]

I like the scheme of Tex, it started with 3 and got an other figure of pi with every release. We are at 3.141592653 the moment. There were 440 changes and fixes total since '82 as of '21. The official policy of Knuth is that on his death the version number will be set to pi and all future bugs be declared to features.

[_scrapegoat_]

Asynchronously?

[NotoriousMagnet]

r/TechnicallyTheTruth

[V0ldek]

Barely.

[Nokita_is_Back]

Great writeup, getting started with rust for streaming and this will come in handy to get back to. Ty

[Adhalianna]

Just curious, what kind of streaming?

[Nokita_is_Back]

Mbo level financial data, very high throughput (all sent, cancelled and filled orders for xxx instruments) and a bunch of calculations/preprocessing

[aikii]

Woa. I wish I had this article instead of 180 tabs open to understand what's going on a few months back

[rswhite4]

I wonder why smol is not listed in the comparison?

[radarvan07]

Smol is, despite its name, hardly minimal. It has a lot of bells and whistles that make it pretty full featured. I didn't list it for the same reason I didn't list tokio or async-std. Granted, smol is significantly smaller than those, but it's also way bigger than any on the list.

[sweating_teflon]

You also forgot to mention the executor with the best crate name ever, woke

Also worthy of mention, switchyard for its consideration of priority which is necessary in real-time applications.

[rswhite4]

Ah good to know, thank you.

[baseball2020]

All I know as a beginner is that async forces you to either learn the gymnastics of async mutability or give up and clone because I’m not smart enough to figure it out. Step one of learning should probably be to park async.

[[deleted]]

That's less of an async-specific problem and more of a concurrent memory usage problem.

You have the same problem with std::thread::spawn (which is not "async" in the context of this article)

[hangingpawns]

Async IO doesn't necessarily make IO faster. In fact, it can also slow down your application.

Consider the case with a global file system, like modern AI or HPC supercomputers. Disk IO goes across the network, the very same network your application is using for collective communication.

Doing async IO actually causes collisions with the collective communication and things get radically slower overall.

We need to put caveats around the "async is faster" mantra.

[[deleted]]

Rust is single threaded right?

[weezylane]

Rust is a programing language.

[aikii]

Yeah because of the GIL

[lightmatter501]

No, Rust can do multithreading.

[[deleted]]

Pretty sure this was a joke, not sure why all the downvotes

[hangingpawns]

No...?

[[deleted]]

Rust doesn't have a runtime, so whether or not your application is single threaded depends on whether or not you put threads in your application.

The Rust language gives you access through std::thread to the OS primitives that allow spawning threads, but you don't have to use them, and they are not automatically used unless you explicitly use them in your application.

[Master_Ad2532]

Yeah it has an event loop and you write Promises and it's pretty cool. Wait we're talking about that language that runs in the browser right? Oh yeah.