It embraces a defect introduced for BC reasons as if it's sound engineering. It really isn't.
If you start over, there's no reason any blocking API should really BLOCK your program. Your functions can look completely synchronous, but yield to the event loop when they invoke a blocking API.
Basically like Erlang works.
Eventually it will be the case, but these kind of "love the flaw" attitudes are slowing us down.
That implies a level of sophistication and abstraction that simply doesn't exist today, and probably won't for a while.
For this to work you either need an ultra-sophisticated compiler what will transparently auto-async your code at compile time (as realistic as a unicorn at this point) or a heavy runtime which will have performance implications.
So in the meanwhile I agree with TFA that coloured functions is probably the pragmatic choice if you want pay-for-what-you-use async right now.
Personally my main issue with async is that it seems to me that a generation of devs who grew up on JavaScript see it as the Alpha and Omega, the one and only way of handling any sort of parallel or event-driven system, not considering other approaches such as threads and/or polling. This sometimes results in spaghetti code that I personally find over-engineered.
To give you an example I hacked on rbw a week ago, a Rust command line client for Bitwarden. It's a good program, but it's completely built with async code and I genuinely don't get it given that it's almost entirely synchronous in practice (you query an entry, you enter your passphrase, you get a result). As a result I found it a lot harder to follow the flow of the program and understand how it all fit together. But hey, I eventually got it and managed to fix the issue I was debugging, so it's not the end of the world.
>For this to work you either need an ultra-sophisticated compiler what will transparently auto-async your code at compile time (as realistic as a unicorn at this point) or a heavy runtime which will have performance implications.
I may be misunderstanding this point, but if I'm not, it seems like gevent managed to do this for Python a decade ago and it still works well today. I still use gevent for new code because it gracefully sidesteps this function-coloring problem. (I know people don't normally associate "monkey-patch" with "graceful", but they somehow made it work. I guess this falls under the "heavy runtime" approach, but it doesn't feel heavy at all.)
True, but is this not also the case when using Python's native async/await functionality?
The difference is that async/await doesn't even work with previous pure-Python code which performs any I/O, either. There are thousands of ordinary third-party libraries which basically have to be tossed out the window and rewritten from scratch, despite none of them using any C extensions.
gevent works well with almost all of those old libraries.
Yes indeed.
> The difference is that async/await doesn't even work with previous pure-Python code which performs any I/O, either. There are thousands of ordinary third-party libraries which basically have to be tossed out the window and rewritten from scratch, despite none of them using any C extensions.
Hmm, yeah. I sometimes wonder about a language style where functions are monadic by default, and I guess being able to monkeypatch the internals is a way to achieve the same thing - rather than introducing a syntax for a "programmable semicolon", we can just monkeypatch the actual semicolon. Introducing effectfulness into code that wasn't written to accommodate it worries me, but I guess gevent usually works in practice. I guess a language like Frank is a more principled way of doing that kind of thing.
And the external API they provide is really clean; you generally don't have to think about any of the internals. You just use everything exactly like you already would and pepper in straightforward abstractions like gevent.Pool and gevent.spawn. Internally, it might be the antithesis of Pythonic, but the external interface and developer experience is very Pythonic.
you don't [1]
> you need an ultra-sophisticated compiler (as realistic as a unicorn at this point)
Isn't what Zig does, described in the post linked by a few other comments [1], basically this?
> That implies a level of sophistication and abstraction that simply doesn't exist today, and probably won't for a while.
This sounds like a description of UNIX and was true from the very first versions: a blocking call would trap the system, select a process task that can continue and jump to that instead. At the language level, I'm pretty sure we had this in the 1980s in Forth, and I don't think it was considered new even then (although I don't have a reference handy); libdill does this for C programs.
Or am I misunderstanding what you're saying?
OS-level async is what I accuse some devs to underuse, preferring language-level async constructs. I've read a lot of frankly FUD and cargo culting about how inefficient things like pthreads are. Let's not even talk about pre-fork parallelism which is probably the simplest way to use multiple cores when dealing with independent tasks but hardly anybody seems to use these days. I wonder if most devs even realize that it's an option.
In my experience coroutines were never really popular in the C world simply because without GC or at least a borrow checker it's just very hard to write correct code. Avoiding memory violations in C is tricky, avoiding memory violation in async C is asking a lot.
Rust does a lot better here thanks to borrow checking but it still leads to, IMO, very complicated code.
Speaking from experience: they don't. I recently picked up a Linux kernel development book [1] and after four or five chapters I was able to eliminate several bottlenecks and eliminate latency edge cases in personal projects with a greater understanding of the scheduler algorithm and process priority/affinity/yields.
I think the problem is that the vast majority of developers work on top of cross-platform runtimes that hide any detail that can't be easily implemented for all operating systems. It's been more than a decade since I've used Unix sockets directly in any language and I don't how to set SO_REUSEPORT in Rust. I'd probably have to implement it using `TCPListener::as_raw_fd()` and `unsafe libc::setsockopt`? It's just easier stay sane within the bumpers.
[1] https://www.amazon.com/Linux-Kernel-Development-Robert-Love/...
Depends on how much of it you want to solve automatically. The Zig compiler does essentially auto-async your functions. So I think you can write a whole lot of synchronous code, and then just have a single "async" at the top to have it yield to the event loop whenever it hits blocking IO.
So I think you can solve 90% of that problem without being ultra-sophisticated.
Automatic yield points and a proxy to syscalls are used for that.
It's also still plenty fast (as opposed to Erlang, which was mentioned in other comments).
https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b...
Like the article points out, then you would need green threads to do asynchronous work simultaneously. And if you are already using threads then there is no need for "async". The point of "async" is to give you the ability to efficiently manage the event loop WITHOUT threads.
This require either runtime-based or operating system support. If need be, you can always rely on the OS scheduler to be your "async blocking API".
Well, the original red-blue function article did say "just use threads", didn't it?
> Is it unnecessary performance optimization to parallelize multiple adjacent asynchronous functions?
The important word in your question is "async". Take that out and the answer is "no" - it's not unnecessary to parallelise. But the example serves well to illustrate at least one aspect of why red/green is wrong in my opinion: who decides what should be able to run concurrently?
Let's modify the example slightly, and assume we have a function `size(url) -> Int` that returns the size in bytes of a given URL. It's making network calls, so it'll have latency. Should the function be async?
As the developer of that function, I can't reasonably make that choice beyond "probably". But it comes with a cost. The caller can't now just call it: they have to await, and perhaps unbox the answer. If they're only calling it once then you've just added unnecessary complexity to their code.
The _callee_ is the one who's appropriately placed to decide. Using the example, we're calling it 3 times. So, as the developer writing the _calling_ function, I can decide that it's appropriate to paralellise.
To use GP's example, Erlang gets that the right way round. Functions are functions are functions. If I want to call a function synchronously, I just call it. If I want to parallelise, then I simply spawn the function instead.
> or should we just hope that the runtime/compiler gets smart enough to know what is safe to parallelize?
That would be a step on further still. It's definitely doable - compilers already do a buch of pretty sophisticated dataflow analysis.
But even today, the red/green async model is a very limited thing. With significant constraints. Other than perhaps rust - with its focus on zero-cost abstractions - it feels at best an interim step that asks programmers to compensate for a lack of good fine-grained concurrency support in language runtimes.
Functions are functions are functions. If I want to call a function synchronously, I just call it. If I want to parallelise, then I simply spawn the function instead.
Why not put the async idea on the caller side alone, as suggested and as seen in go?
fetch(url) // synchronous
go fetch(url) // asynchronous
if the compiled code of synchronous and async functions really has to look different for fundamental reasons, the compiler can still silently emit both versions (and gc unused variants)
Someone please help me understand, or rid the world of this async-await mess.
> the compiler can still silently emit both versions
I think that is zig's strategy under the hood (not 100% sure)
1. The function does not have a suspend point, so it is emitted as a normal function, and it just gets called like a normal function at the async callsite. Await is a no-op.
or...
2. It has a suspend point. It is emitted with the async calling convention, and any normal callsites to it also become suspend points.
`go fetch(url) // asynchronous`
This is not something you can readily abstract over. That depends on whether language is compiled vs interpreted, has a runtime or not, is scheduled or not, stack model, threading model, ownership model, and so on. `go myfunc()` implies something to dispatch, execute and reap that function and its metadata, and there's no one-size-fits-all solution.
You can design a language that has this feature, but it's not without tradeoffs, and it's certainly not something you could just introduce to a language unless it already lends itself to it.
Cilk is designed for parallelism more than for concurrency, but with a runtime augmented idle cpu detection, it would work perfectly for async io.
Cilk requires annotating async functions calls at the call point (with the spawn keyword to make them async), but not the funciton themselves, so there is no red/blue coloring.
Synchronization is explicit via the sync keyword, but in principle I think a compiler could insert the sync point on first use of the value.
I don't think a cilk style runtime would be heavier than an executor behind async/await.
> The _callee_ is the one who's appropriately placed to decide. Using the example, we're calling it 3 times. So, as the developer writing the _calling_ function, I can decide that it's appropriate to paralellise.
The right answer is polymorphism, and it's easy in a language with HKT (I do it in Scala all the time). If you make every function implicitly async (or possibly-async at the runtime's discretion) then you lose the ability to know where the yield points are, to get higher performance from blocking where appropriate, but more than that you just don't get consistent performance behaviour.
Thread-based code (CSP) is, after all, the most well studied model of parallel computation, and for a reason. Async code which achieves real parallelism may get much harder to interpret, especially if it's non-trivial (e.g. requestA.then(requestB).then(requestC); in parallel, requestD.then(requestE); and mix this up with mild processing between A and B and C, and between D and E - you can easily get to race conditions in this type of code even in single-threaded runtimes like NodeJS).
Huh? Traditional threading is not CSP; threads are generally defined as sharing memory. Async is much closer to the CSP model.
The main difference is that in CSP (and thread-based models) the thread of execution is explicitly represented as an entity in the code. In async models, the threads of execution are mostly abstracted away and implemented by a runtime scheduler, while communication is done purely by function return values.
Of course, you can typically implement any of these models in terms of each other (e.g. you can easily implement CSP channels in a language which offers mutexes and shared data; or you can implement them with async/await primitives). But the base support in the language and the patterns you'll see emerge in idiomatic code will be different between goroutine/CSP, shared-memory parallelism, and async/await.
Threads + some kind of channel (a la Erlang processes or Go's goroutines) are pretty much direct programmatic representations of CSP.
afaiu erlang is based on non-sequencial processes more like the actor model, there is no "communicating sequencial" process at the base of it (though you can implement csp in actor languages) afaik
here you can see joe armstrong and carl hewitt fundamentally disagree with sir tony haore (csp) and sequential channels as a fundamental construct [1] https://www.youtube.com/watch?v=37wFVVVZlVU&t=720s
again, apologies if im arguing something that wasnt implied, it was just something i noticed ^^
This approach tends to become a lot less simple if you have any sort of significant resource usage to manage: you’ll be fighting all of that magic when you have non-trivial memory usage, need to avoid limits on file handles or connections, etc. not to mention the runtime support for things like debugging.
Any time you see a long-running widespread problem and think there’s an easy fix, ask whether you’re really that much smarter than an entire field or whether it might be harder than you think.
db = connect_to_db()
result = run_query(db, …)
result2 = run_query(db, …)
result3 = run_query(db, …)
return build_response(result, result2, result3)
The same problem arises for memory usage: if you allocate memory it's going to stay allocated until the last async response arrives and if that's non-trivial it means that the async work might not be worth the hassle because your concurrency is actually RAM-limited below the point where you see any benefit over synchronous execution.
One common challenge here is that it's usually quite easy to miss this being a problem no matter what style you use if you don't carefully test with real data volumes or under perfect conditions. For example, if my code looks like this:
result_1 = run_query(db)
result_2 = call_other_service()
return build_result(result1, result_2)
There are, of course, ways to guard against this but then it's a lot harder to have a language make synchronous-looking code run asynchronously and leaving out async/await isn't saving you much if you have to sprinkle synchronization primitives all over the place. That doesn't mean you don't do it, of course, but it means there isn't a shortcut.
Haskell does that, and it is great. But there is no chance at all that I would want anything like that in Rust. It would be completely out of place, and break the entire concurrency model.
That would make the language unfit for any task I use it for today.
Therefore, you would need to deal with far more race conditions.
Even in single-threaded languages, your entire state may change during a single asynchronous function call. By differentiating between synchronous code (i.e. code that needs to be run in a single slot) and asynchronous functions, you can immediately see where you need to account for unexpected state changes.
(Yes, it's more complicated in multithreaded languages, but the main idea still holds because they usually all sync back to a single thread)