Hacker News Reader

I used/worked on a similar async model at FB long before I'd ever touched node. Threads are not really solving the same problem as async.

Imagine you are building the FB newsfeed. You have 10 stories and want to fetch them as quickly as possible. The stories are all different types and each refers to other data: profile info, privacy, comments (which depend its own profile fetch), likes, etc.

So you have this tree of dependent data fetches, how do you minimize the time waiting? You could walk the tree node-by-node, but that balloons your wait time. So you kick each bit of work off to a new thread and wait for it to be done. How do you wait for it? Lots of options of course, but they all end up looking like an ad-hoc implementation of async. Which is fine! But if you have a large codebase where a large fraction of code is dealing with this stuff you pretty soon want the runtime to handle this. And if you are mixing code written by others you really want everyone to use the same mechanism.

So the value of async isn't really in the specific implementation choices, it's that it lets you represent this tree in a consistent way. This is less about the number of requests per second, and more about how much code you have to deal with; plenty of places have low RPS but have accumulated lots and lots of code.

Second, threads have their own costs even ignoring performance. Arguably a big reason PHP/Hack worked so well for FB is that each request was single-threaded and started with a clean state; there's whole universes of bugs that are avoided in this model. And node doesn't have threads because JS doesn't have threads, microcontrollers may not have threads, etc.

I used "async" long before Node too. It's one of the reasons I knew to stay away from Node.

"ad-hoc implementation of async"

I think you're confusing the problem with the solution. I solve this sort of thing in Go all the time. This is literally what I was doing yesterday. It's fine in that context. You had to reach for async because it was the only option in your context, not because it was the best choice. Async as it is conceived of today was a hack for dynamic scripting languages that basically had no other option. They "won" there because the environments simply couldn't support any other solution, not because they outcompeted anything.

Go is internally doing async-like cooperative multitasking. You just don't see it because they actually integrated it into the language well.

As jerf said in a parent comment,

> It's just you manually doing what the compiler ought to be doing for you,

Which is the proper way of doing it. As soon as you expose all that plumbing a whole generation of inexperienced programmers are going to use it to build their sandcastles with and then you can spend the next two decades on the cleanup. Such stuff should be implemented once and made bulletproof rather than to give everybody a box with interesting shiny parts that will explode when used wrong.

> So you have this tree of dependent data fetches, how do you minimize the time waiting? You could walk the tree node-by-node, but that balloons your wait time. So you kick each bit of work off to a new thread and wait for it to be done. How do you wait for it?

This is exactly the kind of problem that is targeted by Project Loom [1] and structured concurrency [2] on the JVM. Async programming makes a lot of tools not applicable (or at least very cumbersome to use): debuggers, profilers, tracing tools, stack traces, etc.

[1]: https://openjdk.org/jeps/425

[2]: https://openjdk.org/jeps/428

> Where did it come from in its current incarnation? Node.

Rust's async/await is inspired by C# (which was inspired by F#, which was inspired by Haskell).

> right now threaded code is straight-up a better option on almost every metric,

Agreed that people are generally too eager to reach for async when they could easily get away with threads, and fortunately Rust makes threads extremely pleasant to work with. The whole point of Rust is that it doesn't force you to use any given paradigm when it comes to concurrency/parallelism, and has support for many approaches.

And yet it didn't learn that it took almost 10 years for .NET community to sort out async/await support across all layers of the stack.

.NET archictects have spent last year researching Go and Java Loom approaches, and have acknowledge if it had been today, most likely that would have been the approach taken instead of async/await, as many .NET devs still get it wrong.

During the "ASP.NET Core and Blazor futures, Q&A" at BUILD 2023.

This is the best practices of async/await in .NET as written by one of the ASP.NET architects,

https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...

Everyone rediscovers Erlang at one point in this space, it seems.

Yeah, it would be great if it had wider industry adoption.

Joe Duffy on Midori and async/await in a C# dialect: http://joeduffyblog.com/2015/11/19/asynchronous-everything/

Where he notes that the .NET implementation wasn't without issues on Midori.

Which is again another point of how the whole Rust's async/await process failed to learn from previous experiences.

Even worse, because in what concerns .NET, the runtime is part of the story, while in Rust that is yet another piece of the puzzle that is in motion, not yet decided, although it can be anything as long it is tokio.

> Where he notes that the .NET implementation wasn't without issues on Midori.

Indeed. In my opinion and experience async/await is a very leaky abstraction. I think it is definitely not worth it in most languages. Whether it is appropriate for rust I'm unconvinced. I think it is DOA in C++ with its required allocation, but I have yet to use it in anger.

I only have used them in C++/WinRT, as they are a kind of required to handle anything WinRT, and it was kind of ok when doing UWP, although it was much more complex as in WinRT case, it also takes into account how COM/WinRT compartments work.

See https://devblogs.microsoft.com/oldnewthing/20210504-01/?p=10...

Don't miss it.

See other post about why I blame node.

As for Rust supporting threads... yes! Yes it does! And it effectively solves all of the problems with them that can be solved at the programming language level. There's an irreducible increase in complexity with concurrent code, but there's only so much to be done about that.

I think a lot of developers have a tendency to massively overprivilege performance and always reach for the biggest, shiniest thing when they don't need it, and cost themselves a lot in the process. Sure, if you're doing tens of millions of things concurrently in Rust you may need the async support because threads can't do what you want. But before you write code based on the assumption that you're going to be doing tens of millions of concurrent things on a 64-core system, check that you actually are. If you've got an API server whose request rate is measured in tens per second, a really quite common case, you'll never notice the thread overhead. You really need quite a massive system nowadays to get to the point where that's even remotely a problem, let alone your biggest one.

I don't deny that when you are nailed to the wall and seriously wondering if 64 cores is going to be enough you may have specialized needs that require specialized solutions. I am glad that Rust has the option for those who need it. But async should be counted as a cost of such problems, not a benefit, and something you prove out as the only solution, not the first thing reached for.

It is the mindset that makes one buy a SLR, when they can't even make up all the options on the smartphone camera.

We wrote asynchronous driven network code for decades without syntactic sugar for it, and it was fine. That 5% performance gain can be had without it. Async syntax is a mistake. Not just because of the mess it makes across the program tree, but also because it brings with it a specific notion of how to do asynchronous I/O.

io_uring for example gives an entirely different model, one with some lovely performance benefits. I'm sure there's a way to make it play well with Rust async and tokio, etc. but they're not really the same model on the surface. And so having bolted async into the language syntax itself, and also adding an explicit requirement on concepts like 'executors' into the language, we've created a legacy problem.

IMHO async in Rust was a mistake. A systems programming language should not have mandated a technique like this, and should have stayed agnostic.

Having written decades of async code without rust (and still doing so in c++), I don't understand your point. It is really hard to write safe highly performant asynchronous code. Rust makes it safe, but without the additional "syntax sugar" it makes it very unergonomic. The developer velocity I can achieve with async rust is unbelievable compared to what I had to do previously.

I think your problem may be with tokio, not async. io_uring and async are not incompatible.

> The developer velocity I can achieve with async rust is unbelievable compared to what I had to do previously.

I have seen a glimpse of that in my paid work but I have to say it takes quite a while and a lot of nerves expended to get to that point. It's one of these things where you climb a mountain peak and can now see everything clearly but before that it's all a mess, mists and shadowy figures.

> A systems programming language should not have mandated a technique like this

Rust doesn't mandate anything. It's unipinionated when it comes to concurrency; use whatever approach that you think is best. Async/await is just one option among many.

Its presence as a fundamental syntactical element is a fairly strong statement about its advisability.

Its presence is not a mandate. It is not a decorative syntactical element, but affects compiler code generation the same way as rust has _synchronous_ generators.

A developer is still free to spawn a thousand foot-guns, and I daresay the assumption would be that they made that choice knowing how to properly juggle them.

> io_uring for example gives an entirely different model, one with some lovely performance benefits.

The io_uring model is also fundamentally async? So not sure what you’re arguing here. It’s just completion, rather than readiness based, but otherwise no different, and completely compatible with how other async things work in the Rust ecosystem (see tokio-uring).

If anything, I’d argue that io_uring is the best example of the benefits of async API’s over the “just spawn another blocking thread bro” model.

I think this is just a common misconception of io_uring based on its earlier implementations. io_uring natively supports a polling model.

On Windows side, IO Completion ports, BeginAsync()/EndAsync(), TPL and Dataflow.

Async in its current incarnation did not come from node. Eg Haskell had async/await in 1999. https://softwareengineering.stackexchange.com/questions/3774...

Node wasn't released until 10 years later.

And I have code still in production written in the "Perl Object Environment", one of several async frameworks for Perl, written before Node even existed. Also before Node existed, I had written code in the Twisted framework for Python.

Node did not invent async by any means and I know it in the strongest possible sense, having used it before Node existed. But those libraries, in use for over a decade, did not make everyone using them exclaim in joy "Yes! This is what all concurrent programming should be!" A few, sure, but far from everyone. They're kind of a bear, even after years of polish.

Not only did those libraries already know about callback hell, they had already implemented some of the (partial) solutions to it. Watching the Node propaganda was almost surreal to me because I could and more-or-less did predict how it would go, years in advance, as it recreated the experience already had by other languages. Experience that did not leave the impression that this was the paradigm for the future. These libraries typically languished within their ecosystems, kept around only because they were the only practical way to, say, keep your Python but also get concurrency. The fact they were the only way to proceed kept them alive, but they never really flourished despite being right there, readily available.

Node is the reason people are running around today claiming async is the bee's knees. Node is the reason why people come on to /r/golang asking how Go can possibly be used for network programming when it lacks the Magic of Async. Contradicting the Node propaganda is why people are nervous about saying "uhmm, hey, I'm using async in a big program and it's not exactly sunshine and rainbows". Prior to Node that would have just been the common understanding; these libraries were often viewed as powerful within their target language because there was no other way to do what they did, but tricky and complex to work with. It was well understood they easily degraded into a mess and were often difficult to onboard a new developer because of the difficulty of following the control flow.

All I'm really saying here is, the community opinion was correct before Node and we should just go back to that opinion, founded on decades of experience.

Exactly. I wonder how many people that are riding the async bandwagon have any actual experience building large systems that operate under some kind of reliability guarantee. It's a great way to pull a whole pile of unnecessary complexity into a codebase, lots of fun debugging hairy little problems and to solve interesting bugs with free footguns provided for all takers.

It's a kludge at best and it's quite annoying to see a first class project such as Rust be distracted like this.

Please keep preaching. Every time I've investigated async I've just asked "why is it so unnecessarily complicated?", but I don't have enough background to know if I'm just missing something.

Async await isn't useful because it's more ergonomic. It's useful because it's low overhead. If you don't care about that then rust might not be the right language for you the same way a language with a GC might be better suited for most folks. For my domain, any other choice would have made rust untenable. Rust has made all the right choices that make it an excellent choice for code I was otherwise forced to use c or c++ for. Not every language must bend its ways for every possible user, and most folks get upset when that inevitable happens because it dilutes the qualities that made the language useful for the original set of folks it was primarily useful for. Being popular unfortunately comes with the curse of not pleasing everyone.

IMO almost nobody demands a language to "bend its way" so as to not "make folks upset", it's just that the way Rust went about async/await is not ergonomic at all. It's also pretty dark, as in it's hard to surface good information.

Add Tcl events to it as well, with famous rants like this one, "Why Threads Are A Bad Idea"

https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/...

A bear indeed. I too used twisted circa about 2001 or so.

How popular is Node compared to Haskell. 10 times? 100 times 1000 times? . So Node marketing machine sounds about right to me.

Saying that Rust chose async because node did is such an absurdly ignorant, incorrect statement.

Rust didn't choose async because of Node. Async's massive popularity is because of Node. It existed long before then, and that's precisely part of my point. It had a bad reputation before then, and it's slowly-but-surely reacquiring it now.

Rust didn't choose async because it was popular. You can go ahead and read the massive, multi-year discussions on the topic if you'd like. They've been going on since before 1.0.

I read them at the time. The gist was basically "it has been empirically established that async is the right way to do concurrency" - ie, it was because of Node.

It was more "it fits best with our needs as a systems language (overloaded term, yada yada) and we should support a robust concurrency model sooner rather than later". The Rust devs were aware of green threads and the like. It is deeply unfortunate that async is still such a mess, though.

They specifically referred to C# and its efficient implementation

That's nonsense

I am not versed in computer science well enough to comment on the model in general but I'll agree that the current way of doing async is pretty sloppy. When you fully invest your project in it and use async libraries it does get better but some compilation errors still sound like dark magic (I'll forever regret not writing down a few of them I encountered last year because the team is receptive to changing rustc error message).

Though I'll also say plain old multithreading and async are serving different niches, in my experience.