Why asynchronous Rust doesn't work

Correct me if I'm wrong, but isnt any sort of async support non integral to rust? For example in something like Javscript you can't impliment your own async. But in C, C++ or Rust you can do pretty much anything you want.

So if in the future io-uring and friends become the standard can't that just be a library you could then use?

Similar to how in C you don't need the standard library to do threads or async.

Could Rust switch? More importantly, would a completion based model alleviate the problems mentioned?

Since you clearly have expertise, I'm curious if you might provide some insight into what would roughly be different in an async completion-based model & why that might be at a fundamental odds with the event-based one? Like is it an incompatibility with the runtime or does it change the actual semantics of async/await in a fundamental way to the point where you can't just swap out the runtime & reuse existing async code?

FWIW I've done a fair bit of researching with io_uring. For file operations it's fast, bit over epoll the speedups are negligible. The creator is a good guy but they're having issues with the performance numbers being skewed due to various deficiencies in the benchmark code, such as skipping error checks in the past.

Also, io_uring can certainly be used via polling. Once the shared rings are set up, no syscalls are necessary afterward.

> Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively made on the ground of "we want to ship async support as soon as possible" [1].

That is not an accurate summary of that comment. withoutboats may have been complaining about someone trying to revisit the decision made in 2015-2016, but as the comment itself points out, there were good reasons for that decision.

Mainly two reasons, as far as I know.

First, Rust prefers unique ownership and acyclic data structures. You can make cyclic structures work if you use RefCell and Rc and Weak, but you're giving up the static guarantees that the borrow checker gives you in favor of a bunch of dynamic checks for 'is this in use' and 'is this still alive', which are easy to get wrong. But a completion-based model essentially requires a cyclic data structure: a parent future creates a child future (and can then cancel it), which then calls back to the parent future when it's complete. You might be able to minimize cyclicity by having the child own the parent and treating cancellation as a special case, but then you lose uniqueness if one parent has multiple children.

(Actually, even the polling model has a bit of cyclicity with Wakers, but it's kept to an absolute minimum.)

Second, a completion-based model makes it hard to avoid giving each future its own dynamic allocation, whereas Rust likes to minimize dynamic allocations. (It also requires indirect calls, which is a micro-inefficiency, although I'm not convinced that matters very much; current Rust futures have some significant micro-inefficiencies of their own.) The 2016 blog post linked in the comment goes into more detail about this.

As you might guess, I find those reasons compelling, and I think a polling-based model would still be the right choice even if Rust's async model was being redesigned from scratch today. Edit: Though to be fair, the YouTube video linked from withoutboats' comment does mention that mio decided on polling simply because that's what worked best on Linux at the time (pre-io_uring), and that had some influence on how Futures ended up. But only some.

…That said, I do agree Pin was rushed and has serious problems.

I agree that Rust async is currently in a somewhat awkward state.

Don't get me wrong, it's usable and many projects use it to great effect.

But there are a few important features like async trait methods (blocked by HKT), async closures, async drop, and (potentially) existential types, that seem to linger. The unresolved problems around Pin are the most worrying aspect.

The ecosystem is somewhat fractured, partially due to a lack of commonly agreed abstractions, partially due to language limitations.

There also sadly seems to be a lack of leadership and drive to push things forward.

I'm ambivalent about the rushing aspect. Yes, async was pushed out the door. Partially due to heavy pressure from Google/Fuchsia and a large part of the userbase eagerly .awaiting stabilization.

Without stabilizing when they did, we very well might still not have async on stable for years to come. At some point you have to ship, and the benefits for the ecosystem can not be denied. It remains to be seen if the design is boxed into a suboptimal corner; I'm cautiously optimistic.

But what I disagree with is that polling was a mistake. It is what distinguishes Rusts implementation, and provides significant benefits. A completion model would require a heavier, standardized runtime and associated inefficiencies like extra allocations and indirection, and prevent efficiencies that emerge with polling. Being able to just locally poll futures without handing them off to a runtime, or cheaply dropping them, are big benefits.

Completion is the right choice for languages with a heavy runtime. But I don't see how having the Rust dictate completion would make io_uring wrapping more efficient than implementing the same patterns in libraries.

UX and convenience is a different topic. Rust async will never be as easy to use as Go, or async in languages like Javascript/C#. To me the whole point of Rust is providing as high-level, safe abstractions as possible, without constraining the ability to achieve maximum efficiency . (how well that goal is achieved, or hindered by certain design patterns that are more or less dictated by the language design is debatable, though)

The poll model has the advantage that you have control when async work starts and therefor is the more predictable model.

I guess that way it fits more the Rust philosophy.

Why did polling have to be baked into the language? Seems bizarre for a supposedly portable language to assume the functionality of an OS feature which could change in the future.

Meanwhile C and C++ can easily adopt any async system call style because it made no assumptions in the standards about how that would be done.

Rust also didn't solve the colored functions problem. Most people think that's an impossible problem to solve without a VM/runtime (like Java Loom), but people also thought garbage collection was impossible in a systems language until Rust solved it. It could have been a great opportunity for them.

> A bigger problem in my opinion is that Rust has chosen to follow the poll-based model

This is an inaccurate simplification that, admittedly, their own literature has perpetuated. Rust uses informed polling: the resource can wake the scheduler at any time and tell it to poll. When this occurs it is virtually identical to completion-based async (sans some small implementation details).

What informed polling brings to the picture is opportunistic sync: a scheduler may choose to poll before suspending a task. This helps when e.g. there is data already in IO buffers (there often is).

There's also some fancy stuff you can do with informed polling, that you can't with completion (such as stateless informed polling).

Everything else I agree with, especially Pin, but informed polling is really elegant.

In all this time, maestro Andrei Alexandrescu was right when he said Rust feels like it "skipped leg day" when it comes to concurrency and metaprogramming capabilities. Tim Sweeney was complaining about similar things, saying about Rust that is one step forward, one step backward. These problems will be evident at a later time, when it will be already too late. I will continue experimenting with Rust, but Zig seems to have some great things going on, especially the colourless functions and the comptime thingy. Its safety story does not dissapoint also, even if it is not at Rust's level of guarantees.

This post is completely and totally wrong. At least you got to ruin my day, I hope that's a consolation prize for you.

There is NO meaningful connection between the completion vs polling futures model and the epoll vs io-uring IO models. comex's comments regarding this fact are mostly accurate. The polling model that Rust chose is the only approach that has been able to achieve single allocation state machines in Rust. It was 100% the right choice.

After designing async/await, I went on to investigate io-uring and how it would be integrated into Rust's system. I have a whole blog series about it on my website: https://without.boats/tags/io-uring/. I assure you, the problems it present are not related to Rust's polling model AT ALL. They arise from the limits of Rust's borrow system to describe dynamic loans across the syscall boundary (i.e. that it cannot describe this). A completion model would not have made it possible to pass a lifetime-bound reference into the kernel and guarantee no aliasing. But all of them have fine solutions building on work that already exists.

Pin is not a hack any more than Box is. It is the only way to fit the desired ownership expression into the language that already exists, squaring these requirements with other desireable primitives we had already committed to shared ownership pointers, mem::swap, etc. It is simply FUD - frankly, a lie - to say that it will block "noalias," following that link shows Niko and Ralf having a fruitful discussion about how to incorporate self-referential types into our aliasing model. We were aware of this wrinkle before we stabilized Pin, I had conversations with Ralf about it, its just that now that we want to support self-referential types in some cases, we need to do more work to incorporate it into our memory model. None of this is unusual.

And none of this was rushed. Ignoring the long prehistory, a period of 3 and a half years stands between the development of futures 0.1 and the async/await release. The feature went through a grueling public design process that burned out everyone involved, including me. It's not finished yet, but we have an MVP that, contrary to this blog post, does work just fine, in production, at a great many companies you care about. Moreover, getting a usable async/await MVP was absolutely essential to getting Rust the escape velocity to survive the ejection from Mozilla - every other funder of the Rust Foundation finds async/await core to their adoption of Rust, as does every company that is now employing teams to work on Rust.

Async/await was, both technically and strategically, as well executed as possible under the circumstances of Rust when I took on the project in December 2017. I have no regrets about how it turned out.

Everyone who reads Hacker News should understand that the content your consuming is usually from one of these kinds of people: a) dilettantes, who don't have a deep understanding of the technology; b) cranks, who have some axe to grind regarding the technology; c) evangelists, who are here to promote some other technology. The people who actually drive the technologies that shape our industry don't usually have the time and energy to post on these kinds of things, unless they get so angry about how their work is being discussed, as I am here.

I think there are 2 separate findings in it:

First of all yes, Rust futures use a poll model, where any state changes from different tasks don't directly call completions, but instead just schedule the original task to wake up again. I still think this is a good fit, and makes a lot of sense. It avoids a lot of errors on having a variety of state on the call stack before calling the continuation, which then gets invalidated. The model by itself also doesn't automatically make using completion based IO impossible.

However the polling model in Rust is combined with the model of always being able to drop a Future in order to cancel a task. This doesn't allow to use lower level libraries which require to do this without applying any additional workarounds.

However that part of Rusts model could be enhanced if there is enough interest in it. e.g. [1] discusses a proposal for it.

[1] https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-asy...

^this

IMO, Rust already provides a decent amount of way to simplify and skip things. Reference counting, async, proc_macro, etc.

In my experience, programming stuffs at a higher-level-language where things are heavily abstracted, like (cough) NodeJS, is easy and simple up to a certain point where I have to do a certain low-level things fast (e.g. file/byte patching) or do a system call which is not provided by the runtime API.

Often times I have to resort to making a native module or helper exe just to mitigate this. That feels like reinventing the wheel because the actual wheel I need is deep under an impenetrable layer of abstraction.

I'm a giant Rust fanboy and have been since about 2016. So, for context, this was literally before Futures existed in Rust.

But, I only work on Rust code sporadically, so I definitely feel the pros and cons of it when I switch back and forth to/from Rust and other languages.

The problem, IMO, isn't about allocations or ownership.

In fact, I think that a lot of the complaints about async Rust aren't even about async Rust or Futures.

The article brings up the legitimate awkwardness of passing functions/closures around in Rust. But it's perfectly fair to say that idiomatic Rust is not a functional language, and passing functions around is just not the first tool to grab from your toolbelt.

I think the actual complaint is not about "async", but actually about traits. Traits are paradoxically one of Rust's best features and also a super leaky and incomplete abstraction.

Let's say you know a bit of Rust and you're kind of working through some problem. You write a couple of async functions with the fancy `async fn foo(&x: Bar) -> Foo` syntax. Now you want to abstract the implementation by wrapping those functions in a trait. So you try just copy+pasting the signature into the trait. The compiler complains that async trait methods aren't allowed. So now you try to desugar the signature into `fn foo(&x: Bar) -> impl Future<Foo>` (did you forget Send or Unpin? How do you know if you need or want those bounds?). That doesn't work either because now you find out that `impl Trait` syntax isn't supported in traits. So now you might try an associated type, which is what you usually do for a trait with "generic" return values. That works okay, except that now your implementation has to wrap its return value in Box::pin, which is extra overhead that wasn't there when you just had the standalone functions with no abstraction. You could theoretically let the compiler bitch at you until it prints the true return value and copy+paste that into the trait implementation's associated type, but realistically, that's probably a mistake because you'd have to redo that every time you tweak the function for any reason.

IMO, most of the pain isn't really caused by async/await. It's actually caused by traits.

In a systems context, where performance and memory ostensibly matter, why wouldn’t you want to be made aware of those inefficiencies?

Sure, Go hides all that, but as a result it’s also possible to have memory leaks and spend extra time/memory on dynamic dispatch without being (fully) aware of it.

Definitely dynamic dispatch + async brings out a lot of pain points.

But I only agree that the async part of that is unfortunate. Making dynamic dispatch have a little extra friction is a feature, not a bug, so to speak. Rust's raison d'être is "zero cost abstraction" and to be a systems language that should be viable in the same spaces as C++. Heap allocating needs to be explicit, just like in C and C++.

But, I agree that async is really unergonomic once you go beyond the most trivial examples (some of which the article doesn't even cover).

Some of it is the choices made around the async/await design (The Futures, themselves, and the "async model" is fine, IMO).

But the async syntax falls REALLY flat when you want an async trait method (because of a combination-and-overlap of no-HKTs, no-GATs, no `impl Trait` syntax for trait methods) or an async destructor (which isn't a huge deal- I think you can just use future::executor::block_on() and/or use something like the defer-drop crate for expensive drops).

Then it's compounded by the fact that Rust has these "implicit" traits that are usually implemented automatically, like Send, Sync, Unpin. It's great until you write a bunch of code that compiles just fine in the module, but you go to plug it in to some other code and realize that you actually needed it to be Send and it's not. Crap- gotta go back and massage it until it's Send or Unpin or whatever.

Some of these things will improve (GATs are coming), but I think that Rust kind of did itself a disservice with stabilizing the async/await stuff, because now they'll never be able to break it and the Pin/Unpin FUD makes me nervous. I also think that Rust should have embraced HKTs/Monads even though it's a big can of worms and invites Rust devs to turn into Scala/Haskell weenies (said with love because I'm one of them).

Yeah, a struct holding four different closures is not a pattern that makes much sense in Rust.

That would look a lot better as a Trait with four methods.

> So... don’t use first-class functions so much? It’s a systems language, not a functional language for describing algorithms in CS whitepapers.

Then maybe it was a mistake to adopt an async paradigm from functional languages that relies heavily on the idea that first-class functions are cheap and easy?

(FWIW I think Rust was right to pick Scala-style async; it's really the only nice way of working with async that I've seen, in any language. I think the mistake was not realising the importance of first-class functions and prioritising them higher)

Wanted to write something similar, just not as elaborate as you did (native German speaker here).

Another good example is Java, and languages running on top of the JVM.

> It’s a systems language, not a functional language for describing algorithms in CS whitepapers.

This kind of toxicity is why I left programming behind as a career.

I think your implication that a system programming language can't have nice stuff is based on system languages of old. Unless a language is absolutely must have manual memory allocations, it can have 1st class functions and closures.

> caught a multi-threading bug

The compiler complained: “error[E0308]: mismatched types”

There wasn't any multi-threading in that example I think.

You are to find fancy runtime-only errors in async functions. Their existence outweighs any other compiler’s benefits.

He's just pointing out that it isn't very ergonomic, not that Rust is bad (in fact he states the opposite multiple times).

Pointing out weaknesses and things that might be done better is what helps something mature, not just praising it.

What is the bug? I don't see it.

> anything where you want to pass functions around.

You should read the article! The author goes into this in fascinating detail.

Nit, you can already abstract over lifetimes. But I really agree with the HKT comment, in principle. In practice it's not so bad. Abstracting over async, mutability, and borrows would be more important to smooth over a few of these issues (there are ways around both, but it's not always obvious).

Most of these issues arise for library authors. I think a lot of folks in the ecosystem today are writing libraries instead of applications, which is why we get these blog posts lamenting the lack of HKTs or difficult syntax for doing difficult things that other languages hide from you. I don't think users have the same experience when building things with the libraries.

That said, there's a bit of leakage of complexity. Sometimes it's really hard to write a convenient API (like abstracting over closures) and that leads to gnarly errors for users of those APIs. Closures are particularly bad about this (which some, including myself, would say is good and also easy to work around), and there's always room for improvement. I don't think a lack of HKTs is really holding anything essential back right now.

> mean it doesn't really have first-class functions: there are three different function types

Rust absolutely does have first-class functions, though. Their type is `fn(T)->U`. The "three different function types" that you refer to are traits for closures. And note that closures with no state (lambdas) coerce into function types.

    higher_order(is_zero);
    higher_order(|n| n == 0);
    
    fn higher_order(f: fn(i32)->bool) {
        f(42);
    }

    fn is_zero(n: i32) -> bool {
        n == 0
    }

It's true that when you have a closure with state then Rust forces you to reason about the ownership of that state, but that's par for the course in Rust.

Rust programs can theoretically be fast, but most of the ones I've used are slow. I tried two high profile implementations of the same type of software, one in Rust and one in Java. The Java one was faster and used less memory.

Rust programmers tend to do all kinds of little hacks here and there to make the borrow checker happy. It can add up. The borrow checker is perfectly happy when you copy everything.

Rust is becoming one giant antipattern.

(I'm sure highly experienced Rust programmers can get it to work, but there are probably less than 1000 people on this planet that can write good Rust that outperforms C++ so does it really count.)

> Async isn't really the problem - the same issue pops up with error handling, with resource management

There are ways to handle that, though. It's called algebraic effects and they are nicely implemented in Unison language[1] (although there they're called abilities[2]). It's very interesting language; I recommend reading [3] for good overview.

[1] https://www.unisonweb.org/

[2] https://www.unisonweb.org/docs/abilities

[3] https://jaredforsyth.com/posts/whats-cool-about-unison/

+1000 in this. You can just use rust like c/c++ if you don’t want to buy into async.

Maybe it’s just the hyper and related crates universe, but my perception (see my sibling comment) is that more and more of the ecosystem will be “async only”.

Like you, I think that’s sort of fine, because you can always roll your own. But it’s also kind of sad: one of the best things about the Rust ecosystem is that you can so effortlessly use a small crate in a way you really can’t in C++ (historically, maybe modules will finally improve this).

Mmmyeah, they said this about python too...

I don't know how anybody can say this with a straight face.

Even in a systems context I think it's pretty reasonable to want to either perform or receive a HTTP request, as soon as you do that in Rust you are funneled into Hyper or something built on top of it (like reqwest) and instantly are dependent on tokio/mio.

The very first example in the reqwest readme^1 has tokio attributes, async functions AND trait objects. It's impossible that a beginner attempting to use the language to do anything related to networking won't be guided into the async nightmare before they have even come to grips with the borrow checker.

1. https://crates.io/crates/reqwest

+2

Yes! Using `sans-async` must NOT diminish our productivity in comparison with `async` counterpart.

> at some point, coding event loops became very natural/comfortable for me

In fact it is, I'm very happy with it too.

> one nice thing about rust's async/await is, you don't have to use it, and if you don't, you don't pay for it in any way.

You've said it!

Why is it a problem that custom executors are difficult to implement? Most other languages that I'm aware of they wouldn't even be possible to implement.

I really don't see a problem with function color in a typed language. Every function has color and compiler enforces you pass right color. Async is just another type that may have some convenient syntax. It might be inconvenient in untyped languages like js since you couldn't compose them.

I agree on generator<->async conversion.

I'm not an expert but I can't shake the thought that Rust had it backward with async and generator. Generator looks like a good bridge between sync and async. Before reading about implementing async executor and digging under what tokio and async-std is doing (it's been months and I haven't finished), I thought implementing async executor is just as easy as running looping a generator.resume() until it yields GeneratorState::Complete until I realize generator is still on nightly!

It may be because I'm a noob in Rust, but I can't write easily:

``` let some_handle_arc = Arc::new(some_handle); future::block_on([ // this future will stop running midway if some_handle is modified in some way make_future(some_handle_arc),

  // make_future_stopper will modify some_handle_arc when receiving
  // a certain input from a certain interface
  make_future_stopper(some_handle_arc)

]); ```

My initial intuition is if async is generator-based, there should be an escape hatch where the generator-runner just exit, drop the generator, without waiting for the generator to yield Generator::Complete. But again it might be from my noobness being a simple Rust hobbyist.

Sorry for the rant

> The function color problem is a bit overblown, it hasn't broken nodejs yet either.

I agree; and I would also point at C#, which is the originator of the async/await syntax, and has had it for over 8 years now, with the ecosystem embracing it for most of that period. It works.

> The function color problem is a bit overblown, it hasn't broken nodejs yet either.

It didn't break Node because Node avoids function color problem altogether. Nobody writes blocking code in Node due to its single-threaded nature.

Function color problem is the difficulty of mixing blocking and async functions. It's especially annoying in Python, where you have to spawn a thread to call blocking functions from async functions, and welcome to mutithreading bugs.

In Node the problem doesn't exist, because you don't block in its blocking functions. You either do `await f()` or `f().then()`.

The issue is much more general. I also don't see a particular problem with Rust here, but I do see with Rust the same false hope I saw in the late eighties and early nineties with C++ (hell, I fell victim to it myself back then): the belief that with enough features, cleverness, and language complexity we could have the cake and eat it too -- have all the control of a low-level language with the same productivity as a high-level language. Low-level languages, whether they try to appear as high-level ones on the page or not, all suffer from low-abstraction, i.e. the inability to hide internal implementation details behind an API and isolate them from consumers. This makes changing implementation details hard and the program much more rigid, and so increases maintenance cost. The problems with C++ weren't apparent at first, because writing the program the first time is as easy as with a high-level language; the problems start when you change the program over the years. There is no doubt Rust cleans up C++ and solves some particular problems with it, but it doesn't solve this fundamental problem.

There are many situations where a low-level language and the control it affords are absolutely necessary, but low-level programmers are aware of the non-negligible price they pay.

I am guessing you are a point D/D' in the diagram [1] Although the diagram is for the Rust overall, I think something similar is true for async Rust.

All I would say is hang in there. It gets better (from my experience).

Rust is not something you can code along as you think. There is a bit a of upfront thinking what the data-structures & data-flow look like.

At present, I can know in advance without writing code whether implementation I am thinking in Rust will work or not (work => satisfy Rust compiler)

[1] https://imgur.com/kNkV7jm

You had chosen the really hard way to learn Rust. The most of problems for a beginner comes from lifetimes and borrowing. Async code by itself is harder topic when it comes to lifetimes and borrowing. When you use object in a concurrent manner, then you need to have two or more references to it, who would own object? When object has his owner, object lives. When object lost his owner, object dropped. Someone must own it. And borrow-checker need to have a way to prove, that owner will live longer than every one of your threads using this object, otherwise borrow-checker would start to complain and refuse to compile your code. If you are trying to get mutable access to object how you are going to ensure that it would be done in a safe manner without data races? How are you going to explain borrow-checker that it is a safe way?

I'm trying to say, that mostly you problems was lifetimes and borrowing, like with other beginners, but problems were magnified to a level when beginner have no chances to make it work.

The problem you were trying to solve (safe system level multi-threaded programming) is really really hard, and actually Rust makes it easier.

If you enjoy it, learn it and have fun doing high performance work at your new job.

If you’re not passionate about it, it’s OK, there are lots of work in other domains.

I sympathize. As I said in another comment, the issue isn't really caused by async, IMO. It's caused by the complicated and leaky abstraction of traits. I'd be willing to bet that your difficulties were more around dealing with the interactions of async + traits than if you had just written a bunch of async functions and then ran them inside an async main (via tokio's tokio::main attribute).

Just a guess.

> The problems the author is describing might apply more to library authors

I don't know much about Rust, but I found the examples in the article kind of simple. As far as I can see, the author is trying to spawn a new thread and share an object between the main thread and the new one. It's seems like an everyday paradigm.

Perhaps the problems arise when passing complex objects instead of native types (i.e. u32).

Agreed, I rewrote a 10k line a js websocket based game server[0] a few months ago into async Rust. It was mostly painless

I didn't have to deal with closures much because I'm comfortable writing a 2000 line match

0: https://github.com/serprex/openEtG/tree/master/src/rs/server

It is in no danger of become as complex than C++. Nowhere near.

> But unlike C++ it’s more difficult to pick and choose what you use.

Can you expand on this point?

As a C developer who has never really used C++ or Rust I sort of agree. Looking at Rust introductory guides I increasingly get the same feeling as looking at C++ things, where there's just _too much_ of everything. I know it's a subjective feeling that is probably unfair to the language, but it's still the impression I get.

I'm confident if I actually put in the work to learn Rust I would end up liking it and I plan on doing that at some point, but it certainly doesn't help my motivation.

> Just because async is in the language, don't feel like you need to use it everywhere.

Except that you will have to because no alternative library exist

I'd like to understand what you mean by this. I'm no expert on Rust lock-free designs, but what are the "amortization guarantees" that you refer to? Is there something that I can read that explains this in greater detail?

GC languages aren't significantly better, because the GC usually only directly manages the memory[1], and there are many, many other resources that need to be managed correctly.

1: Many GC languages let you run arbitrary code when the associated memory is freed, but if you have to wait for a full GC pass to happen before e.g. a lock is released or a file descriptor is flushed, that will cause many issues as well.

The color problem matters for static languages as much as for dynamic languages.

The essence of the problem is whether you can turn internal iterators into external ones without rewriting them. If you can't then your language has function colors.

The only thing a type-system brings to the table in this matter is an error at compile time if you used the wrong color.

It won't solve the color problem.

Also Rust async runtimes have `block_on(async)` and `spawn_blocking(sync).await`, so the main problem of call graphs split by "color" doesn't exist in Rust. Rust can merge the two worlds.

Unlike JS, Rust can wait for async code in blocking contexts, and it can run CPU-bound code in async contexts.

He says the problem is the proliferation of async libraries, which forces their use and pollute everything they touch in association with the closure problem. It's the combination of both.

Isn’t the Go solution green threads on top of hardware threads?

Lots of green threads get load balanced on top of a thread pool. Isn’t that the whole unique aspect of Go? So in essence they do both.

Well I'd say you have to take a lot of care to make them compose well.

Just like it takes care to compose thread- and process-based concurrency, it takes care to compose threads and async correctly and comprehensibly.

If you care about utilization you MUST use threads (or processes, which are a different story). So if you use async, then you have the problem of composing them, which is indeed hard. There are some C++ codebases that do this well but they're notable for being exceptions ...

There does appear to be overuse of async as a premature optimization. The default should to use threads and explicitly shared state -- basically the idioms in Go, although I'm sure ownership complicates that a lot.

The problem with green threads is that, unless they're a part of the platform ABI, they don't really get along with anything else - including green threads in other languages/frameworks! This makes cross-language/runtime interop unnecessarily difficult, and as I understand, it's partly why Go apps tend to be "pure Go", and even their stdlib insists on using syscalls on platforms where you're supposed to go via libc (like BSDs, and previously also macOS).

But there doesn't seem to be any concerted effort to standardize green threads. Win32 has had fibers for a while, but nobody's actually using them, and runtimes generally don't support them. Even .NET tried to do it in 1.x, but then dropped support in later versions.

I think you're spot on. For 99% of the use cases, traditional threads are the way to go. It's only when you have a truly massive number of logical threads (>100k, or even >1M) not doing anything most of the time, that OS threads reach their limits due to their aggregate stack size. In other words: web services, where each server thread either waits for input from the client or for a database reply, and only if they have to handle hundreds of thousands of concurrent clients.

This is not a concern for most Rust users, but it is a concern for large companies that are potential patrons of an up-and-coming programming language. I'm not saying it's wrong to cater to their needs, rather that it's not something over which regular Rust users should lose sleep.

Things that are easier with Rust's async:

• Timeouts and cancellation. Rust's async code can be aborted from the outside (with correct cancellation and cleanup of everything in progress). OTOH if you run imperative blocking code, you need every blocking function to cooperate.

• Full utilization of CPU and I/O in workloads that mix both. Async executor balances threadpools/polling queues for these automatically. OTOH if you just use regular blocking calls with no state machines/continuations, it will be hard to separate these two. A single mixed-use threadpool will oscillate between I/O-bound threads and underutilizing CPU, and CPU-bound threads and idling I/O.

Fully agree with that, and Rust makes that very easy still. Its 5-10 lines to spawn multiple threads that communicate with each other either via shared state or message passing, and I solve most paralleism problems that way to this day in Rust. :D

I abandoned some projects due to that as well. That, and constant breaking changes in major libraries such as `hyper`.

Maintaining Rust code is expensive. More than completing the first iteration of a project. Language such as Go or C are boring, but don’t have that issue.

> AFAICT, tokio is basically going to become the default assumption

I've noticed this as well. And then there are the libs that don't support async, like diesel. I lost time trying to find the right combination of libraries for a web project. There are a lot of things I don't like about Go, but this part is easier.

I noticed this a few months ago as well. I was looking for a way to do simple synchronous HTTPS requests in a CLI, and it seemed like using `reqwest` with tokio was more or less the default option in Rust. I ended up using ureq, and it looked like there may have even been ways to avoid it using hyper and an alternative tls-connector but the simplest solution seemed to be "just use tokio".

When something foundational, like networking, gains a defacto dependency on tokio, it seems inevitable that a large footprint of the ecosystem will eventually depend on it.

Is it still zero cost if the price to pay is a steep increase of code complexity?

The current model also still requires a lot of boxing and cloning, so it is far from being “zero cost” as advertised.

What's an alternative to async/await that's explicit about runtime costs?

Do you have a source on people generally disliking async/await? I've become a fan of it in JS.

Rust was the first language that made it efficient, abstraction without overhead (which took many years of work). It’s just a state machine with an enum holding the state, but of course it means that the memory model is harder to understand than with JavScript.

C# and C++ adopted basically the same model.

Isn't async/await from F#/C# world, or Scala has a different variant?

I'm confused... Scala doesn't have async/await.

There have been some vague discussions, but STM is (as you mention), tough in an impure language. It is also not clear that it achieves Rust's efficiency goals.

> What’s wrong with async_std?

The problem is that it exists. Or rather, that multiple async libraries exist and every attempt to employ asynchronous programming in Rust inevitably leaves you with the problem of aligning these different, redundant, incompatible, incomplete, evolving async libraries, which is an unmitigated disaster.

Rust, all by itself, is a non-trivial hill climb for developers. They're willing to bust out the climbing tools and make the attempt because they see the value. But then they get hit in the head by debris like futures::io::AsyncRead <-> tokio::io::AsyncRead and that is it; they come down off the hill and go find something else to scale. Worse yet they don't talk about it; they love Rust, the idea of Rust, and they want it to thrive so they avoid being critical.

IO and async is fundamental. It's too fundamental to suffer multiple, partial, incompatible, ever evolving realizations. This is the number one issue that threatens Rust. People have only so much patience to spare; only so many attempts they're will to make climbing the same hill.

I have hope. Companies like Amazon and Microsoft are making serious commitments to Rust because they too see the value. They're going to get knocked in the head by the same falling debris. And so there is a chance that while this is all still young and the MBAs and lawyers and rent seekers aren't yet savvy, Rust will receive the sort of tedious, expensive labor it so desperately needs to mature.

With standard library support, green threads can be just fine. I've worked with many, many C programs that were nbio and green threads. Cancellation is trivial when you are writing the scheduler! In these cases, I used multiprocessing when I needed parallelism. The answer to "If you're blocking on a socket recv in a thread..." is to not ever do that; the library should provide a green recv that appears to be blocking to the code, but is implemented with non-blocking calls underneath. With the privilege of being the standard library, there are many ways to enforce this.

N to M is much harder to get cancellation right, but again if you write the scheduler, you can define the cancellation points, so you are not beholden to undefined behavior. Instantly cancelling a thread is just not solvable, and for Rust, which cares about low-level performance &c. then long-running computations could explicitly check for cancellation when it is needed. Threads that perform I/O regularly will naturally hit cancellation points.

Cancellation is a huge problem in concurrency, and the usual answer to "how do I cancel a thread" is "you don't want to cancel a thread" which is rather unsatisfying. As you point out, it's not like using async and/or promises automatically solves the problem either; the only way to get it right is to build it in from the start.

Rust async doesn't quite solve the cancellation problem either.

Sure, you can stop polling the future at any time, but that doesn't mean that you left the system state consistent.

Careful thought is needed on every call to await in an async function. It might be the last thing that async function ever does.

That's probably something that should be true in a well-implemented system anyway. After all, processes could be killed at any point.

I don't know enough about Asio to make a good comparison, but

> Am I correct in assuming these are the same things as a reactor (kqeue/epoll etc.) vs a proactor (IOCP)

Close enough, yes.

> a proactor can be implemented in terms of a reactor.

Yes.

What you've described with pthread_create is basically a closure, just implemented within the limitations of C and like many things in C, wildly unsafe. You can of course interact with the underlying implementation if you want (Rust is quite capable of calling into libc directly), but then you're responsible for ensuring safety. Rust provides a safe wrapper over this with a closure which is generally easier to use and harder to misuse than the equivilent C.

Note that you don't need a closure in Rust to start a thread. You can just specify a function to be called (because functions implement FnOnce).

I would say it’s clickbaity.

Just turn all &str to String and use .clone() liberally while you get used to the language, and you'll avoid having to think about the borrow checker for most basic applications.

I think Haskell is stuck like you say because if your code is overly wordy, it will run slowly too, yet Rust is still relatively fast even if you do .clone() a lot.

The problem may be with the fuzzy conceptual notion of "systems language" that is the starting point of many of these languages that end up with effectively conflicting set of goals.

(I agree with Animats comment elsewhere in this thread blessing all threaing models as "OK in isolation". It's just they don't play well together in a single language.)

Single ownership and deterministic destruction are quite useful on their own though, outside of just memory management. I wouldn't call them niche. Rust makes use of them all the time.

Deterministic destruction is obviously very useful for resource management, and not just files and database handles, but also locks and scope guards.

Single ownership allows working with mutable data without dangers of shared mutability. Without it you either need true immutability, or defensive coding by proactively copying inputs to ensure nobody else can unexpectedly mutate data you have a reference to.

Single ownership also happens to nicely enforce interfaces that require functions to be called only once or that objects can't be used in invalid state, e.g. after a call to .deinit() or after intermediate steps in builders/fluent interfaces/iterator chains.

No, he could not. The problem emerges when trying to use state (a database connection, in the author's example) in the callback function. That requires a closure (or a managed global, but that's not zero-cost).

> [async] “colorless”

I’m super interested that you think that’s something that can exist, how would it work, what would it look like in your mind ?

I see you're a fan of Zig's design, but I don't really think Rust would be as you describe even if it was made today, for several reasons:

- comptime evaluation aren't something Rust designers are interested in, as it doesn't fit their functional programming mindset[1], (and it's not a new concept to Zig, D has had something similar for long).

- An IDE-first compiler is a good idea (and a must have for a production language today) but I'm not sure how feasible it is to start with something like that. If it's going to slow down early development, then it's definitely not a good move to go there first, but I don't know.

- per function allocation is a pain in the ass from a usability perspective. In fact it recreates the same “function color” problem you'd like to avoid. Just think of your non-allocating functions as blue and allocating ones as red functions, you can't call a red function from a blue one.

- Zig's “colorblind” asynchronous function rely on automagically switching between async and sync functionn at compile-time, and I really don't see that fitting with Rust's thrive for explicitness.

[1]: https://twitter.com/pcwalton/status/1369114008045772804

None of this is true.

Zig generics are dynamically typed; Rust generics are statically typed. Everyone in Rust was absolutely aware of dynamically-typed generics and they were actively rejected.

Explicit allocators were likewise rejected. They were deemed to add too much noise in the 99% case in which you just want to use the system malloc. You might disagree with that decision, but none of Rust's designers consider it a mistake.

I'm also very skeptical that the ability to automatically switch between async and sync would be the right decision for Rust. It may be the right decision for Zig. But in Rust we have to, for example, work properly with OS TLS and any sort of automatic async/sync switching would be a footgun.

The Rust community regards the JS community with contempt? Where does that opinion come from?

Why Java 8 as opposed to the latest JDK?

And what about C#? It's in a similar boat as Java.

Also, how is the Java memory model different from Go for this use case? They both allow mutation by sharing.

Humans waste billions of hours and dollars in casinos - apply your efforts here and you’ll help the human race much more.

Can you give an example that C+ can do efficiently that Rust cannot do efficiently even with ‘unsafe’?

There is a reason why people are moving away from shared memory parallelism.

It's not fun to deal with NUMA domains efficiently. For hardware engineers, it's not fun implementing cache coherency protocol efficiently.

There is a reason why even Intel was experimenting with channels back in 2010 and you see more and more "network on chip", "cluster on chip" designs with non cache coherent memory.

As we need more cores, shared-memory synchronization becomes too costly.

Source:

- https://en.wikipedia.org/wiki/Single-chip_Cloud_Computer

PS: I'm not even talking about the difficulty of writing correct concurrent data structures.

Even glibc authors get that wrong https://news.ycombinator.com/item?id=26385761

While you were chasing girls I was in my basement mastering java (SE 8u181)

This is just plain wrong. There's nothing you can do in C/C++ (or C+, as you put it) that you can't in rust, when it comes to parallelism. There's always unsafe if you really need it.