Asynchronous clean-up(without.boats)
without.boats
Asynchronous clean-up
https://without.boats/blog/asynchronous-clean-up/
71 comments
I liked the first sentence or two of your comment but I quickly stopped following.
Any concurrency model has tightly coupled & specific semantics about scheduling and cancellation: that's what a concurrency model is meant to provide. The semantics of "synchronous code" are just treated as natural by programmers because it's what they've been taught their whole lives, but someone had to invent that too (Edsger Dijkstra & Tony Hoare, specifically).
If all you mean to say is "the async model means whether a function synchronizes with a concurrent process becomes part of its contract", yes that's true, but the idea that this is "eroding modularity" and not "including essential facts about function behavior in its type signature" is an assertion of design principle, not a statement of fact.
Any concurrency model has tightly coupled & specific semantics about scheduling and cancellation: that's what a concurrency model is meant to provide. The semantics of "synchronous code" are just treated as natural by programmers because it's what they've been taught their whole lives, but someone had to invent that too (Edsger Dijkstra & Tony Hoare, specifically).
If all you mean to say is "the async model means whether a function synchronizes with a concurrent process becomes part of its contract", yes that's true, but the idea that this is "eroding modularity" and not "including essential facts about function behavior in its type signature" is an assertion of design principle, not a statement of fact.
I am likely not even at 10% of the competence of the author but I can't help but notice the continuously mentioned struggle of "but what if we cancel the cancellation?" -- which to me seems to be the wrong question to ask. IMO it should not be possible. It should be made impossible by the compiler. The "everything is cancellable" rabbit hole is infinite and is not worth pursuing. Eventually the Rust core team will be inspecting CPU microcode and its bugs, or what's the endgame exactly? So let's not go there, I say.
I know that Rust does not have a runtime and it does not have a spec but I think the questions posed in the article hint at the need for either -- or even both at the same time (i.e. "make a spec for the third party runtime implementors").
I am not saying "imitate Golang or Erlang". I am saying: "just pick a side already".
On a more intuitive level: to me it feels like Rust tries to be everything for everyone, and I think many of us know that will never work.
Choose. Commit. Double down. Make it work. Golang and Erlang did. Rust can do it as well.
I know that Rust does not have a runtime and it does not have a spec but I think the questions posed in the article hint at the need for either -- or even both at the same time (i.e. "make a spec for the third party runtime implementors").
I am not saying "imitate Golang or Erlang". I am saying: "just pick a side already".
On a more intuitive level: to me it feels like Rust tries to be everything for everyone, and I think many of us know that will never work.
Choose. Commit. Double down. Make it work. Golang and Erlang did. Rust can do it as well.
Async Rust code is currently well-suited to both web servers and embedded. I, for one, would be very sad if they "just picked a side" that excluded one of these (very different) use cases.
Yeah, I literally do both, and it's sweet as hell.
Nowhere did I imply I want to take stuff from people. You could have read my comment charitably and without the unnecessary snark.
Check my other sibling comment where I reply to the OP's author.
Check my other sibling comment where I reply to the OP's author.
I'm not sure where you read snark in my comment, but I can assure you it was unintentional.
Well, the quotes when saying:
> I, for one, would be very sad if they "just picked a side" that excluded one of these (very different) use cases.
...did not help.
And again, my comment was more generic and I even explained why: because I can't claim the level of competence of OP's author.
> I, for one, would be very sad if they "just picked a side" that excluded one of these (very different) use cases.
...did not help.
And again, my comment was more generic and I even explained why: because I can't claim the level of competence of OP's author.
I cannot follow your comment.
Being automatically cancellable is part of the value proposition of the future abstraction: it lets you abandon unnecessary work automatically. This post is about a limitation on cancellation (cancellation itself must be synchronous).
To me, your comment appears to be a sort of vibey free word association. Microcodes? Pick a side? What on earth are you actually trying to express??
Being automatically cancellable is part of the value proposition of the future abstraction: it lets you abandon unnecessary work automatically. This post is about a limitation on cancellation (cancellation itself must be synchronous).
To me, your comment appears to be a sort of vibey free word association. Microcodes? Pick a side? What on earth are you actually trying to express??
I believe what they're trying to get at is related to the following quote from your article:
> This also alleviates the need for considering any sort of question about “what happens if you cancel the cancellation future,” and whether that is recursive or idempotent: once a future begins canceling, “canceling” it again is idempotent, because its already canceling; there is no second future to cancel.
I think the misunderstanding they had is that what you call "async cancellation" requires a second future (which is implicitly constructed from `poll_cancel` or something like that), whose entirely purpose is to run the cancellation code of the first future. If this were the case, then we'd have to ask the question "What happens if the cancellation future is cancelled? Who cleans up after it?"
I don't have enough experience with async Rust in practice yet (sadly), so I was also tripped up when reading at first. I think that you call it "async cancellation" makes people think that it's a separate future, even though (from the type signature of `poll_cancel`) it should be completely clear that it isn't.
Sorry, I hope I got everything right, and that this clears up what I believe to be the misunderstanding for everyone involved!
> This also alleviates the need for considering any sort of question about “what happens if you cancel the cancellation future,” and whether that is recursive or idempotent: once a future begins canceling, “canceling” it again is idempotent, because its already canceling; there is no second future to cancel.
I think the misunderstanding they had is that what you call "async cancellation" requires a second future (which is implicitly constructed from `poll_cancel` or something like that), whose entirely purpose is to run the cancellation code of the first future. If this were the case, then we'd have to ask the question "What happens if the cancellation future is cancelled? Who cleans up after it?"
I don't have enough experience with async Rust in practice yet (sadly), so I was also tripped up when reading at first. I think that you call it "async cancellation" makes people think that it's a separate future, even though (from the type signature of `poll_cancel`) it should be completely clear that it isn't.
Sorry, I hope I got everything right, and that this clears up what I believe to be the misunderstanding for everyone involved!
The design in Eric Holk's post that I link has that property because it has an `on_cancel` combinator to add a future to run when another future is cancelled (and anticipates the problem of then cancelling that future and so on); that section of my post is just about why I wouldn't have that combinator and how if you don't, this problem doesn't exist.
I was mostly trying to express that chasing after everything being cancelable is IMO not worth it i.e. cancelling the destructor code should not ever happen -- the compiler / runtime should not allow it ever.
Again, my opinion only. Feels like too much complexity for no payoff.
The other person replying to you understood me correctly.
Again, my opinion only. Feels like too much complexity for no payoff.
The other person replying to you understood me correctly.
Reading about async Rust is like reading about a large complicated infrastructure project that keeps getting delays and cost overruns. Rust will end up spending a significant part of its complexity budget on async alone. I wonder if it's worth it, for a problem that gets significantly easier if you are prepared to be just a bit more wasteful (allocations, memory, etc). Compare with Ocaml or Haskell for instance.
The way I see it, Rust is trying to do something novel -- imperative-style async/await in a 'true' systems language. That's a fundamentally hard problem, so their implementation is going to have warts. But it will serve as a great reference for the next batch of languages developed which want to do such things. The work is valuable for the state of computing, even if we don't get something perfectly and spotless in Rust itself.
It's hard to call something virtually every other systems language does 'novel' given for example C++ has async/await though?
Rust shipped async/await before C++ (Rust in 2019, C++ in 2020). C++'s version is not memory safe.
> C++'s version is not memory safe.
As a C++ engineer with 20+ years of experience, I recently had an employer project migrate to C++20 and shortly then C++23. We started using coroutines. Oh goodness they're fun. The simple things are indeed simple and easy.
And actually fairly easy to get wrong, too. Way too easy. I might know how coroutines work but goodness it's been difficult training the rest of the team.
It's when you start to get true asynchronicity with multiple jobs running concurrently and each job might have a different workflow... well all of the synchronization and waiting for multiple jobs doesn't quite exist in the standard yet. So the standard provides the language tools but third party libraries provide the actual functionality -- to various degrees of success. We use boost asio's awaitable and there's clearly some warts and even gaps in functionality that we've had to work around.
I like early adopting many things. Adopting coroutines, even in C++23, was perhaps a little too-early.
I really wish my employer would give me time (say... 2 years) to clean up a ton of things not just in our codebase but also in the libraries we use and even propose fixes to the standard itself.
As a C++ engineer with 20+ years of experience, I recently had an employer project migrate to C++20 and shortly then C++23. We started using coroutines. Oh goodness they're fun. The simple things are indeed simple and easy.
And actually fairly easy to get wrong, too. Way too easy. I might know how coroutines work but goodness it's been difficult training the rest of the team.
It's when you start to get true asynchronicity with multiple jobs running concurrently and each job might have a different workflow... well all of the synchronization and waiting for multiple jobs doesn't quite exist in the standard yet. So the standard provides the language tools but third party libraries provide the actual functionality -- to various degrees of success. We use boost asio's awaitable and there's clearly some warts and even gaps in functionality that we've had to work around.
I like early adopting many things. Adopting coroutines, even in C++23, was perhaps a little too-early.
I really wish my employer would give me time (say... 2 years) to clean up a ton of things not just in our codebase but also in the libraries we use and even propose fixes to the standard itself.
It's way ahead of C++ in terms of async.
So much time is spent on async because it's important and most other languages have ignored it for a long time.
Ever tried libuv in C? That was just a nightmare to work with, callbacks within callbacks within callbacks.
Rust's approach to async is the best I've seen so far in any language, even high level languages like javascript that depend on async to even function.
So much time is spent on async because it's important and most other languages have ignored it for a long time.
Ever tried libuv in C? That was just a nightmare to work with, callbacks within callbacks within callbacks.
Rust's approach to async is the best I've seen so far in any language, even high level languages like javascript that depend on async to even function.
> Rust's approach to async is the best I've seen so far in any language
I'm not a Rust programmer but have used async/await in both Python and C#. I've also written concurrent code in Erlang. I'd choose the Erlang approach over async/await every time. One concurrency primitive - the process - and an ergonomic, coherent set of supporting features (message passing, supervisors). No function colours and all the baggage that comes with that. Less well discussed but no less important: it puts concurrency decisions in the hands of the function caller, not the implementer.
I understand Rust's focus on zero cost abstractions and, whilst I wouldn't pretend to understand the innards and consequences, get why green threads might not be compatible with that. OTOH that restriction doesn't hold for languages with a runtime like C# and Python. I'm increasingly convinced the compromises of async/await make it a poor language design for the concurrency problem when the language has a runtime.
Perhaps we'll see some comparitive studies now Java has green threads. Erlang is different from C#/Python in many ways so straight comparison is hard. Java is much closer to C# so should be a much better basis for comparison.
I'm not a Rust programmer but have used async/await in both Python and C#. I've also written concurrent code in Erlang. I'd choose the Erlang approach over async/await every time. One concurrency primitive - the process - and an ergonomic, coherent set of supporting features (message passing, supervisors). No function colours and all the baggage that comes with that. Less well discussed but no less important: it puts concurrency decisions in the hands of the function caller, not the implementer.
I understand Rust's focus on zero cost abstractions and, whilst I wouldn't pretend to understand the innards and consequences, get why green threads might not be compatible with that. OTOH that restriction doesn't hold for languages with a runtime like C# and Python. I'm increasingly convinced the compromises of async/await make it a poor language design for the concurrency problem when the language has a runtime.
Perhaps we'll see some comparitive studies now Java has green threads. Erlang is different from C#/Python in many ways so straight comparison is hard. Java is much closer to C# so should be a much better basis for comparison.
This post illustrates a common and unfortunate misconception about async/await.
It's not "hurr durr don't block thread" which is where a lot of developers stop reading at, at their own loss. And then come asking about green threads in github issues in a classic X Y problem fashion.
It is a paradigm where method calls represent an asynchronously produced result, a Task/Promise. Therefore, if all you do is always just await all the results right after calling async methods, you have not used the other 80% of the features.
Task<T> is about composing, chaining and interleaving the tasks, sometimes hundreds or thousands at a time, to achieve (sometimes massively) parallel and concurrent execution of application logic. And we are blessed with C# making it as easy as it gets.
It's not "hurr durr don't block thread" which is where a lot of developers stop reading at, at their own loss. And then come asking about green threads in github issues in a classic X Y problem fashion.
It is a paradigm where method calls represent an asynchronously produced result, a Task/Promise. Therefore, if all you do is always just await all the results right after calling async methods, you have not used the other 80% of the features.
Task<T> is about composing, chaining and interleaving the tasks, sometimes hundreds or thousands at a time, to achieve (sometimes massively) parallel and concurrent execution of application logic. And we are blessed with C# making it as easy as it gets.
You don't need the syntax tho. You can do green threading without function colouring. Rust might be the only language with an excuse to do it without green threading but only insofar as async doesn't presuppose native threading. But then why not just have a trait when you need to ensure you're the only thing executing on a single thread.
Please re-read the comment, thank you.
In addition, there are single-threaded and thread-per-core executors with different future bounds. It is that Tokio puts more requirements on Send and Sync because it is a proper implementation with worker-per-core (configurable to be otherwise) + work stealing.
In addition, there are single-threaded and thread-per-core executors with different future bounds. It is that Tokio puts more requirements on Send and Sync because it is a proper implementation with worker-per-core (configurable to be otherwise) + work stealing.
async/await is a language design feature to enable fine-grained concurrency. Where "fine grained" means "more fine" than OS processes or threads allow.
> Task<T> is about composing, chaining and interleaving the tasks, sometimes hundreds or thousands at a time, to achieve (sometimes massively) parallel and concurrent execution of application logic.
Replace Task<T> with Erlang processes and the statement holds. Except without coloured functions; without the async decision being in the wrong place; without codebases where dual versions of functions proliferate (DoSomething() / DoSomethingAsync()).
At its heart, concurrency is about being able to express multiple sequences of actions such that there's no undesired interaction between them when running. Thread blocking is one form of undesired interaction. So "hurr durr don't block thread" does matter even if it's not the only thing.
> Task<T> is about composing, chaining and interleaving the tasks, sometimes hundreds or thousands at a time, to achieve (sometimes massively) parallel and concurrent execution of application logic.
Replace Task<T> with Erlang processes and the statement holds. Except without coloured functions; without the async decision being in the wrong place; without codebases where dual versions of functions proliferate (DoSomething() / DoSomethingAsync()).
At its heart, concurrency is about being able to express multiple sequences of actions such that there's no undesired interaction between them when running. Thread blocking is one form of undesired interaction. So "hurr durr don't block thread" does matter even if it's not the only thing.
In C#, interleaving various tasks is as easy as
In addition, because Task<T> is a thread-safe object in C#, you can apply all kinds of transformations and data chaining with LINQ on collections/sequences of those, or even together with parallel LINQ and tasks at the same time. Your simple average code will easily scale to all CPU cores if it does not have interdependencies/contention (a lot of LOB codebases don't, it's all straight line up to a DB or a third-party call(s)).
And last but not least, all BEAM-based languages are comparatively slow (hard performance ceiling is always imposed if you don't pay with static typing and full JIT/AOT) and unfortunately suffer from high heap footprint, even compared to the more throughput-focused GC modes in .NET and GC implementations in JVM. But no, developers are insistent on parroting quotes said 10 to 15 years ago instead of at least attempting to assess technologies on their merits of today.
var data1 = service1.GetData();
var data2 = service2.GetAnotherData();
var aggregate1 = Aggregate(await data1);
var result = Handle(await aggregate1, await data2);
In addition, because Task<T> is a thread-safe object in C#, you can apply all kinds of transformations and data chaining with LINQ on collections/sequences of those, or even together with parallel LINQ and tasks at the same time. Your simple average code will easily scale to all CPU cores if it does not have interdependencies/contention (a lot of LOB codebases don't, it's all straight line up to a DB or a third-party call(s)).
And last but not least, all BEAM-based languages are comparatively slow (hard performance ceiling is always imposed if you don't pay with static typing and full JIT/AOT) and unfortunately suffer from high heap footprint, even compared to the more throughput-focused GC modes in .NET and GC implementations in JVM. But no, developers are insistent on parroting quotes said 10 to 15 years ago instead of at least attempting to assess technologies on their merits of today.
> "colorless" (which is always a lie)
No, colourless isn't a lie. Erlang doesn't have two types of function (sync and async). C#/Python now do. As a function/method implementer in those languages, for every single function implementation, I am faced with the following:
1. My function has to be async, because someone, somewhere, in the call chain of functions I want to invoke, decided to make their function async. So I have to deal with the downsides (lower performance, debugging complexity) whether I need the upsides or not.
2. I need to decide whether to make my function async because the decision hasn't been taken out my hands somewhere down the call stack. If I'm writing a library function that means I'm now having to judge how callers will use my function. If I decide async, then I've imposed constraints on the caller as per #1.
3. I need to implement sync & async versions of my function so as not to constrain the choices of my callers.
That emerges because of (1) the asymmetric constraint imposed by async/await and (2) the requirement for function implementers to make the decision, not callers. A sync function can't call an async one. That's the basis of colouring. It's not a lie.
> the article about function coloring is actively harmful to the industry
No, the article about colouring very clearly explains the asymmetric nature of sync/async and the limitation it imposes. Its use of colour as a metaphor very clearly illustrates the issue. Sure, there's a risk that some people won't fully read and understand it - and then just parrot "yeah, coloured is bad". That's not the fault of the article though.
There's nothing inherently wrong with Futures as a concurrency construct: it's essentially enabling cooperative multitasking. The issue is that async/await as an implementation causes codebase bifurcation.
> all BEAM-based languages are comparatively slow
Emphasis on "comparative". I don't disagree that in certain dimensions - notably raw compute performance and memory usage - BEAM languages are comfortably down the benchmark tables compared to C#. That doesn't always translate to real world practicality though (and even throughput is getting better given the active JIT work).
> developers are insistent on parroting quotes said 10 to 15 years ago instead of at least attempting to assess technologies on their merits of today.
Futures have merit per above. Async/await brings syntactic convenience which, in isolation, is an improvement. But with it comes significant cost. Cost that isn't there with green threads and isn't intrinsic to Futures either. You can't just sweep those limitations under the carpet by promulgating the hubris that the arguments are old.
No, colourless isn't a lie. Erlang doesn't have two types of function (sync and async). C#/Python now do. As a function/method implementer in those languages, for every single function implementation, I am faced with the following:
1. My function has to be async, because someone, somewhere, in the call chain of functions I want to invoke, decided to make their function async. So I have to deal with the downsides (lower performance, debugging complexity) whether I need the upsides or not.
2. I need to decide whether to make my function async because the decision hasn't been taken out my hands somewhere down the call stack. If I'm writing a library function that means I'm now having to judge how callers will use my function. If I decide async, then I've imposed constraints on the caller as per #1.
3. I need to implement sync & async versions of my function so as not to constrain the choices of my callers.
That emerges because of (1) the asymmetric constraint imposed by async/await and (2) the requirement for function implementers to make the decision, not callers. A sync function can't call an async one. That's the basis of colouring. It's not a lie.
> the article about function coloring is actively harmful to the industry
No, the article about colouring very clearly explains the asymmetric nature of sync/async and the limitation it imposes. Its use of colour as a metaphor very clearly illustrates the issue. Sure, there's a risk that some people won't fully read and understand it - and then just parrot "yeah, coloured is bad". That's not the fault of the article though.
There's nothing inherently wrong with Futures as a concurrency construct: it's essentially enabling cooperative multitasking. The issue is that async/await as an implementation causes codebase bifurcation.
> all BEAM-based languages are comparatively slow
Emphasis on "comparative". I don't disagree that in certain dimensions - notably raw compute performance and memory usage - BEAM languages are comfortably down the benchmark tables compared to C#. That doesn't always translate to real world practicality though (and even throughput is getting better given the active JIT work).
> developers are insistent on parroting quotes said 10 to 15 years ago instead of at least attempting to assess technologies on their merits of today.
Futures have merit per above. Async/await brings syntactic convenience which, in isolation, is an improvement. But with it comes significant cost. Cost that isn't there with green threads and isn't intrinsic to Futures either. You can't just sweep those limitations under the carpet by promulgating the hubris that the arguments are old.
Do you have experience with C#? If yes, how much?
I mean, libuv is entirely incomparable to how async is done in C++ too.
You'd do it like this: https://github.com/boostorg/cobalt or like this: https://github.com/danvratil/qcoro
You'd do it like this: https://github.com/boostorg/cobalt or like this: https://github.com/danvratil/qcoro
Interesting thank you!
Setting aside the issue of delays (I agree with that; this is why I started blogging about async Rust again even though I am no longer part of the project), Rust cannot solve the problem except with async because of its prior commitment to "the C runtime." I've written about this in other posts, but this comment from PhantomZorba on lobste.rs describes the situation succinctly:
> Async style language features are a compromise between your execution model being natively compatible with the 1:1 C ABI, C standard library, and C runtime and a M:N execution model. C++ async suffers from the same issues, except it’s not as strict in terms of lifetime safety (not a good thing). The cost for the native compatibility with the C/system runtime is the “function coloring” problem.
> Go, Haskell, and I assume Erlang make the other compromise. They eschew the C ABI and runtime completely and implement their own standard library. All code ends up being color-clean. The cost is that integrating with code outside their ecosystem is complex and slow.
https://lobste.rs/s/jkct2m/avoid_async_rust#c_0dqqlv
> Async style language features are a compromise between your execution model being natively compatible with the 1:1 C ABI, C standard library, and C runtime and a M:N execution model. C++ async suffers from the same issues, except it’s not as strict in terms of lifetime safety (not a good thing). The cost for the native compatibility with the C/system runtime is the “function coloring” problem.
> Go, Haskell, and I assume Erlang make the other compromise. They eschew the C ABI and runtime completely and implement their own standard library. All code ends up being color-clean. The cost is that integrating with code outside their ecosystem is complex and slow.
https://lobste.rs/s/jkct2m/avoid_async_rust#c_0dqqlv
100%! I'm so glad someone sees it for how it is.
At least some of the language features motivated by async are also useful in other places, e.g. RFCs 3425 and 2033
And the "bit more wasteful" part is a non-starter because people want to use async in embedded contexts.
And the "bit more wasteful" part is a non-starter because people want to use async in embedded contexts.
https://www.oreilly.com/library/view/parallel-and-concurrent... explains how Haskell does async exceptions and cancellation, for comparison. I found that the most challenging chapter of The Concurrency Book, but even so it feels like a solved problem in Haskell (especially once you've read the next chapter, on stm)
I feel the same. At least, author has been transparent about the infra-project-gone-off-the-rails vibe, see https://without.boats/blog/a-four-year-plan/ :
> For those who don’t know, there was a big debate whether the await operator in Rust should be a prefix operator (as it is in other languages) or a postfix operator (as it ultimately was). This attracted an inordinate amount of attention - over 1000 comments. The way it played out was that almost everyone on the language team had reached a consensus that the operator should be postfix, but I was the lone hold out. At this point, it was clear that no new argument was going to appear, and no one was going to change their mind. I allowed this state of affairs to linger for several months. I regret this decision of mine. It was clear that there was no way to ship except for me to yield to the majority, and yet I didn’t for some time. In doing so, I allowed the situation to spiral with more and more “community feedback” reiterating the same points that had already been made, burning everyone out but especially me.
> For those who don’t know, there was a big debate whether the await operator in Rust should be a prefix operator (as it is in other languages) or a postfix operator (as it ultimately was). This attracted an inordinate amount of attention - over 1000 comments. The way it played out was that almost everyone on the language team had reached a consensus that the operator should be postfix, but I was the lone hold out. At this point, it was clear that no new argument was going to appear, and no one was going to change their mind. I allowed this state of affairs to linger for several months. I regret this decision of mine. It was clear that there was no way to ship except for me to yield to the majority, and yet I didn’t for some time. In doing so, I allowed the situation to spiral with more and more “community feedback” reiterating the same points that had already been made, burning everyone out but especially me.
> a bit more wasteful
The whole point of Rust is to not be a bit more wasteful
The whole point of Rust is to not be a bit more wasteful
I know that Zig is quite different from Rust and it is less mature, but I do wonder how its async compares.
Check out the Q&A in this video to hear it from the man himself, it's the first question: https://www.youtube.com/watch?v=5eL_LcxwwHg
The tl;dr is: "The previous async approach ended up not working, and had to be removed. It's currently an incredibly hard problem with no clear rodemap. The plan is to get there eventually."
The tl;dr is: "The previous async approach ended up not working, and had to be removed. It's currently an incredibly hard problem with no clear rodemap. The plan is to get there eventually."
Any more details about why the previous async approach ended up not working? and/or what that approach even was?
I have never used it directly, take what I say with a grain of salt.
As far as I know at least part of the idea was to eliminate the function coloring problem by letting the compiler do some nifty compile-time deductions. This had some issues (I don't know if this is still planned, it seems like the kind of thing that should not work in practice). Additionally, there were all sorts of hard technical issues with LLVM, debugging, etc.
I recommend checking the issue tracker, eg. https://github.com/ziglang/zig/issues/6025
I personally don't understand the domain well enough at all, but honestly, I feel like (if possible) Zig should try to double down on its allocator approach.
Instead of trying to use some compile-time deduction magic explicitly pass around an "async runtime/executor" struct which you explicitly have to interact with. Why not?
As far as I know at least part of the idea was to eliminate the function coloring problem by letting the compiler do some nifty compile-time deductions. This had some issues (I don't know if this is still planned, it seems like the kind of thing that should not work in practice). Additionally, there were all sorts of hard technical issues with LLVM, debugging, etc.
I recommend checking the issue tracker, eg. https://github.com/ziglang/zig/issues/6025
I personally don't understand the domain well enough at all, but honestly, I feel like (if possible) Zig should try to double down on its allocator approach.
Instead of trying to use some compile-time deduction magic explicitly pass around an "async runtime/executor" struct which you explicitly have to interact with. Why not?
Interesting analysis. I tend to agree on the complexity budget.
That being said, even if we ignore wastefulness, have you tried async programming in OCaml or in Haskell? You immediately enter a CPS/monadic nightmare that makes programming way more complicated, debugging extremely hard and doesn't deal too well with errors.
These are the hard async problems that Rust is attempting to solve. Performance isn't the main blocker here.
That being said, even if we ignore wastefulness, have you tried async programming in OCaml or in Haskell? You immediately enter a CPS/monadic nightmare that makes programming way more complicated, debugging extremely hard and doesn't deal too well with errors.
These are the hard async problems that Rust is attempting to solve. Performance isn't the main blocker here.
Does it? I haven't used much ocaml and I haven't used Haskell in a while, but as I remember it all IO is already non blocking in Haskell, and the async library gives you the most painless async experience I've ever seen in any ecosystem. And for OCaml, you have explicit binds but recover neat do notation with let*?
You may be right. I haven't used OCaml or Haskell in a while, either. Last time I did concurrency in OCaml, there was no such thing as `let*` (you had to use Camlp4 to achieve anything like this), so it's entirely possible that the user experience has improved. As for Haskell, I mostly remember the complexity of getting anything like a reasonable error handling through the IO monad.
I’ve been following a similar issue in Swift (which is informed by some learnings from the Rust side of things). Here is a link to the latest language complexity resulting from this: https://forums.swift.org/t/sub-pitch-task-local-values-in-is...
There are a number of other proposals linked to this issue that can be referenced from that thread. I hope there is a next generation async model for future languages that is truly simple, because this all makes me think footguns are endemic to the current approach (which is broadly the same in Rust and Swift).
There are a number of other proposals linked to this issue that can be referenced from that thread. I hope there is a next generation async model for future languages that is truly simple, because this all makes me think footguns are endemic to the current approach (which is broadly the same in Rust and Swift).
Seems java's virtual thread is the only sane async model out there.
I believe Golang uses a similar model but much more simple to use. Uncolored async is the way to go
I'm of two minds on this point. Uncolored async is simpler language design and works well for _most_ cases but provides way fewer guarantees than colored async, with the potential to break badly in some cases.
For instance, there are many system-level data structures that are not allowed to migrate from one thread to another (e.g. Linux mutexes or Rust's Rc) or sometimes from one core to another. If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all.
Which means that you can't be a system programming language (for some definition of system programming).
By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may .
For instance, there are many system-level data structures that are not allowed to migrate from one thread to another (e.g. Linux mutexes or Rust's Rc) or sometimes from one core to another. If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all.
Which means that you can't be a system programming language (for some definition of system programming).
By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may .
> e.g. Linux mutexes
You don't want to use blocking mutexes anyway with async.
> or Rust's Rc
This is only half true. The danger is that two `Rc` that point to the same data are in different threads. But it should be safe to move all of them at once from one thread to another, which is exactly the case if all the `Rc`s involved live inside a `Future`. The problem is that this is a non-local property that's hard to encode in the type system.
> By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may .
FYI that's known to be unsound due to thread locals. And more generally it doesn't seem to give much attention to safety (see for example how it allowed unsound scoped tasks, or the fact it allows doing unsafe operations in some of its macros due to wrong scoping of `unsafe` blocks).
You don't want to use blocking mutexes anyway with async.
> or Rust's Rc
This is only half true. The danger is that two `Rc` that point to the same data are in different threads. But it should be safe to move all of them at once from one thread to another, which is exactly the case if all the `Rc`s involved live inside a `Future`. The problem is that this is a non-local property that's hard to encode in the type system.
> By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may .
FYI that's known to be unsound due to thread locals. And more generally it doesn't seem to give much attention to safety (see for example how it allowed unsound scoped tasks, or the fact it allows doing unsafe operations in some of its macros due to wrong scoping of `unsafe` blocks).
> If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all.
A simple call to https://pkg.go.dev/runtime#LockOSThread solves that.
Pay the cost of backwards compat when you need it, don't pay it when you don't need it.
A simple call to https://pkg.go.dev/runtime#LockOSThread solves that.
Pay the cost of backwards compat when you need it, don't pay it when you don't need it.
Go's approach to async programming is indeed simpler, but its FFI and handling of stateful coroutines can introduce complexity and overhead when bridging with external code. Using CGO is slow because it requires synchronization of the coroutine state between libc and Go. Everyone avoids CGO whenever possible, so it is not a solution.
Rust chose a different path that is not more complex, but the complexity lies elsewhere.
Rust chose a different path that is not more complex, but the complexity lies elsewhere.
Just an extra bit of clarity: the relative slowness of CGo calls is a conscious trade-off that enables Go threads to be much lighter weight. It's not an inherent aspect of the design, but a trade-off you pay for wanting more lightweight green threads. Choosing to not follow the age old C ABI internally means you have to bridge that gap if and when you come to it.
That I can easily believe. Someone should make a benchmark of how many requests you can serve from a java backend compared to a rust backend that's heavy on IO and network.
Sure, we did that in 2016 when we first created the Future abstraction: http://aturon.github.io/blog/2016/08/11/futures/
Java virtual threads shipped between 2021 (preview) and 2023 (final).
Yeah an 8 year old benchmark doesn't mean much, both languages/platforms surely have evolved greatly and I would not surprised that on many meaningful workloads there is some parity.
It wouldn't stop the hype, it never does.
I never understood the fascination for working with cutting edge languages; to me it just increases the likelihood that you're going to find language errors or library errors and get tied up for ages helping to refine the environment. Plus the relatively small size of the developer community and supporting literature available.
Maybe it's a dog people thing, the sort of people that get into it are the sort of people that want to go home and have a dog with infinite energy bouncing up and down all the time.
Just exhausting to even think about.
I never understood the fascination for working with cutting edge languages; to me it just increases the likelihood that you're going to find language errors or library errors and get tied up for ages helping to refine the environment. Plus the relatively small size of the developer community and supporting literature available.
Maybe it's a dog people thing, the sort of people that get into it are the sort of people that want to go home and have a dog with infinite energy bouncing up and down all the time.
Just exhausting to even think about.
> cutting edge languages;
Whatever about anything else, Rust has definitely moved past "cutting edge"
Whatever about anything else, Rust has definitely moved past "cutting edge"
I have been actually professionally working with Rust for the last 2 years, and most recently on certified safety systems.
But I'm always thinking that the JVM is a pretty solid platform that has not yet reached its full potential. It gets a bad rap because of the hellhole that enterprise software is. But come on, look at android, look at games like Minecraft. Solid projects, written in large part in Java.
But I'm always thinking that the JVM is a pretty solid platform that has not yet reached its full potential. It gets a bad rap because of the hellhole that enterprise software is. But come on, look at android, look at games like Minecraft. Solid projects, written in large part in Java.
Describing Minecraft as "solid" makes me very scared reading "certified safety systems". Minecraft is the most standard possible example of Java's badness and bloat. It's explicitly what software should strive not to be.
It's a game first and foremost, and it mostly works, quite well, with multiple players. It's a completely different set of requirements from safety software.
And people write mods for it and have had success. If that is not solid what is. For real what's so bad about minecraft, it even runs on a relatively old laptop of mine with 8 gigs of RAM without any lag.
In most safety software you can't even use dynamic memory. Maybe a lot of the software we write in that domain would be considered "bloat" in others, but I don't know what are the constraints that Minecraft faces that drove it to be implemented the way it is. But despite the bloat, they managed to do a lot.
And people write mods for it and have had success. If that is not solid what is. For real what's so bad about minecraft, it even runs on a relatively old laptop of mine with 8 gigs of RAM without any lag.
In most safety software you can't even use dynamic memory. Maybe a lot of the software we write in that domain would be considered "bloat" in others, but I don't know what are the constraints that Minecraft faces that drove it to be implemented the way it is. But despite the bloat, they managed to do a lot.
> For real what's so bad about minecraft, it even runs on a relatively old laptop of mine with 8 gigs of RAM without any lag.
When Minecraft came out, 8G of RAM would be pretty much the highest-end system you can buy. It's really not the flex you think it is.
In terms of the opposite direction from Minecraft in stability is Factorio, which can easily run on a multiplayer server for a gaming group on a potato of a computer and whose high-end multiplayer record is well over 500.
When Minecraft came out, 8G of RAM would be pretty much the highest-end system you can buy. It's really not the flex you think it is.
In terms of the opposite direction from Minecraft in stability is Factorio, which can easily run on a multiplayer server for a gaming group on a potato of a computer and whose high-end multiplayer record is well over 500.
[deleted]
> I would be interested in examples of code that users believe require cancellation-specific async code, though.
This happens all the time. For example, cancellation in the middle of sending a HTTP request. The connection is now unusable and must be closed. Without cancellation the connection returns to a state where it can be used and is re-added to a pool.
This happens all the time. For example, cancellation in the middle of sending a HTTP request. The connection is now unusable and must be closed. Without cancellation the connection returns to a state where it can be used and is re-added to a pool.
> On a UNIX system, the file is closed in the call to drop by calling close(2). What happens if that call returns an error? The standard library ignores it. This is partly because there’s not much you can do to respond to close(2) erroring, as a comment in the standard library elucidates
Note that this is true for UNIX file descriptors, but not for C++ streams: an error when closing may indicate that the stream you closed had some buffered data it failed to flush (for any of the reasons that a failed write might come from).
In that case, you sometimes do want to take a different codepath to avoid data loss; eg, if your database does "copy file X to new file Y, then remove X", if closing/flushing Y fails then you absolutely want to abort removing X.
In the case of Rust code, the method you want is `File::sync_all`, which returns a Result for this exact purpose.
Note that this is true for UNIX file descriptors, but not for C++ streams: an error when closing may indicate that the stream you closed had some buffered data it failed to flush (for any of the reasons that a failed write might come from).
In that case, you sometimes do want to take a different codepath to avoid data loss; eg, if your database does "copy file X to new file Y, then remove X", if closing/flushing Y fails then you absolutely want to abort removing X.
In the case of Rust code, the method you want is `File::sync_all`, which returns a Result for this exact purpose.
In the meantime I actually wrote a create that hacks around this problem:
https://crates.io/crates/async-dropper
https://crates.io/crates/async-dropper
> I don’t have an example of fully non-cooperative cancellation available off the top of my head.
That would be Erlang.
That would be Erlang.
Asynchronous clean-up is a solved problem in C++ senders & receivers.
I wonder what's so different about rust that they can't solve it in the same way.
I wonder what's so different about rust that they can't solve it in the same way.
> I can write all these posts and tell you with a straight face there’s no tradeoff because appeasing the borrow checker is NBD. I never think about appeasing the borrow checker when I write Rust.
Guy is in a bubble. He doesn't realize that 99% of rust programmers don't have the experience he does.
Guy is in a bubble. He doesn't realize that 99% of rust programmers don't have the experience he does.
With my experience of moderating the Rust Community Discord Server, it really doesn't take long to get over the borrow checker. Most people are not writing code complicated enough to get stuck with the really complicated cases (unfortunately, yes, the borrow checker is not perfect) but it really is good enough for most people most of the time.
Clicking with the borrow checker is a big hurdle for many, but once it clicks and you adjust your design patterns to be compatible with the language it really is a secondary concern.
I very rarely run into borrow check errors, and if I do they are usually easily solved. From my impression that's the same for most semi-experienced Rust devs.
I very rarely run into borrow check errors, and if I do they are usually easily solved. From my impression that's the same for most semi-experienced Rust devs.
The borrow checker is really not that big of a deal. It is a hurdle, but the primary issue is just that it's novel and requires you to use different design patterns.
If people get stuck here, it is because they don't understand that the dreaded borrow checker error is (generally) about large, systematic code design patterns, not about local changes.
They try to appease the borrow checker by making small, local changes, which doesn't end up working, since borrow checker issues are about a fundamental issue in the ownership-design of your codebase. Once someone explains this to you, it's really not that hard.
If people get stuck here, it is because they don't understand that the dreaded borrow checker error is (generally) about large, systematic code design patterns, not about local changes.
They try to appease the borrow checker by making small, local changes, which doesn't end up working, since borrow checker issues are about a fundamental issue in the ownership-design of your codebase. Once someone explains this to you, it's really not that hard.
This is not to suggest that async models are a bad idea. They just have a higher level of intrinsic complexity and language support is immature. The benefit is qualitatively better scalability and performance, so there is a purpose behind using async models.