Hacker News Reader

Comment by daenz | Hacker News Reader

I learned Rust by writing a (fuse-based) filesystem [0]...about 30k lines iirc. Rust was challenging, but not crazy difficult (it helps that I have a C++ background). I loved it. Development was slower than a dynamic language, but faster than C++, and most importantly, I felt safe. It's a really solid language.

However, when I took a look at async Rust, it really did appear to be a mess. I have substantial experience with Python async/await (which is also a mess), so I'm not unfamiliar with the async concepts. Honestly, I think it's the idea of an event loop in a compiled + non-memory-managed language. You really have to think hard about where objects are living and for how long, and combine that with the illusory world of how async/await appears to work (versus how it actually works), it gets hard to conceptualize. Maybe I just didn't spend enough time with it to feel comfortable with it, but that's my hot take.

Imo, Go does performant concurrency right. Rust would be smart to adopt what Go offers.

0. https://github.com/amoffat/supertag

View on HN

Exactly. And worse, async in Rust is viral, because any code outside of async doing I/O is not good to use inside of async. And it gets worse: making everything async is not a good option. Effectively, it seems there is no viable answer: you need two of everything.

Go does do concurrency well, but unfortunately it’s only able to do that because of opinionated decisions that a language with Rust’s design goals cannot really make. They also have tradeoffs that I don’t think Rust developers would accept, like making calls into C functions slower. So I feel as though Rust async is at an impasse. It can be made much better, but it feels like the improvements will come at increasing complexity in the language, compiler and ecosystem. Meanwhile, the ideal end state seems like it will still have a lot of annoyances, such as the need to tirelessly duplicate anything that needs I/O for sync and async.

I almost kind of wish Rust would just drop async, as the rest of Rust is much better, having only minor issues that are very much fixable IMO. Instead the ecosystem is accelerating into it, and now it’s hard to avoid for some use cases.

I hope it all works out, because Rust is good and I’ve been advocating for its adoption at work and continually trying to adopt it elsewhere. But the issues with async are very dire, imo. Async rust is cool, but it isn’t what I would consider to be a similar level of robust, thoughtful design.

If Rust does decide to continue with async, they should really look into investing in improved docs and education around it. When I was looking at it a few years ago (maybe it has improved since then), I really did feel stupid for not getting the ideas/conventions/reasoning. If it was that off-putting to me, as someone with some experience, I can imagine it is very unapproachable to complete newcomers. It just felt like I was looking at something that shipped way too early.

The async chapter in Rust for Rustaceans was a great introduction. It leaves something to be desired because you walk away with it without knowing how to run any async code (it doesn't mention any runtimes, for instance), but it explains the concepts really well.

Async is new enough that the function and trait docs are getting better all the time. There was a time it was really ugly to use async, and I still find it a bit crufty but it's a lot more approachable for someone new to Rust.

It's happening, see https://github.com/rust-lang/wg-async . Everyone is aware that current async support in Rust is very much at "MVP" status.

The viral aspect is the thing which really annoys me as well about it: I have some apps that make one or two single requests to DBs in certain configurations, and I've had to end up using async for those parts (up to main() obviously, although not all code in the apps needs to be aware of async thankfully) due to many crates needing/using async now for this (which may well be good/fine for other peoples' heavy usage, but not really for my usage).

However, it means that even when these requests are not being done (and might never be for the running of the apps, as it's user-configured what the apps do and whether they make DB requests occasionally), these apps end up having some (it may not be much, but it's somewhat noticeable) overheads, i.e. coreCount threads are always created by the async infrastructure (despite being a single-threaded app in one of the apps cases), call stacks are deeper even though async is not really being used (although due to main() being async effectively that changes everything), meaning more memory usage for those threads's stacks (which is somewhat ironic, as that's one of the points of utilising async for heavy IO requests - reducing memory usage! - but in reverse it hurts my use cases a tiny bit).

Edit: I tried to use things like pollster (in an attempt to significantly isolate and limit the async usage to just where it was needed), and it wouldn't work for my use cases.

I'm on the verge of splitting the apps into two parts due to this, but due to the shared state, that would involve additional complexity (RPC or something), which I don't really want to stomach.

You can spin up a single threaded runtime to perform these async calls without the need to "infect" the rest of the program.

The strategy is to spin up a single threaded async runtime and to just perform that call and block on the runtime itself. The easiest way to do that is probably https://github.com/zesterer/pollster

And there really isn't much in there so you didn't need to worry about performance or anything like that.

I recently refactored a colleague's program from async to sync because it's essentially and entirely sequential.

The reason it started its life as async was the reqwest library, which first and foremost provides async methods to perform http requests.

However, tucked away behind a feature flag aptly named `blocking` there is a small API that wraps the async api and allows making sync/blocking calls in a non-async main. And there they employ the same strategy of having a thin async runtime that blocks on completion of the async call.

This works with runtime agnostic futures, but you can't do any I/O without requiring a specific runtime. reqwest for example doesn't use a generic block_on, it runs tokio behind the scenes.

You can spawn a simple Tokio I/O runtime with Builder::new_current_thread().with_io().build().

The catch is that it’s not really “simple”, and idk the performance penalty.

I tried things like pollster, and they wouldn't work in my case for reasons I can't remember (but I asked for assistance on the Rust Discord and there didn't seem to be ways around it).

A multithreaded runtime that is shared for all functions in the app - that other synchronous code then "blocks_on" - will also work. Or e.g. having a cached thread_local tokio runtime.

Btw:

> And there really isn't much in there so you didn't need to worry about performance or anything like that.

Actually you have to! In case you write a program that spawns background threads (with whatever async runtime), and then let your foreground thread interact with that - it will have performance implications since your program now does additional context switches. It might or might not matter for your application, but in general it's rather easy to lose all perf benefits that async code actually might provide by still requiring switches between full threads.

I worked on a rust project that had one thread with a httpserver all async, and another thread with some mqtt client all sync. Communicate over channel. No big deal.

I agree to a large extend. However its not that viral if you're the app developer. Tokio ( and iirc most other executors ) have a block_on and a spawn_blocking to jump between 'worlds'.

If all you're doing is something like "get 10 http request and concat them to stdout" then doing it with Rust async + a block_on call is pretty straight forward.

> because any code outside of async doing I/O is not good to use inside of async

This is (somewhat) similar in all programming languages and it is called coloured function problem:

https://news.ycombinator.com/item?id=8984648

The way you solve that problem is either 1) just use threads, which is fine for almost every program with the notable exception of webservers (and even for webservers an aversion to threads is often a premature optimization), or 2) make everything async at the language level by transparently intercepting all I/O, which is acceptable for a managed language (so, most languages) but undesirable for a language with bare-metal aspirations like Rust (we're writing a bare-metal hypervisor-ish thing, and we're using Rust because very few languages are acceptable for such a constrained use case (we're not using async for it, but hilariously we could be, since Rust's stackless approach is suitable even for systems too constrained to have threads in the first place)).

>I almost kind of wish Rust would just drop async, as the rest of Rust is much better, having only minor issues that are very much fixable IMO. Instead the ecosystem is accelerating into it, and now it’s hard to avoid for some use cases.

I've written a decent-sized project backed by Tokio/async Rust and when I'm in pure async code, it's honestly fine and I have few complaints (just... gimme stable trait async fns). I don't think it's worth dropping; async Rust has its place and is continuing to be iterated on.

What needs to happen is what's happening right now: people who write in Rust need to be louder about the fact that crates should be sync first, async second. And/or (my personal irrational opinion) the language needs to get over it and adopt Tokio into Rust proper.

If this proves difficult - the ability to be sync/async via feature flags - then this is something that the language needs to solve before other features IMO (I will admit I'm saying this without checking to see if it's being worked on, though).

It's usually easier to write the async version first and then write a sync wrapper. See for example the `postgres` crate.

Right, I get that.

I'm saying that the sync version shouldn't be "run tokio blocking in the background", because while you might be giving them an out on async infection in theory, you're still making them bring in the entire dependency tree and you're still creating more background resources than is necessary.

The `postgres` crate launches a "current thread" tokio runtime which doesn't really have much overhead in terms of background resources. I agree about dependencies though.

"async infection" is kinda interesting when you think about it. To use `postgres` as an example, talking to a database is asynchronous whether you like it or not. To use blocking APIs to access it is just to allow something (typically the OS) to pretend that it isn't.

In general I've found the experience of writing a program async from the beginning to be very good in Rust, and in the very rare cases (in my field of work) where I have some genuine blocking to do, Tokio provides good tools for that (`tokio::task::spawn_blocking` and `tokio::task::block_in_place`). I can imagine that if you were writing a largely CPU-bound program, async would feel more like an "infection".

Honest question: do you really need concurrency to solve problems?

Sure... The most obvious case is running an internet service, but if you're asking if I've ever done something where there's either a strong CPU-bound or latency constraints, the answer is "yes."

Today's world even power constrained devices like phones have many cores. Laptops and desktops are getting more cores just about every year. Even chromebooks are heading towards 8 cores last I heard.

Take for instance wanting to backup a directory to a remote server and/or cloud. Sure you could use scp, single threaded would be fine, read a file, hand it over to scp, which does encryption and transport.

However you'd waste quite a bit of network bandwidth and disk space. Ideally you want incremental, so you need a database for metadata. You could add compression as well. But you likely want deduplication so if you have a system image for a virtual machine and 1% of it changes you can upload 1%. You also likely want to detect corruption if you upload a backup, then restore and the file has changed.

There are single threaded programs that do these kind of things, but they tend to be very slow, some well known backup clients that promise a flat rate for infinite backups often use the approach to reduce the amount of data it's practical to backup.

So ideally you have multiple threads, one for scanning the filesystem, one for talking to a database of metadata, another for checksumming plaintext, encrypting, and checksumming the encrypted blob, and yet another for managing a queue of blobs to upload.

Without concurrency even simple things like uploading backups can become painfully slow.

There’s a common problem of software design where people believe they need to put their logic and their IO together, and not only is that not true, but it screws up testing, scalability, and feature evolution when you do.

A language that punishes you for not keeping your IO separate? Well, that isn’t necessarily a bad thing. Often when I find people complaining about how hard something is, I find out they’re trying to ice skate uphill, and if they backed up a second and took some advice they wouldn’t be struggling so much.

Microsoft tried to educate developers with best practices by making WinRT async only and it backfired, despite the tooling available in .NET Native and C++/CX for it.

Similarly the way AsyncTask or GCD worked on mobile platforms before other alternatives came into place. Android even went as far as starting to kill processes that were doing network accesses on the UI thread.

All because most will take the easy path if there is an opportunity to do so.

If you don’t mix logic with I/O then why do you even need async-await as a language feature? I’m not disagreeing with you, but the whole point of async-await was to be able to mix asynchronous operations into your code without having to turn your logic inside out.

But if you isolate your I/O from your logic, then what benefit do you get from async-await?

I guess it can still make the “I/O logic” code more readable…

IO callbacks don’t compose. That’s why everyone is switching to async await (that, and faddishness). This problem is amplified by mixing business logic and IO, so the motivation is in the wrong place and continues through the refactor because we’re solving only half the problem.

Most of the interesting business logic is collating data from three or four places, and fetching that data sequentially is high latency. So you can do that part asynchronously and then present the input to sequential (pure) code that derives the answer. That pure code is very easy to unit test.

The “problem” is now I have three kinds of code - IO, logic, and orchestration - and people intuit that this is more complicated than the bookkeeping they do and externalization onto others by mashing all three concerns together in one file, and then duplicate it with elaborate fakes in their tests. Which they are hesitant to write or others are hesitant to maintain, leading to low value, high effort tests.

There's been some discussion among the Rust language developers about a mechanism to let functions be "generic over asynchronicity", to help alleviate all the duplication. But it's still in the very earliest design stage, and might never happen

Do you have a link to a proposal or the discussion?

https://github.com/rust-lang/lang-team/issues/162 https://hackmd.io/Aw2L3VmPQsm0ANC_XMughQ

> And worse, async in Rust is viral

So just like in Java, C#, Python, ...

In other words asynchrony is viral.

I feel like I should respond here.

Yes. The async mechanism is similar to Java, C# and Python.

However, all of those languages you listed are JIT’d languages with automatic memory management.

In Rust, the mantra is very much “zero (runtime) cost abstraction” much like C++, and unlike Java, unlike C#, unlike JavaScript, unlike Python, unlike Ruby, etc. And being a language that deals with performance critical, possibly latency sensitive applications, running on potentially very strapped embedded devices, Rust libraries very much do try to provide you with the absolute best case performance.

With JS, everything being async is completely reasonable because control flow always returns to the event loop anyways. With JS, Java and C#, the runtime performance is plenty fast to do some harder compute tasks, but most of the compute is spent in large abstractions and the applications are still largely I/O bound. With Python, all of that applies except the runtime performance is a fair bit worse, too. At the bottom of all of these languages is a runtime written in low level code and often times third-party modules using C++.

Rust is different. Firstly, Rust is the language at the bottom.

Given all of that, almost any library has to support sync and async for ideal characteristics; there’s no good way to use sync libraries in async and visa versa. But because of the differences Rust has to other higher level language, it’s much harder to accomplish this without thoroughly duplicating code.

While it might never matter if you insist on never writing stuff you’d consider library code, it’s still a design issue, it still impacts the ecosystem, and indirectly, it still will impact you.

I hold that I believe the ecosystem is already strained to try to make fully idiomatic, zero-compromises libraries, and the additional pressure of async bends the story until it breaks. It’s true that Rust’s design for async is not terribly unique, but I feel it is in a uniquely poor position, for unfortunate reasons that are not necessarily the fault of the Rust developers or designers.

> However, all of those languages you listed are JIT’d languages with automatic memory management.

Granted. However, if you mix and match sync with async code in Java, C#. You're going to have a very bad time™. At runtime. Article https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Predates stable Rust. Rust didn't somehow add virality to async. It was viral from the start.

And using Rust async with Arc/Box/Pin/etc. works more or less like in GC-land.

> I hold that I believe the ecosystem is already strained

Strained? Not really. Async imo is a bit overblown. Most libs I am contributing don't use async at all.

My opinion is that async was rushed. Pin needed for Async was a well-spring of unsoundness issues, probably still is. Async fn in traits is missing. GATs, etc.

Features that would remove some issues mentioned in the article are being worked on. But then people would be it's 2022 and no async in Rust, joke lang amirite.

Damned if you do, damned if you don't.

Yes, async is viral in those other languages; but the solution is usually, just use async everywhere. That’s not the solution in Rust. It simply won’t work for the same reason that Rust isn’t GC’d.

> Features that would remove some issues mentioned in the article are being worked on. But then people would be it's 2022 and no async in Rust, joke lang amirite.

To be clear, I hate programming language development driven by memes. I don’t think that was the case with Rust async; I think Rust async was released because it was hotly anticipated. It was definitely, at least in my opinion, the reason why Go implemented generics (at least ahead of other potentially more useful changes…)

And yes, it is true: they can technically fix many of these pain points. But I flatly disagree with your notion that the ecosystem is not having difficulty with this, and I also don’t think there is good reason to be optimistic about the timelines for fixing some of these harder problems.

On the ecosystem. I could point to numerous examples, though I really don’t want to single any out. The NATS client library for Rust is an example where I found myself surprised: outwardly, everything looks like it’s in good shape, but internally, it is using Unblock to mash sync code into an async world, which apparently uses a thread pool limited to 500 threads. Now I don’t know how many libraries inappropriately use this strategy, but the fact that it exists and has found use in decently popular production software is not a good sign. Again, I don’t want to start crapping on a bunch of projects, so I’m leaving it at this.

On optimism for fixing the problem:

I think that Rust has made immense progress on resolving issues that have come up and building features around painpoints. However, when it comes to issues around memory management, pinning, etc. there’s been a lot of nearly-intractable issues: technically, they can be solved, but they aren’t being solved. Today, in safe rust, it is impossible to allocate a structure larger than the stack. Placement new is always just around the bend. Rust genuinely delivers on many of its promises W.R.T. safety, so it is immensely disappointing to me how often I’ve run into this problem. I know structures that are bigger than the stack may seem niche, but the stack really isn’t that big, and as far as I know there’s not even a guaranteed size, so if you test on Linux your app may very well work just fine, but then you run it on Windows and it all explodes. To me this is a worst case scenario of failure cases… and I think this is the easiest and most basic conundrum out of all of them. That doesn’t mean it’s easy to fix, of course, but still.

Maybe what they’ve released now is better than nothing, but I do believe the ecosystem suffers for all of the added complexity and duplication. Writing good Rust library code is not easy.

> just use async everywhere. That’s not the solution in Rust. It simply won’t work for the same reason that Rust isn’t GC’d.

At this point, I have to say RC is a primitive form of GC and it would mostly work. Not high performance but it would work.

> To be clear, I hate programming language development driven by memes. I don’t think that was the case with Rust async

First, most programming is driven by fads. Second, my point was that if Rust waited more people would pan it for not having async.

Rust async was "rushed". It took years, but we still didn't get smooth experience out of it. Many pieces were missing.

It was rushed because many people wanted it, many developers were sick of having it in limbo, etc.

> Today, in safe rust, it is impossible to allocate a structure larger than the stack. Placement new is always just around the bend.

I don't follow Rust development too detailed nowadays, but if you are experiencing hardships, have you considered providing support to it? Either via money or time donations?

I understand complaining that some closed source company is prohibiting you from doing something, but this is an OSS project.

https://www.youtube.com/watch?v=9E_rtUgUF58

Rust cannot copy what Go does without compromising on various language design goals. What Go does is good, but what’s good for Go isn’t always what’s good for Rust. That goes the other way too :)

Rust did try to have something closer to Go before 1.0, but it led to so many issues it was removed. Those issues aren’t a problem for Go.

Here are a couple of examples of the changes that were made in the two or three years before Rust 1.0 if anyone wants to read more:

https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...

https://pcwalton.github.io/2013/06/02/removing-garbage-colle...

Go has a runtime and a GC, and importantly can implement an event loop outside of anything reached by tracing execution from your code's entry point. Rust's philosophy lead them to make the runtime something you bring in with a library import and start manually. Bundling Tokio with every binary would not be their way, although something like it may one day wind up in the standard library.

Does Tokio have a concurrency model similar to Go's?

No, since rust async is stackless. There is a stackful coroutine implementation for Rust: https://github.com/Xudong-Huang/may

I'd like to have some clarification on the following claims:

  - Rust async is a mess
  - Python async is a mess

What does "mess" means here?

I have been writing Rust code for a few months, and Python code for more than a decade. I have to admit that I do not know the internals of the Python's async model, but as a "user", I think that trio (and asyncio with 3.10 / 3.11 is getting better) is really great.

The ability to call `trio.run` / `asyncio.run` anywhere to start an async loop does not "contaminate" the async/await keywords up to the entrypoint. Which is great.

In Python, calling an async function returns a coroutine object (that can be awaited). In Javascript it returns a Promise. In Rust it returns a Future.

From the "user" point of view, it's all the same. And I don't know many developers who are interested in how it works under the hood, because (like in math/physics/science in general) it's very useful to sit on the shoulders of others.

If I understand correctly, Rust gives you the tools, and the "shoulders" belong to the library developers (like tokio). Which is fine to me.

So, I really do not understand what "mess" means, what it refers to, and what I (as a "user") can do about it. Also, if the internals change, how will this impact my code?

trio and stdlib has different primitives for sleeping/locking/garhering/etc. And you can't change loop implementation by simple ioloop_of_this_year.run(async_main) in the main().

This is nitpicking, I never said that.

There is still no explanation for what "mess" means, but I don't think it means having multiple competitors providing an implementation.

The fact that there are multiple async Python libraries means that the internals are generic enough to allow that. From what I understand of Rust, there could be another "tokio" as well. And they would not necessarily be compatible either.

This is like saying "You can't use a Django model with SQLAlchemy".

My path to Rust async sanity was using lots of Rc. Though at times when I'm using lots of Rc, I question why I'm not just using a GC language.

I really like Go as a language and you can approximate a lot of its development style by just using channels similarly in your own code. I frequently employ crossbeam channels to that effect.

I was about to say. You could avoid a ton of ‘Rc’s by just using channels instead.

To a certain extent, it's just enforcing what you have to do for correctness. If you have concurrency (even without parallelism), and objects are shared across contexts, you have to keep track of when objects are in use or not. The other option is enforcing exclusive access (which is just a way of maintaining a refcount of 1)

At least Rust makes it easier with an Rc/Arc type! Can't tell you how many refcounting bugs I've dealt with in C since you have to remember to increment and decrement the count manually.

"Using lots of Rc" is what we call Java Disease elsewhere. Usually it indicates trying to sidestep architecture problems instead of solving them.

Often you Don't Care, and anything that works well enough lets you move on to the next thing. As long as you and people around you agree on the goal and tradeoffs, it is OK.

> Though at times when I'm using lots of Rc, I question why I'm not just using a GC language.

This seems like the wrong way to look at it?

Focusing on the spots in your code where you’re using RC and concluding you ought to be using GC misses the fact that all of the spots in your app where you’re getting along fine without GC would suddenly be forced to bear the costs of GC.

And RC isn’t a poor man’s GC; Apple concluded that Automated Reference Counting was a significant memory and CPU win over running a GC. Unless you’re littering RCs literally everywhere, you’re probably not doing anything much worse than ARC does in Swift (in fact you’re probably doing better if you don’t do it anywhere the compiler didn’t force it, because Swift has less lifetime info and is forced to be more defensive) – you’re more than likely coming out ahead versus what your runtime costs of a GC would be.

(But if you’re not concerned about runtime memory or CPU cycle costs at all, then sure, Rust is probably at the wrong level of abstraction for your problem)

> Apple concluded that Automated Reference Counting was a significant memory and CPU win over running a GC

I really don’t think it is true in the general case. Of course Apple will claim that, having betted on it with Swift, and also it may be true in their general niche (mobile devices with not much RAM). But if we are in a server setting with plenty of RAM available, tracing GCs of e.g. the JVM are quite green on the CPU (which is another important factor in this setting), and they provide probably the best throughput (as GC can happen on another thread concurrently)

> Python async/await (which is also a mess)

This! There seems to be a move to (somewhat) "async everything" in Python. But it just results in bad developer UX, it's verbose and unneeded 95% of the time.

I wish Gevent had been adopted as the starting point for an official way to do "none threaded" parallelization.

Lack of 'async' in Go has been a great design choice (aka, an absolute blessing).

People complain a lot about Go's missing features, and they did end up adding generics, but their conservative approach I think has been a net benefit for Go.

Rejecting language feature is something that's hard to do, and it takes a lot of experience, and I dare say wisdom to stick to it.

It's the other way around, Rust tried Go's approach and rejected it. The original incarnation of Rust was heavily inspired by Limbo, which was the language Pike developed prior to Go. As of 2011, you could describe Rust as a slightly lower-level Go, it even had (a poor stub implementation of) a GC. Rust's Go-style green thread runtime was removed in 2014 because it complicated the C interop story too much (which is a tradeoff Go is happy to make).

It's not a matter of minimalism or simplicity, it's a matter of different priorities. Rust's stackless async support is suitable for systems like microcontrollers, and the design reflects that.

> stackless async support is suitable for systems like microcontrollers, and the design reflects that.

Tangent: How feasible would it be to have a language where the required stack space for all function invocations is statically known at compile time, just as the sizes of Rust futures are statically known? I guess this would be even harder, because with async functions, the compiler only has to store the state of the function in a statically sized structure when it reaches an await point. But I'm guessing that running out of stack is a common problem when developing for microcontrollers.

You can predetermine function stack sizes as long as you don't do anything resembling C's "alloca" (Rust doesn't support alloca directly, but it supports dynamically-sized types in some contexts which would stymie this). But from there you need to use that information to figure out the maximum stack usage of the program, which means exhaustively determining all possible execution paths, which can be a hard problem (you also need to forbid recursion, even mutual recursion, which languages generally don't try to do (something something y-combinator)).

I may be very wrong here, but the JVM byte code’s method structure explicitly has a stack size and local array max size property, both calculated at compile time. Are they using some heuristic here?

I'd bet that the stack size you refer to doesn't include callees (i.e., the stack used by procedures called by the method in question).

Oh you are right, Java has two stacks, an operational and a method/function stack. Only the former is calculated ahead of time (and the latter is configurable at runtime).

> Rust's stackless async support is suitable for systems like microcontrollers, and the design reflects that.

This is the argument you hear, but how does it play out in practice? I don't know of any async runtimes that don't use Arcs, you can't use the async trait crate (boxed futures=allocations) and you don't have the escape hatches needed (Arcs) when you get too deep in type-hell. To this day, I haven't heard any embedded folks praise async Rust. I'm by no means an embedded expert, but if I were to do embedded I'd likely go with a plain old event loop to be safe.

Getting zero-cost (static only) stackless async was a huge flex, and I'm very impressed with the proof of concept. I'm just wondering whether it actually targeted the intended demographic.

I recently did an embedded rust project. Gave up on rust `async` and rolled my own asynchronous runtime on top of "synchronous" rust. It was much nicer than worrying about the type system. Since it's an embedded project with no OS, it's not hard to get peak performance from a very simple polling async runtime.

The thing that makes async runtimes complicated is handling multithreading in an intelligent way, and that's not something that worries most embedded engineers.

I work professionally in embedded rust, and we don’t use async. That’s because we’re aggressively static; there’s no dynamic allocation in the system at all. This isn’t inherently an issue with async on bare metal, but it doesn’t really buy us anything, so we’re not doing it.

That said, it is very cool, and does work well, if you want to do it. I think for many projects it would make sense. For our requirements, synchronicity works, and so we’re sticking with it, but folks on my team use it for other things, just not in the specific context we’re in.

The key is that nothing in async rust requires dynamic allocation. This is in opposition to C++‘a async stuff, which can in theory optimize away the allocations that are required, but you’re relying on the optimizer to do that. Our particular environment allows us to be 100% static, all the time, and so we’re pursuing that route as far as it can go.

You really can get quite far by having everything be statically allocated, placing reasonable constraints on input sizes/rates, and making use of ring buffers.

I've only worked on embedded development using C++, but I didn't really encounter any issues writing (admittedly, somewhat simple) device drivers with no heap whatsoever.

The problem is, Go uses a concurrency model (stackful coroutines/fibers) that was all the rage in the 90s (to the point where the Windows APIs have vestigial support for it) and then got abandoned by everyone except them for reasons that are still applicable.

Here's a paper on the history and flaws that was written to argue against adding them to C++:

"Fibers under the magnifying glass" by Gor Nishanov

https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13...

TL;DR: They don't play nicely with FFI and that's a big part of why Go is its own little semi-closed ecosystem... the polar opposite of Rust, where things like PyO3, Helix, Neon, cbindgen, etc. are a huge competitive advantage.

Reply on news.ycombinator.com