Rust async/await hits stable tomorrow(github.com)
github.com
Rust async/await hits stable tomorrow
https://github.com/rust-lang/rust/blob/master/RELEASES.md
35 comments
I don't understand the obsession with async code. I can understand it with JavaScript: browser environment was crippled and node copied that instead of making proper threading available. But for most environments it's not a problem. Just use thread pool and enjoy sane sequential programming model. Yes, it might not work for Google scale. But it should work for the vast majority of projects and if you really need to think about scaling, you should think about scalable architecture to be able to scale to multiple machines.
It's like every programming language and framework today suddenly decides to introduce those async primitives and I've yet to find a single use-case for it in my projects.
It's like every programming language and framework today suddenly decides to introduce those async primitives and I've yet to find a single use-case for it in my projects.
If your code is simple with thread pools, it will be just as simple with async/await.
The biggest problem with thread pools is that you have a limited number of threads. Either because you set an explicit size limit, or you run out of memory. It's really annoying to debug deadlocks that happen because your thread pool is out of threads. So typically applications that use thread pools just don't use parallelism as much as they would if they could use async/await.
There isn't really any advantage of thread pools. Programming in Go, for example, it's very easy to write async calls and quite awkward to explicitly manage threads. But in practice, there are never really any reasons you miss having thread pools.
The biggest problem with thread pools is that you have a limited number of threads. Either because you set an explicit size limit, or you run out of memory. It's really annoying to debug deadlocks that happen because your thread pool is out of threads. So typically applications that use thread pools just don't use parallelism as much as they would if they could use async/await.
There isn't really any advantage of thread pools. Programming in Go, for example, it's very easy to write async calls and quite awkward to explicitly manage threads. But in practice, there are never really any reasons you miss having thread pools.
If you are deadlocking, you have a bug. If you hit OOM, you most likely have leaks or went wild with threads or allocations.
Both of those conditions are orthogonal to async/thread pools, so what do you mean?
Both of those conditions are orthogonal to async/thread pools, so what do you mean?
I mean, if your thread pool has 10 threads available, and your code attempts to run an 11th thread, you can run into a deadlock. Whereas that same code written with async/await can run fine.
You can call that "going wild with threads" but in an async/await model it is often just fine to use that many async calls.
You can call that "going wild with threads" but in an async/await model it is often just fine to use that many async calls.
> Just use thread pool
Rust's Tokio runtime uses a thread pool. As does C#'s asynchronous runtime. Goroutines are also multiplexed among threads. Asynchronous primitives and multithread programming are not mutually exclusive, Javascript not withstanding.
Interestingly, one language is indeed bucking the trend. Java is introducing fibers (lightweight user-mode threads) that allow traditional (sane, as you call it) code to be efficiently scheduled so that it "performs as well as asynchronous code" without introducing new language primitives. So you'll have the opportunity to see which works best in important mainstream languages. One wonders if Java won't pull off a surprise win here.
> you should think about scalable architecture to be able to scale to multiple machines
No, sorry; that's not a viable approach. CPUs are highly concurrent beasts with dozens of cores. Using these inefficiently with traditional blocking threads is not feasible even if you can spread the inefficiency across "multiple machines." That would simply waste expensive hardware, power, space and cooling. Asynchronous techniques solve real efficiency problems in the real world; it isn't a fad. And you can't fall back to "most projects don't need it" in the context of advising others how to scale large systems; they do indeed "need it" and they will continue to gravitate to programming platforms that provide it while abandoning those that do not.
Rust's Tokio runtime uses a thread pool. As does C#'s asynchronous runtime. Goroutines are also multiplexed among threads. Asynchronous primitives and multithread programming are not mutually exclusive, Javascript not withstanding.
Interestingly, one language is indeed bucking the trend. Java is introducing fibers (lightweight user-mode threads) that allow traditional (sane, as you call it) code to be efficiently scheduled so that it "performs as well as asynchronous code" without introducing new language primitives. So you'll have the opportunity to see which works best in important mainstream languages. One wonders if Java won't pull off a surprise win here.
> you should think about scalable architecture to be able to scale to multiple machines
No, sorry; that's not a viable approach. CPUs are highly concurrent beasts with dozens of cores. Using these inefficiently with traditional blocking threads is not feasible even if you can spread the inefficiency across "multiple machines." That would simply waste expensive hardware, power, space and cooling. Asynchronous techniques solve real efficiency problems in the real world; it isn't a fad. And you can't fall back to "most projects don't need it" in the context of advising others how to scale large systems; they do indeed "need it" and they will continue to gravitate to programming platforms that provide it while abandoning those that do not.
The biggest benefit I see with Async code is that a thread can go back to the thread pool while you as an example wait for a response from a HTTP request to an external service
Yes that's the definitive use case. Usually you have to explicitly describe the wait, so you need to write the code a certain way. I think OP was referring to the fact that threading / forking processes is usually just as effective, and you don't have to rewrite all your code from the ground up.
> It's like every programming language and framework today suddenly decides to introduce those async primitives and I've yet to find a single use-case for it in my projects.
Consider that maybe this is because your projects are not the intended targets of async programming.
Async is super not new. Fibers and CSP and etc. are not new. A lot of the benefit of better concurrency is exactly for stuff that scales horizontally, but just because you can scale to hundreds of boxes does not mean you want each box to be bottlenecked on how many connections it can handle. For servers you absolutely want to be able to use your nodes to their fullest. Demand for this is almost certainly driving programming languages.
10 boxes handling 10000 connections > 100 boxes handling 1000 connections (edit: each)
Consider that maybe this is because your projects are not the intended targets of async programming.
Async is super not new. Fibers and CSP and etc. are not new. A lot of the benefit of better concurrency is exactly for stuff that scales horizontally, but just because you can scale to hundreds of boxes does not mean you want each box to be bottlenecked on how many connections it can handle. For servers you absolutely want to be able to use your nodes to their fullest. Demand for this is almost certainly driving programming languages.
10 boxes handling 10000 connections > 100 boxes handling 1000 connections (edit: each)
You can use async network calls to handle multiple number of connections (in library code) yet use thread pool to write business logic (application code).
I'm not suggesting to just use blocking I/O API. Non-blocking API like select/epoll/etc is very useful and should be utilized whenever possible. I'm about those language features.
I'm not suggesting to just use blocking I/O API. Non-blocking API like select/epoll/etc is very useful and should be utilized whenever possible. I'm about those language features.
Why is this approach nicer than event loops w/ async/await or goroutines? I think forcing humans to manually deal with continuations is not humane :)
Why do you want to make your code more complex by using select/epoll/etc and making continuation spaghetti instead of just embracing async?
You are mixing up asynchronous IO with non-blocking IO with async syntax sugar.
As the name implies, async syntax sugar is a convenience, it does not magically improve performance.
As the name implies, async syntax sugar is a convenience, it does not magically improve performance.
It's really nice on embedded systems for one. Share a single stack, but have blocking looking code. I really like the Rust model where astnc/await is mainly syntax sugar, and you can just code the state machine manually if you want.
Edit: It's also nice on servers, because even if you have memory for all of those stacks in a no astnc world, you def don't have cache for all of them. Splitting the data that needs to be saved between blocking points from the temporary data that gets you to the next block point (and reusing that memory on the next task) has benefits in a modern memory architecture.
Edit: It's also nice on servers, because even if you have memory for all of those stacks in a no astnc world, you def don't have cache for all of them. Splitting the data that needs to be saved between blocking points from the temporary data that gets you to the next block point (and reusing that memory on the next task) has benefits in a modern memory architecture.
Rust shines as a language that both allows threaded and async programming, especially by being able to model concurrency issues.
But async programming was always hampered by several issues, which made it's own code generation and syntax necessary. Mostly, that's borrowing over yield points.
This enables Rust to be a language about choice: you can easily mix async and threaded code, with both being supported by the language just as well. The magic is that the `async/.await` support doesn't come with a runtime, you can choose it yourself.
Want predominantly threaded stuff? Use a threadpool (and maybe `await` the result). Predominantly concurrency? Use a runtime like https://async.rs and let run your code on that.
But async programming was always hampered by several issues, which made it's own code generation and syntax necessary. Mostly, that's borrowing over yield points.
This enables Rust to be a language about choice: you can easily mix async and threaded code, with both being supported by the language just as well. The magic is that the `async/.await` support doesn't come with a runtime, you can choose it yourself.
Want predominantly threaded stuff? Use a threadpool (and maybe `await` the result). Predominantly concurrency? Use a runtime like https://async.rs and let run your code on that.
Nodejs make proper threading available:
https://nodejs.org/api/worker_threads.html
> I've yet to find a single use-case for it in my projects.
This is the “concurrency vs parallelism” that (e.g.) Rob Pike goes on about[0], rightfully. I think to the uninitiated it can be tough to grasp (not commenting on whether YOU understand or not...). I use it daily, depending on circumstances, w a single-threaded network client that concurrently manages connections to perhaps hundreds of other machines. Most of the wall-time is spent waiting for something to occur on one of the remotes; “waiting in parallel” isn’t going to speed anything up, and nothing happens outside of the relatively infrequent events from the outside network to my client. I can’t forecast what is going to arrive on which socket, so I wait, and process asynchronously. GUIs will operate this way too. The pattern is suitable where you’re in a situation where: “something might happen sometime and I’ll need to do a (quick) bit of work in response”
[0] https://youtu.be/cN_DpYBzKso
This is the “concurrency vs parallelism” that (e.g.) Rob Pike goes on about[0], rightfully. I think to the uninitiated it can be tough to grasp (not commenting on whether YOU understand or not...). I use it daily, depending on circumstances, w a single-threaded network client that concurrently manages connections to perhaps hundreds of other machines. Most of the wall-time is spent waiting for something to occur on one of the remotes; “waiting in parallel” isn’t going to speed anything up, and nothing happens outside of the relatively infrequent events from the outside network to my client. I can’t forecast what is going to arrive on which socket, so I wait, and process asynchronously. GUIs will operate this way too. The pattern is suitable where you’re in a situation where: “something might happen sometime and I’ll need to do a (quick) bit of work in response”
[0] https://youtu.be/cN_DpYBzKso
The same can be achieved easily with non-blocking IO with an event loop.
In addition, several threads will go faster than one as soon as any two remotes overlap.
In addition, several threads will go faster than one as soon as any two remotes overlap.
It's particularly a big deal in Rust where working with the base Future primitives was pretty hairy. With async/await I can write code that looks synchronous but has all the advantages of async.
Async is much easier to program than threads (even thread with Rust). You might be working very low-level where you don't have an OS and thus no threads. Rust's works on those devices too. Like you can use this to implement an OS.
I think that there's going to be a new os written in Rust. It will be much lower level than all the current OS. You don't need a lot of protection when the compiler protects you.
I think that there's going to be a new os written in Rust. It will be much lower level than all the current OS. You don't need a lot of protection when the compiler protects you.
Providing support at the language level gives application developers more tools. If they know their own application domain, perhaps they can make better scheduling decisions than a general purpose scheduler?
> But it should work for the vast majority of projects and if you really need to think about scaling, you should think about scalable architecture to be able to scale to multiple machines.
Or not. To me, that's like saying "If you need to worry about how to fit your data in memory, you should just move to Hadoop, or something like that instead".
Async/Await is especially suited to Rust though because Rust is all about safety/performance/ergonmics. Async/Await in particular allows eliminating of unsafe blocks that one would have to use to achieve the same level of performance by manually implementing state machines for futures.
Also, generally speaking, I think futures are good, performant abstraction over asynchronous code. It's required a lot of work to get it to stable, and there's still a lot of work to be done to address the multitude of paper-cuts left, but the dividends are huge.
Or not. To me, that's like saying "If you need to worry about how to fit your data in memory, you should just move to Hadoop, or something like that instead".
Async/Await is especially suited to Rust though because Rust is all about safety/performance/ergonmics. Async/Await in particular allows eliminating of unsafe blocks that one would have to use to achieve the same level of performance by manually implementing state machines for futures.
Also, generally speaking, I think futures are good, performant abstraction over asynchronous code. It's required a lot of work to get it to stable, and there's still a lot of work to be done to address the multitude of paper-cuts left, but the dividends are huge.
First of all, the “I don’t understand it therefore I assume it is bad and wrong until proven otherwise” trope is a tired one. Secondly, Rust does a great job of documenting its features so these questions are usually already answered.
Why Async?
https://rust-lang.github.io/async-book/01_getting_started/02...
Why Async?
https://rust-lang.github.io/async-book/01_getting_started/02...
He said he didn’t understand the obsession, that’s not the same as not understanding it.
So I work at Facebook and day in and day out use Hack (Facebook's split from PHP) and one thing that's ingrained in the programming model is the async-await model.
PHP/Hack have a model that I think is probably the best overall method for serving HTTP requests in that within the context of a single request, none of the code is multithreaded. I say this is superior because you don't have to worry about race conditions (largely), locking and all that. You might call services that do that but you're insulated from the multithreaded issues of that.
Anyway, knowing that Hack's async-await is strictly cooperative multitasking rather than being multithreaded so you get concurrency and non-blocking I/O without the mental and code cost of threads and locks.
That's why I think it's a big deal.
PHP/Hack have a model that I think is probably the best overall method for serving HTTP requests in that within the context of a single request, none of the code is multithreaded. I say this is superior because you don't have to worry about race conditions (largely), locking and all that. You might call services that do that but you're insulated from the multithreaded issues of that.
Anyway, knowing that Hack's async-await is strictly cooperative multitasking rather than being multithreaded so you get concurrency and non-blocking I/O without the mental and code cost of threads and locks.
That's why I think it's a big deal.
> I can understand it with JavaScript: browser environment was crippled and node copied that instead of making proper threading available.
This is false.
Single-threaded async for the server side was popularized by nginx, which started in 2002. Somewhere in 2007-2009 the Tornado web server showed that even Python could be fast and scalable using this model. In 2009 when node was first released, single-threaded async was already a thing.
What made node interesting was that it came with a pre-existing language where nonblocking code was idiomatic. This removes a lot of the pain of single-threaded async that you see in something like Java where it's easy to accidentally use a blocking call. And speaking of Java, that's also where multithreaded is painful because generally you have mutability, so you really need to know what you're doing to avoid race conditions. At every line where you mutate anything, you have to ask yourself, "what if the thread gets preempted here?" In JavaScript you only have to ask the equivalent question on lines where you see `await`.
This is false.
Single-threaded async for the server side was popularized by nginx, which started in 2002. Somewhere in 2007-2009 the Tornado web server showed that even Python could be fast and scalable using this model. In 2009 when node was first released, single-threaded async was already a thing.
What made node interesting was that it came with a pre-existing language where nonblocking code was idiomatic. This removes a lot of the pain of single-threaded async that you see in something like Java where it's easy to accidentally use a blocking call. And speaking of Java, that's also where multithreaded is painful because generally you have mutability, so you really need to know what you're doing to avoid race conditions. At every line where you mutate anything, you have to ask yourself, "what if the thread gets preempted here?" In JavaScript you only have to ask the equivalent question on lines where you see `await`.
Can we avoid posting "1 day earlier" news? We're just going to dilute the discussions
Otherwise we end up having to penalize the actual thing as a dupe, or have repetitive split discussion.