Hacker News Reader

Comment by crazygringo | Hacker News Reader

Very true. :)

The genius about them, however, is that with all those, we discovered that you could get rid of "goto" afterwards. Which was kind of amazing.

"Await", on the other hand, doesn't remove the need for callbacks -- it just makes it much easier to use them in a lot of common use cases, in a much clearer way. But there are still plenty of valid/necessary uses for callbacks that can't be handled by "await".

View on HN

On the contrary, there are still perfectly good uses for goto. The two I can name right off the top of my head are stack-like error unwinding in C (which comes with an endorsement from CERT recommending its use) and computed goto dispatch tables in threaded interpreters.

Still, you're right that structured control flow statements have obsoleted goto for all but the tiniest edge cases, and so too do I look forward to callbacks suffering a similar fate at the hands of things like await.

The aforementioned CERT guideline:

https://www.securecoding.cert.org/confluence/display/seccode...

Skeptics should note that the real-world example on that page is from the Linux kernel, where this style of goto is used heavily for error handling.

Most definitely. I wish people actually read http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T... to understand why Dijkstra's argument doesn't apply to the cases you describe.

An alternative that can work, unless you need nested loops, would be to just wrap everything in a do {...} while(false), and then call break.

Await kills `done` and `error` callbacks, which are always devoid of concrete meaning in the context of function. Of course it can't—and isn't meant to replace callbacks like `comparator`, `predicate` etc.

Reply on news.ycombinator.com