Async await: the worst thing to happen to programming?

https://andrewzuo.com/async-await-is-the-worst-thing-to-happen-to-programming-9b8f5150ba74

by thunderbong • 2 years ago

67 134 2 years ago

andrewzuo.com

thunderbong• 2 years ago

Non paywall

https://freedium.cfd/https%3A%2F%2Fandrewzuo.com%2Fasync-awa...

kristianp• 2 years ago

I think the idea behind c# async await was that you could use multple threads without having to worry about the details. It seemed redundant to me to have awaits in a web server. That runs multiple threads already, why does my code have to be async now? I hated it too.

OtomotO• 2 years ago

Because of I/O.

Without any kind of async (this includes green threads) you run out of (OS) threads very fast.

This is not a black/white decision whether Async makes sense for every API all the time or never.

It's a solution to a specific problem that occurred (and still occurs) a lot.

The article was just about the syntax though, because they are still using asynchronous programming via coroutines (or goroutines ;-))

the-lazy-guy2• 2 years ago

It's not about syntax. There is a huge difference in implementation and semantics between stackful coroutines (which go uses) and stackless coroutines (which most languages with async/await use).

For all practical purposes goroutines behave as separate threads with blocking calls. The fact that they are multiplexed on a few system threads is an implementation detail.

Otherwise you could say that using system threads directly is also asynchrnous programming. After all, your thread gets suspended on system calls (including synchronization primitives) and is resumed upon their completion.

tightbookkeeper6• 2 years ago

you run out of (OS) threads very fast.

What does run out mean?

marijnz0r2• 2 years ago

Although it seems async/await is based on multiple threads, this is not the case. To learn about this, read this blog post: https://blog.stephencleary.com/2013/11/there-is-no-thread.ht... Please let me know what you think.

rqtwteye2• 2 years ago

I think it’s nice for server stuff but on a desktop app it’s a pain to deal with. MS definitely went overboard with a lot of APIs being async only. A lot of people don’t seem to understand that async/await is still multithreading so in a desktop app they tend to mess up. Not sure how it’s in mobile.

marijnz0r2• 2 years ago

Although it seems async/await is based on multithreading, this is not the case. To learn about this, read this blog post: https://blog.stephencleary.com/2013/11/there-is-no-thread.ht... Please let me know what you think.

gpderetta11• 2 years ago

Parent didn't say that "async/await" is based on multithreading, they said "it is multithreading", which is definitely correct. It is a form of cooperative multithreading with the statically enforced restriction that you can only yield when the thread stack contains a single stack frame.

It is true that an async/await task doesn't map 1:1 to an OS thread, but that's neither here nor there.

rqtwteye2• 2 years ago

The code after an await often gets executed in a different thread based on my logging.

metaphor• 2 years ago

https://archive.is/bDczv

seanhunter• 2 years ago

The worst thing to happen to programming you say?

Worse than null-terminated strings in C? Worse than null being return on failure of dynamic memory allocation? Worse than nullability of columns in sql which Tony Hoare (the author) called "my Billion-dollar mistake"? Worse than the Knight Capital update bug that caused a $440million loss in 45minutes meaning Knight went out of business and was taken over? Worse than the innovative design of Therac-25 that caused deaths and serious injuries by giving patients 100x the intended doses of radiation? Worse than the Fujitsu Horizon system that lead to deaths due to stress and suicide, innocent people being put in jail etc...?

I could go on but you get my point.

What a staggeringly stupid headline in service of clickbait.

primitivesuave• 2 years ago

The net effect of these "syntactic sugar" diatribes has been many lifetimes of wasted developer effort in migrating between programming languages and frameworks, and countless products/investment dollars fizzling into oblivion because the developers couldn't stop worrying about how pretty the code looks.

DaiPlusPlus2• 2 years ago

Worse than the Fujitsu Horizon system that lead to deaths due to stress and suicide, innocent people being put in jail etc...?

Horizon had really bad bugs, yes - but it wasn't the software that caused the cover-up or the miscarriages of justice: it was the management of (then-)privatized Post Office Ltd that decided they could not afford the risk of losing big government contracts if any word got-out that the system was making fundamental ledger errors. Most of everything else can be blamed on the sheer separation between the devs and the actual end-users: these problems could have been caught and fixed if the Horizon tech-support people weren't 100% subordinate to upper-management: if I learned that our support people were using phone-scripts that were as bad as the PO's I'd threaten to resign).

(though I'd argue the real fundamental problem here wasn't technical, nor managerial, but a simple consequence of the UK's entrenched class-system: subpostmasters generally don't read Classics at Oxbridge, which means in the eyes of the establishment that they're probably the ones at fault)

I'm not mad at the ICL/Fujitsu devs - they were severely understaffed (I gather it was literally just 4 people?), but I am disappointed (and in a state of disbelief) that they evidently didn't have any devs competent enough to know how to design a transactionally-safe retail POS system in the first place (and P.O.S. is the word...): hiring and retaining good people would have avoided this episode entirely (...though no-doubt something else would have led to a similar management scandal eventually - it's in the nature of almost all large UK businesses at this point.

gizmo• 2 years ago

The billion dollar mistake refers to pointers being nullable. Old school type systems not supporting the equivalent of Maybe<T>, basically. It's not specific to columns in sql.

Async/Await is a relatively recent development and the author is free to argue it's bad paradigm that makes simple things way harder than they need to. It wouldn't be the first time our industry jumped on a very silly bandwagon! Calling something "the worst" is fine. It's not a literal claim and it doesn't deserve your scorn.

mcraiha2• 2 years ago

My beef is with Web Crypto. Why are encrypt and decrypt async?

phpnode2• 2 years ago

Because otherwise the main thread will be blocked while those operations take place and the whole ui will freeze

maxbond2• 2 years ago

You'll find this convention in other JS crypto stuff as well, like libraries for password hashing. Eg:

https://www.npmjs.com/package/@node-rs/argon2

https://www.npmjs.com/package/bcrypt

Though the bcrypt package does provide an additional sync API. (You should be using argon2 though.)

mcraiha2• 2 years ago

Yes, but you can offer both sync and async methods. Web Crypto only has async.

andrewstuart2• 2 years ago

Cause they can be slow.

tomovo• 2 years ago

And we're still awaiting any of their benefits.

Sirikon• 2 years ago

I think Medium is worse

tmountain• 2 years ago

Ha, I have to agree with you. Fluff all the way down.

fabian2k3• 2 years ago

It is quite annoying for older codebases in C# that have a lot of existing sync code, but for new code it doesn't matter all that much. You use async methods for IO and DB access and in many applications this means that most of the methods will be async.

I only played around with it a bit a long time ago, but I didn't find Go concurrency as simple and easy as it is often sold. It felt very low level, which is fine for the design goals of Go, but also meant that I was still left with doing some harder parts myself.

Concurrency in C# with async/await is pretty easy for the straightfoward cases that make up most of a typical application. You do have to keep to a few rules and it certainly has very dangerous footguns, but those are minimized if you use consistently use async methods instead of sync.

achr2• 2 years ago

The only real landmine for c# is the default thread synchronization. If it was inverted, the language would be much better off. I think they also made a mistake in removing the OOTB method for throwing away the sync context, but I guess there are many third party libs that provide it.

fabian2k3• 2 years ago

.NET Core web apps have no synchronization context anymore, which is exactly what you're asking for if I understand you correctly. There is no need to call ConfigureAwait there.

I think this is different for GUI apps, but I have no experience with that.

andrewstuart2• 2 years ago

I love async and await its one of the best things to happen in programming.

Simple solution to concurrency.

I appreciate its hard to grasp at first but it’s literally second nature now I rarely need to even give it much thought.

bborud2• 2 years ago

CSP is simpler. Simpler is easier to get right.

I used to write a lot of asynchronous servers in C up until a couple of decades ago. I found it easy. Most people didn't. We have better ways of doing things today.

DaiPlusPlus2• 2 years ago

CSP is simpler. Simpler is easier to get right.

If it's the same CSP I'm thinking of, then yes, but it's only simpler because it relies on enough people on the team having a good grasp of these parts of CS. Based on my own experiences in uni I can tell that courses on formal-methods and the like are probably the least-popular: being taken by a tiny minority of students - it follows then that only a tiny minority of software-writing professionals will have the requisite level of understanding to apply these approaches to their day-job - and those that do are likely already employed within an organization that relies on these formal-methods (e.g. safety-critical avionics, Wall St. quants, etc) which in-turn will help attracts other highly-capable people.

...now contrast those imagined employers with the rest of the software industry: unsexy line-of-business application developers, SaaS dev contract shops, the places where people who couldn't get jobs at Google or OpenAI might end-up working; and also consider the larger-still community of non-professional software writers (people doing VBA in Excel to anyone who simply wants to learn how to make an interactive website for themselves).

CSP is not going to help this latter group. And, in fact, it's this very latter group which drives programming-language design because that market is 100x the size of the formal-methods-ivory-tower people (who are probably using gratis open-source tooling anyway).

Compared to CSP, async/Await is something that you can demonstrate to someone with almost zero experience writing software, who probably can't even afford the time to try to understand how it works, but the mechanics of putting the `await` keyword in the right place can be taught in a few hours and suits 95% of their needs.

-----

If languages like C# or JavaScript were designed only to suit people like you or me then the ecosystems around those languages wouldn't be anywhere near as big, nor those languages anywhere near as decently supported and maintained. If the "price" for that is putting-up with a handful of language-warts then I'm happy to make that trade. I've still got Z3 for everything else :)

unwind• 2 years ago

I think the article confuses "spinlock" with "busy-wait", which made me confused too.

sebstefan3• 2 years ago

The only original insight of this blog post is that it's nice to be able to use `sleep()` without async/await in Go, which is also true for Rust and Rust has Async.

It does not stem from async/await that Javascript doesn't have sleep()

iudqnolq2• 2 years ago

    function sleep(ms) {
        return new Promise((resolve) =>
            setTimeout(() => resolve(), ms)
        );
     }

CryZe• 2 years ago

I still don't know why that isn't just provided for you.

sebstefan3• 2 years ago

You're returning a promise, that's a red function. It's async

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Sleep() should halt, this returns immediately

If I want my code to actually halt, I can either make myself red and use await on your red function, or I resign myself to put everything after the sleep in a .then()

UnreachableCode• 2 years ago

[flagged]

ninetyninenine9• 2 years ago

Async is equivalent to the io monad. It is in itself a monad, I know, but I’m saying it’s just like the io monad. It pollutes everything it touches. It’s literally only effective when paired with IO. So it’s actually in many ways identical.

And that’s a good thing.

In attempting to avoid the pollution u end up implementing the imperative shell/functional core pattern.

Most programmers don’t know that pattern. But for those in the know, the pollution is a good thing.

If you programmed in Haskell you know what’s up. The way you avoid the io monad from polluting everything is part of what makes the program so modular. Async does the same thing. Literally.

   await b(await a())

The above is roughly equivalent to this in haskell:

   a >>= b

How do you avoid pollution? The answer to this question makes your program better.

gpderetta11• 2 years ago

Haskell has significantly more powerful abstraction capabilities than your average async/await language though, making coloring less of a problem.

Also in Haskell you can only perform IO (aside from unsafe IO I guess) inside the IO monad, potentially making the abstraction worthwhile, this is not the case in many other languages.

ninetyninenine9• 2 years ago

It’s the same in typescript if your io is exclusively always called from async functions.

jmillikin3• 2 years ago

"X is just a monad" isn't a useful statement, because lots of types are monads (e.g. lists, hash maps, and nullable pointers).

An important difference between async/await and Haskell's `IO a` is that it's possible for asynchronous code to invoke sync code, and in some languages (such as Rust) vice-versa. So it acts more like a monad transformer, providing operations `IO a -> AsyncIO a` and `AsyncIO a -> IO a`.

The main challenge of async/await is that unskilled people who don't understand threads try to use async/await as a substitute, which leads to bizarre articles like "what color are your functions".

ninetyninenine9• 2 years ago

I said async functions can be treated as the IO monad. And I also said that I realize that promises are themselves monads but that wasn’t my point. The point was to use async functions as coloring in the same way Haskell does it with the IO monad.

tromp• 2 years ago

That's not Haskell AFAIK. Do you mean

    a >>= b

also known as monadic bind of a and b?

ninetyninenine9• 2 years ago

Yeah typo. Corrected.

instig0078• 2 years ago

The above is roughly equivalent to this in haskell:

It's not equivalent.

How do you avoid pollution?

Haskell has <$> and the infrastructure of HKTs to stop this infectious propagation of IO, other languages do not, and their async/await colors do not isolate side-effectful actions from the rest pure parts of your codebase.

https://hackage.haskell.org/package/base-4.20.0.1/docs/Prelu...

ninetyninenine9• 2 years ago

I said roughly equivalent. Async functions pollute and represent io in the same way the io monad does.

The io monad does not isolate io from your pure code. It’s infectious just like an async function.

It’s the abstractions and ways to stop the infection that makes the code pure. You don’t even need hkts to do this. Most languages don’t have a type representing this infection. The infection propagates everywhere without anyone realizing it. The IO monad explicitly tells the developer that the infection is occurring.

I’m saying that async functions do the same thing as the io monad.

The <$> operator in Haskell is just sugar for patterns to stop the pollution from occurring. You can implement it in typescript too. It just won’t be as general as that operator is defined across functors. In typescript you would define a function across only promises.

mzimbres2• 2 years ago

Only in poorly designed code you have problems like this where Async Await goes viral. It can be avoided by spiting libraries into an IO part that uses Async/Await and a protocol part that is sans-io. Using async code to access data that is already in the application memory is inefficient and should be implemented synchronously with regular functions instead of asynchronously.

gpderetta11• 2 years ago

This seems a no true Scotsman argument. In actual real applications it is not always possible to split IO from non I/O parts and the virality of async prevents composition and encapsulation without significant refactoring.

mzimbres2• 2 years ago

In actual real applications it is not always possible

This depends on what are your expectation. IO operations must suspend to wait for data read and writes, therefore it is not possible to avoid Async/Await. In other cases you might have multiple tasks depending on a specific IO operation, for example, one connection to a database that is used by multiple HTTP sessions, here it is also not possible to avoid Async/Await because those sessions are bound to an IO operation.

The real problem however comes when tasks that can complete synchrously are implemented with an asynchronous interface, for example

  message = Await websocket.read(socket, buffer, ...)

This is a poor design because a socket read can pull multiple messages from the kernel buffers into user space and there should be a way to consumed them without Await. Many libraries however don't for watch this problem and that results in the everything is async madness.

fzeindl• 2 years ago

Here are more arguments against async/await: https://www.youtube.com/watch?v=449j7oKQVkc

Ron Pressler always was an advocate for blocking code and even joined oracle to add virtual threads to the JVM, thus invalidating the performance argument of the async/await/non-blocking crowd.

I really wish young developers would be taught about the actor model and communicating sequential processes before falling for the false promises of async/await-land.

And I wish JavaScript runtimes had a way of expressing continuations /blocking threads on their eventloop.

ahoka3• 2 years ago

That performance argument never was a real issue for most applications anyway. You rarely have context switching as a bottleneck in a run of the mill web app, usually it's suboptimal queries, accidentally quadratic naive algos. I think even memory access patterns are more of an issue if you are compute heavy. Considering that "performance" matters at all for the applications purpose. Not everything is a high throughput load balancer.

tightbookkeeper6• 2 years ago

And somehow all these programmers who never care about performance because “computers are fast” become micro-optimizers, willing to restructure every line of code to save a few KB of RAM and rare handful of ms for a context switch.

com2kid2• 2 years ago

Tl;dr the author doesn't understand why having "async operation running in the background" is a useful primitive in a language.

Well, for one example, it means the syntax for kicking off dozens of IO requests and collecting all the results is trivial.

Also I'm tired of people saying "async is infectious!" as if it is something clever.

Having concurrency be part of the type system is a good thing!

justinclift• 2 years ago

Tl;dr the author doesn't understand why having "async operation running in the background" is a useful primitive in a language.

Isn't that covered in the paragraphs starting with?

  And if so you could create some other way to run it asynchronously like Go’s go foo().

ahoka3• 2 years ago

"the syntax for kicking off dozens of IO requests and collecting all the results is trivial."

Please show me this trivial code, assuming I want to process 12 requests in parallel at most (and always processing 12 at the same time until there's non left to process).

fabian2k3• 2 years ago

In C# you'd use a Channel for this, which is pretty easy to use. But of course that is built on top of async/await, with those alone it is far from trivial to implement your specific case.

CookiesOnMyDesk• 2 years ago

Something like this, depending on how you want your input and output to be supplied.

    public async IAsyncEnumerable<HttpResponseMessage> SendTwelveRequestsAtATimeAsync(IAsyncEnumerable<HttpRequestMessage> requests)
    {
        HttpClient client = new();
        List<HttpRequestMessage> requestsBatch = [];

        await foreach (var req in requests)
        {
            if (requestsBatch.Count < 12)
            {
                requestsBatch.Add(req);
            }
            else
            {
                foreach (var res in await Task.WhenAll(requestsBatch.Select(client.SendAsync)))
                {
                    yield return res;
                }

                requestsBatch = [];
            }
        }
    }

joshka• 2 years ago

The rust version of this has an inherent complexity that is very similar to your requirement. Processing at most X requests at once is the job of a Semaphore, until there's none left to process is the job of join_set.

    let mut tasks = JoinSet::new();
    let semaphore = Arc::new(Semaphore::new(12));
    for i in 0..100 {
        let semaphore = semaphore.clone();
        tasks.spawn(async move {
            let _permit = semaphore.acquire().await.unwrap();
            sleep(Duration::from_secs(1)).await;
            i * i // simulate some result
        });
    }
    
    while let Some(result) = tasks.join_next_with_id().await {
        let (id, result) = result?;
        println!("Task {id} result: {result}");
    }

That allows you to collect the results as they come in and align it to the various ids. If you only care about the final result and nothing why things are processing,

    let results = tasks.join_all();

The task is written inline there, but could as easily be an async function

    for i in 0..100 {
        tasks.spawn(process_request(i, semaphore.clone()));
    }

mg4• 2 years ago

A quick fix to the problem would be to allow synchronous functions to use await.

pansa23• 2 years ago

But using `await` is fundamentally what makes a function async

mg4• 2 years ago

What problem would arise if synchronous functions could use await?

fendy3002• 2 years ago

Yeah that's why in nodejs I made functions as async unless I know really well that it won't need await. Though that seems bad, it's not the worst due to how good async/await actually is.

Unpopular opinion, it makes me want to have a setting where all function is async by default, and all function calls are await by default. With `nowait` and `sync` as the opposite

pier25• 2 years ago

In V8 it used to be the case that every await was translated into 3 extra function calls and this caused big perf issues.

These days I think it's only one extra function call but still...

noelwelsh• 2 years ago

The function coloring post[1] covered this very nicely some time ago. It's definitely still an issue in any "monadic" approach to IO.

People who use progressive languages[2] will be using effect systems in a year or two, and this problem will go away.

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

[2]: Unison, OCaml, Scala, and maybe more I don't know about.

ChrisMarshallNY• 2 years ago

To me, the title seems a bit extreme, but I think of it as really just synchronous programming.

True threaded programming is difficult. I find modern closure syntax, where closures can access parent contexts, to be the most effective way to write concurrent stuff.

In either case, you still need to worry about things like thread contention/locks and whatnot.

Those of us, of a certain age, can remember “refCon” (reference context) parameters. I haven’t had to use one of those, in ages.

kabes• 2 years ago

tl;dr author discovered blue/red problem, then went on to discover coroutines and likes coroutines better. Same old discussion, nothing new.

pansa23• 2 years ago

Obligatory link to “What Color is your Function?”

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

mcntsh2• 2 years ago

People think too much about these things.

mjd• 2 years ago

That's why they pay us the big bucks.

mcntsh2• 2 years ago

No "they" pay you to ship features.

alkonaut4• 2 years ago

The tradeoff in Go as I understand it is that you can't know whether the runtime will opt for single threaded concurrency or parallelism? That seems like it could be a headache, but there will always be a headache somewhere in concurrent programming. Perhaps the Go headache is smaller than the C# one in this case.

Doing blocking IO together with UI code is pretty bad in general though. Disks are certainly not quick enough to have File.Delete(...) be blocking unless you know the disk isn't on a network server which is aboard a satellite leaving the solar system or whatever edge case you'll invariably run into.

flohofwoe• 2 years ago

Doing blocking IO together with UI code is pretty bad in general though.

Non-blocking IO without multithreading doesn't require async/await though, all operating systems have had non-blocking IO functions for decades, they just never made it into language stdlibs.

alkonaut4• 2 years ago

Yes, and blocking is usually faster. It's entirely correct for code to be blocking by default because it shouldn't be assuming that there is any interactivity going. If I want to make a console utility that scans some files then I don't need to worry about whether a UI is being repainted. So I completely agree with treating asynchronous as the odd case, and blocking as default which is not what JS does but it's what e.g. .NET IO does, and if you want to have a responsive UI together with IO you can often just combine a processing thread that blocks, and a UI thread that doesn't. The case where you'd want proper async IO is when you want to wait for 100 IO tasks each with unknown duration, where each is really async at the OS level anyway but your IO API doesn't expose that. Doing 100 threads isn't really a good option.

tightbookkeeper6• 2 years ago

But most windows 98 era Ui programs were 1 or 2 threads…. You just handle events in order in a loop.

It works and is far more responsive than what we have today.

Disks are certainly not quick enough to have File.Delete(...) be blocking

What if you invoke a delete and then it fails and you want the user to respond? What will the state of your UI be when that happens?

alkonaut4• 2 years ago

What will the state of your UI be when that happens?

If you can't do anything else until you know whether it was a success or failure, then you ensure that. E.g. you disable every single button that allows the user to do something else before the previous operation completes. Basically the theory is usually that you can allow the UI to "read" the program state while a "write" operation is still in flight. Typically this results in the user being able to for example scroll a document so it re-renders correctly etc. After the in-flight operation succeeds/fails, you can show the user the message if required, then enable new operations to happen. But the UI never stopped pumping messages so it was always responsive at least.

65102• 2 years ago

Precisely!

I had lots of pending requests, the goal was to have as many as possible (since the whole job took about 30 min) without freezing the UI.

When the callback happens there is work to do. The pattern is to do this work immediately.

Then there were as many as [not] possible bits of work to do simultaneously. Since the amount of work per job is unpredictable deliberately making the amount of simultaneous jobs unpredictable is insanity.

Synchronously I can do [say] 50 requests per second, parse 55 and have a buffer.

The solution to the riddle is not to limit the number of requests by 90% and extend the task to take 5 hours while not using 90% of the resources. Then UI freezes only become less frequent, they don't go away.

Instead I store all data from all callbacks in an array along with a description and use a setInterval to parse a configurable number of responses per second while adjusting the new requests to the size of the backlog.

But then it isn't really async anymore.

delegate• 2 years ago

The article complains that async/await 'infects' all the code that touches it and forces the callers to use async/await too.

But isn't the same true with go channels ? If you want to asynchronously interact with a channel (that is, without blocking the main thread), you have to do it in a go block and the caller has to do the same and so on ?

Promises behave similarly - must wrap your code in promises all the way.

These constructs are alternatives to the good old callbacks, which force you to write your code inside callbacks, thus 'infecting' everything and leading to callback hell.

This 'cascade infection' effect is due to the inherent nature of things happening asynchronously, which contradicts the synchronous program flow inside a thread, so when the async event terminates, the program has to jump to a handler in order to process the results.

In the end it's a matter of taste imo..

fer2• 2 years ago

It's the same for many things. Java throws, const-correctness in C++, etc, etc.

As some other comment said, it's like the Haskell IO monad and that's OK, because it lets you isolate and be aware of the implications of that code.

instig0078• 2 years ago

https://hackage.haskell.org/package/base-4.20.0.1/docs/Prelu...

gpderetta11• 2 years ago

the article complains that async/await 'infects' all the code that touches it and forces the callers to use async/await too. But isn't the same true with go channels ?

I'm not familiar with go, but I don't think so: stackful coroutines abstract better than the stackless kind.

whoisthemachine• 2 years ago

Yep in some way the programmer needs to express that the routine will have to _continue_ when IO completes (which will necessarily go up to the top of the stack in some way, unless you don't care about the result of the IO operation), or the runtime needs to block until IO completes.

fwip• 2 years ago

In a big Go application, most of the time you're not writing code that runs in the "main" thread. If you're writing a UI, you put the UI code in its own goroutine, and pass messages to it. If you're writing a server, most of your code will be in your endpoint handlers, which run as their own goroutines.

In >95% of your code, it's fine to just write `foo_val <- foo_chan`, without spawning a goroutine. From a pragmatic standpoint, it's not really different from `foo_val = expensive_foo_calculation()`. This block of code is waiting for something else to finish, and the Go runtime is smart enough to decide whether or not this thread should be parked until that result is ready.

And, as a bonus, `foo_val = expensive_foo_calculation()` looks the same, even if the implementation launches 10 cpu-bound goroutines and reads from 30 files to do the work.

deskr• 2 years ago

I'd argue that the pyramid of doom callback hell is easily a lot worse than async/await.

ffriend• 2 years ago

There seem to be two distinct topics:

1) async programming vs. threading

2) infectious async/await syntax

Async programming is great. Coroutines are a powerful tool, both for expressing your ideas more clearly and for improving performance in IO-heavy systems.

async/await syntax may not be the best design for async programming though. Consider example in Julia:

  function foo(x)
      @async print(x)    # some IO function
  end
  function bar(x)
      @sync foo(x)
  end

`foo()` returns an asynchronous `Task`, `bar()` awaits this task, and you can invoke `bar()` from whatever context you want. Now look at the Python version with async/await keywords:

  async def foo(x):
      print(x)     # some IO function
  def bar(x):
      await foo(x)
  # SyntaxError: 'await' outside async function

Oops, we can't make `bar()` synchronous, it MUST be `async` now, as well as all functions that invoke `bar()`. This is what is meant my "infectious" behavior.

Maybe we can wrap it into `asyncio.run()` then and stop the async avalance?

  def bar(x):
      asyncio.run(foo(x))
  bar(5)

Yes, it works in synchronous context. But path to asynchronous context is now closed for us:

  async def baz(x):
      bar(x)
  await baz(5)
  # RuntimeError: asyncio.run() cannot be called from a running event loop

So in practice, whenever you change one of your functions to `async`, you have to change all its callers up the stack to also be `async`. And it hurts a lot.

Can we have asynchronous programming in Python without async/await. Well, prior to Python 3.5 we used generators, so it looks like at least techically it's possible.

instig0078• 2 years ago

Can we have asynchronous programming in Python without async/await.

Gevent exists: https://sdiehl.github.io/gevent-tutorial/

noiv• 2 years ago

If your program starts spanning multiple machines or awaits user input CPS becomes a topic. At first it's scary, after a while you just assume everything is async.

CPS: https://en.wikipedia.org/wiki/Continuation-passing_style

djaouen• 2 years ago

Uhhhh, just use Elixir? This is a solved problem.

neonsunset• 2 years ago

The author is simply unskilled and lacks critical knowledge.

jitl4• 2 years ago

You need or want async/await in any program that has UI on the main thread, because you do not have the luxury of blocking the main thread if it’s running UI. It’s fine to have blocking code on background threads, but blocking the main thread will cause the dreaded hour-glass or beachball cursor and render your app totally unresponsive. For GUI programming you at least want async/await or an equivalent to model UI event handlers that dispatch work to the background, and then can resume work on the main thread to update UI when the background task is complete.

Swift for example is transitioning from using a lot of callbacks and manual thread dispatch everywhere to using async/await and while the infection aspect is annoying from time to time, needing to deal with continuations/callbacks manually tends to be just as infectious, which was the old way. Even worse is manually wiring up message passing infrastructure inside the app. I wonder how Go UI libraries deal with this? I wrote some X11 apps in Go back in the day and had a bad time whenever I blocked the main thread waiting for a response from a background worker but maybe today there’s better abstractions in the native UI libraries.

The other big downside to threading is the mental overhead of needing to consider the memory model, worry about parallel memory access of objects causing problems, and needing to review code with a microscope in case someone is introducing memory access violations or the even worse deadlock/contention cases. Some programs really benefit from large shared data structures and those are fraught to share across threads and I think that’s where multi-threading gets its somewhat deserved reputation for being annoying.

Go is wonderful for the things it’s built in tools and semantics are well-suited to handle: request/response (where the UI lives in some other process that talks to Go; Go is always the “background” thread pool) or run-till-completed jobs that just print logs as their UI. It is kind of horrible for other stuff. I personally found the channel management and concurrency situation inside the Kubernetes source code really hard to follow since that’s a kind of program that’s all about long lived data shared structures & systems communicating with each other; it would probably be more understandable in Erlang or something.

ghthor• 2 years ago

I find go pretty good at writing TUI’s using the react inspired lib, bubbletea, by the charm group.

Do all real work OOB and send messages of “state” into the rendering loop where all state can be reduced and then rendered into the interface.

cafard• 2 years ago

I was thinking that yesterday afternoon in dealing with some Python, but then found that

import asyncio import something_else

...

asyncio.run(something_else.that_runs_asynchronously(x, z, z))

took care of this.

karmakaze• 2 years ago

That was the most useless async/await post I've seen. The only useful bit is that the Go implementation isn't similarly painful.

First of all, it gets the function color problem backwards. Async await forces 'coloring' of execution to be async. But the desired number of colors is one which is what you have without async/await.

The way Go solves this is by making all 'threads'/goroutines async context without saying so and there's no way to make them not that. Effectively they all started gray-purple or whatever color that was to begin with. It would be as if all the Rust developers went all in and said "Everyone let's only do async."

The problem isn't promises/futures etc, they work fine as can be seen in Java with their CompletionStage. You can even use Executors with thread pools without function-coloring. I never understood the need or desire for async/await keywords (and the corresponding 'rest-of-program' transformation that happens under the hood. That Rust adopted it is the main reason I won't consider entering the ecosystem unless it somehow gets sorted out e.g. with two library ecosystems, basically bifurcating the language.

Async await: the worst thing to happen to programming?

Related Stories