[bob1029]

The thing I struggle with is that most userland applications simply don't need multiple physical cores from a capacity standpoint.

Proper use of concepts like async/await for IO bound activity is probably the most important thing. There are very few tasks that are truly CPU bound that a typical user is doing all day. Even in the case of gaming you are often GPU bound. You need to fire up things like Factorio, Cities Skylines, etc., to max out a multicore CPU.

Even when I'm writing web backends I am not really thinking about how I can spread my workload across the cores. I just use the same async/await interface and let the compiler, runtime and scheduler figure the annoying shit out for me.

Task.WhenAll tends to be much more applicable than Parallel.ForEach. If the information your code is interacting with doesn't currently reside in the same physical host, use of the latter is almost certainly incorrect.

[CJefferson]

I find async a terrible way to write interactive apps, because eventually something will take too long, and then suddenly your app jerks. So I have to keep figuring out manually which tasks need sending to a thread pool, or splitting my tasks into smaller and smaller pieces.

I’m obviously doing something wrong, as the rest of the world seems to love async. Do their programs just do no interesting CPU intensive work?

[tom_]

You're doing nothing wrong other than using async. You'll only become an async fan once you write a program that does no interesting CPU work, just a lot of I/O - because async is great for the case where the computer spends most of its time waiting around for multiple (or possibly even quite a lot more than that) I/O requests to complete, then does a bit of CPU work on completion of each in order to decide what I/O to do next. Then repeat forever.

This stuff is always a pain to do in languages that don't have this sort of facility, because you need to manually structure your code as some kind of state machine. But that's exactly the sort of tedious nonsense the computer can do for you, if only there's the language mechanism to let you explain to it what you want - which is exactly what async is for.

But it is fundamentally a cooperative multitasking mechanism, as code written in this manner expects to run atomically between awaits. So it's impossible for it to take advantage of multiple threads as-is, which is why languages supporting this mechanism don't bother.

If you are doing a lot of CPU work, that's a problem that async was never designed to solve. You need threads.

[CaptainOfCoit]

Are you using multiple threads or just a single one? Not sure why your application would "jerk" because something takes long time? If it's in a separate thread, it being async or not shouldn't matter, or if it's doing CPU intensive work or just sleeping.

[CJefferson]

If I’m using threads for each of my tasks, then why do I need async at all? I find mixing async and threads is messy, because it’s hard to take a lock in async code, as that blocks other async code from running. I’m sure this can be done well, but I failed when I tried.

[seabrookmx]

It depends what framework/language you're using.

It's messy in something like Python, but mostly transparent in C#. In C# you effectively are using async/await to provide M-N threading ala. GoLang, it's just different syntax.

OP references the C# method Task.WhenAll so they might be assuming other languages are equally capable.

[nemothekid]

You can map N-async tasks onto M-threads. This is essentially what Rust does, and if you squint this is how Go works as well.

A go routine is not that different from an async task, except the runtime inserts all the await points for you.

[taeric]

I have seen a lot of interfaces that I would be fine describing as "jerking" due to async silliness. Largely from odd reflows that result when the code completes in an order that is not "top down" in the function.

It can be convenient to have the code "just wait" for an async spot, but I do think there are some benefits to forcing the a bit more structure around it.

[pmontra]

Probably. In web development it's usually get data, transform data, send data. That's in both directions, client to server and viceversa. Transformations are almost always simple. Native apps maybe do something more client side on average but I won't bet anything more than a cup of coffee on that.

[dboreham]

Rest of the world doesn't love async. Just the loud opinionated people.