What async promised and what it delivered • Hacker News Board

Re: What async promised and what it delivered

#11

Post by brazzy » Wed, Apr 22, 2026, 10:03 AM UTC

andrewstuart wrote: post #3

I like async and await. I understand that some devs don’t want to learn async programming. It’s unintuitive and hard to learn. On the other hand I feel like saying “go bloody learn async, it’s awesome and massively rewarding”.

What's awesome or rewarding about it?

It forces programmers to learn completely different ways of doing things, makes the code harder to understand and reason about, purely in order to get better performance.

Which is exactly the wrong thing for language designers to do. Their goal should be to find better ways to get those performance gains.

And the designers of Go and Java did just that.

Re: What async promised and what it delivered

#12

Post by afiori » Wed, Apr 22, 2026, 10:05 AM UTC

nottorp wrote: post #4

andrewstuart wrote: post #3

I like async and await. I understand that some devs don’t want to learn async programming. It’s unintuitive and hard to learn. On the other hand I feel like saying “go bloody learn async, it’s awesome and massively rewarding”.

> It’s unintuitive and hard to learn. Funny, because it was supposed to be more intuitive than handling concurrency manually.

Some come to async from callbacks and others from (green)threads.

If you come from callbacks it is (almost) purely an upgrade, from threads is it more mixed.

Re: What async promised and what it delivered

#13

Post by joelwilliamson » Wed, Apr 22, 2026, 10:06 AM UTC

Function colouring, deadlocks, silent exception swallowing, &c aren’t introduced by the higher levels, they are present in the earlier techniques too.

Re: What async promised and what it delivered

#14

Post by swiftcoder » Wed, Apr 22, 2026, 10:21 AM UTC

brazzy wrote: post #11

andrewstuart wrote: post #3

I like async and await. I understand that some devs don’t want to learn async programming. It’s unintuitive and hard to learn. On the other hand I feel like saying “go bloody learn async, it’s awesome and massively rewarding”.

What's awesome or rewarding about it? It forces programmers to learn completely different ways of doing things, makes the code harder to understand and reason about, purely in order to get better performance. Which is exactly the wrong thing for language designers to do. Their goal should be to find better ways to get those performance gains. And the designers of Go and Java did just that.

> It forces programmers to learn completely different ways of doing things, makes the code harder to understand and reason about, purely in order to get better performance.

Technically, promises/futures already did that in all of the mentioned languages. Async/await helped make it more user friendly, but the complexity was already there long before async/await arrived

Re: What async promised and what it delivered

#15

Post by chmod775 » Wed, Apr 22, 2026, 10:26 AM UTC

joelwilliamson wrote: post #13

Function colouring, deadlocks, silent exception swallowing, &c aren’t introduced by the higher levels, they are present in the earlier techniques too.

Function coloring also only applies to a few select languages. If your runtime allows you can call an async function from a sync function by pausing execution of the current function/thread whenever you're waiting for some async op.

Libraries like Tokio (mentioned in the article) have support for this built-in. Goroutines sidestep the issue completely. C# Tasks are batteries included in that regard. In fact function colors aren't an issue in most languages that have async/await. JavaScript is the odd one out, mostly due to being single-threaded. Can't really be made to work in a clean way in existing JS engines.

Re: What async promised and what it delivered

#16

Post by shakow » Wed, Apr 22, 2026, 10:28 AM UTC

nottorp wrote: post #4

andrewstuart wrote: post #3

I like async and await. I understand that some devs don’t want to learn async programming. It’s unintuitive and hard to learn. On the other hand I feel like saying “go bloody learn async, it’s awesome and massively rewarding”.

> It’s unintuitive and hard to learn. Funny, because it was supposed to be more intuitive than handling concurrency manually.

Frankly, async being non-intuitive does not imply that manual concurrency handling is less so; both are a PITA to do correctly.

Re: What async promised and what it delivered

#17

Post by paulddraper » Wed, Apr 22, 2026, 10:38 AM UTC

> This was bad enough that Node.js eventually changed unhandled rejections from a warning to a process crash, and browsers added unhandledrejection events. A feature designed to improve error handling managed to create an entirely new class of silent failures that didn’t exist with callbacks.

Java has this too.

Re: What async promised and what it delivered

#18

Post by brazzy » Wed, Apr 22, 2026, 11:12 AM UTC

swiftcoder wrote: post #14

brazzy wrote: post #11

Earlier quoted context omitted.

What's awesome or rewarding about it? It forces programmers to learn completely different ways of doing things, makes the code harder to understand and reason about, purely in order to get better performance. Which is exactly the wrong thing for language designers to do. Their goal should be to find better ways to get those performance gains. And the designers of Go and Java did just that.

> It forces programmers to learn completely different ways of doing things, makes the code harder to understand and reason about, purely in order to get better performance. Technically, promises/futures already did that in all of the mentioned languages. Async/await helped make it more user friendly, but the complexity was already there long before async/await arrived

Yes - I was really talking about "asynchronous programming" in general, not the async/await ways to do it in particular.

Re: What async promised and what it delivered

#19

Post by brazzy » Wed, Apr 22, 2026, 11:38 AM UTC

palata wrote: post #5

nottorp wrote: post #4

Earlier quoted context omitted.

> It’s unintuitive and hard to learn. Funny, because it was supposed to be more intuitive than handling concurrency manually.

It is a tool. Some tools make you more productive after you have learned how to use them. I find it interesting how in software, I repeatedly hear people saying "I should not have to learn, it should all be intuitive". In every other field, it is a given that experts are experts because they learned first.

> I find it interesting how in software, I repeatedly hear people saying "I should not have to learn, it should all be intuitive". In every other field, it is a given that experts are experts because they learned first.

Other fields don't have the same ability to produce unlimited incidental complexity, and therefore not the same need to rein it in. But I don't think there's any field which (as a whole) doesn't value simplicity.

Re: What async promised and what it delivered

#20

Post by tcfhgj » Wed, Apr 22, 2026, 12:07 PM UTC

brazzy wrote: post #11

andrewstuart wrote: post #3

I like async and await. I understand that some devs don’t want to learn async programming. It’s unintuitive and hard to learn. On the other hand I feel like saying “go bloody learn async, it’s awesome and massively rewarding”.

What's awesome or rewarding about it? It forces programmers to learn completely different ways of doing things, makes the code harder to understand and reason about, purely in order to get better performance. Which is exactly the wrong thing for language designers to do. Their goal should be to find better ways to get those performance gains. And the designers of Go and Java did just that.

What different way of doing things?

If I want sequential execution, I just call functions like in the synchronous case and append .await. If I want parallel and/or concurrent execution, I spawn futures instead of threads and .await them. If I want to use locks across await points, I use async locks, anything else?