4 ms·
Chapter 15 of the 2007 release of "Programming Languages: Application and Interpretation" gives a really good motivation for the async/await syntax. Here is a l
by tyleo 2y ago
Chapter 15 of the 2007 release of "Programming Languages: Application and Interpretation" gives a really good motivation for the async/await syntax. Here is a link: https://cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/plai-2007-04-26.pdf https://cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-0...
> I would prefer an approach where calls to "async" functions are implicitly awaited unless a keyword turns then into a promise, and all functions are implictly treated as async as needed, unless a keyword specifies that they return a promise, which should be awaited instead. This would make the majority case clearer, and force you to make the minority case explicit where it's currently implicit.
This is a very interesting idea and feels good in an initial 'gut check' sense.
- shivawu 2y agoThis is I believe how ziglang works on its asynchronous story
- felixfbecker 2y agoThat's basically how goroutines work in Go. You opt into concurrency with the `go` keyword, while it's blocking by default. While in JS it's concurrent by default and you opt-in to blocking with the `await` keyword. (Except in Go you have true parallelism for CPU-bound tasks too, while in JS it's only for I/O) Both have their pros and cons. I've seen problems in Go codebases where some I/O operation blocks the main thread because it's not obvious through the stack that something _should_ best be run concurrently and it's easy to ignore until it gets worse (at which point it's annoying to debug).