[HN Gopher] Some thoughts on asynchronous API design in a post-a...
       ___________________________________________________________________
        
       Some thoughts on asynchronous API design in a post-async/await
       world (2016)
        
       Author : acjohnson55
       Score  : 31 points
       Date   : 2021-10-16 20:55 UTC (2 days ago)
        
 (HTM) web link (vorpus.org)
 (TXT) w3m dump (vorpus.org)
        
       | fouric wrote:
       | Can someone explain why the async keyword and the whole "red/blue
       | functions" thing is necessary at all _in the source code_? Why
       | can 't the language implementation see that "await" is used in
       | the body of a function, and automatically mark it as async?
        
         | atarian wrote:
         | I imagine it's not as easy as it looks. Not only do you have to
         | keep track of all the async functions, you need to keep track
         | of the non-async functions that call those async functions,
         | which would likely be a runtime check.
        
         | jerf wrote:
         | In general, it can.
         | 
         | In specific, backporting that onto languages that weren't
         | designed to support that can be very difficult. There aren't
         | very many languages using async/await that were designed that
         | way from the beginning. I'm not sure I can name even one,
         | actually. Many were over a decade old, and that is a lot of
         | code set pretty deep into the concrete before the async/await
         | machinery is installed.
         | 
         | You can look at Erlang, Haskell, and Go as things that just
         | handles the matter internally, between the compiler and the
         | runtime, and erases the color distinction. (Haskell adds back
         | in plenty of color distinctions of its own, it is arguably the
         | leader in "What if we had _dozens_ of  'colors' of functions?"
         | research, but "asynchronicity" is not one of them imposed by
         | the runtime.)
         | 
         | I would certainly encourage any modern language designer
         | starting from scratch to think long and hard before simply
         | blindly porting async/await into their language. Look around at
         | what else has been done first. I consider it an awfully klunky
         | answer. I haven't looked into it personally but I hear Zig has
         | an interesting answer.
        
           | heavyset_go wrote:
           | > _I haven 't looked into it personally but I hear Zig has an
           | interesting answer._
           | 
           | Can you expound on this or share any links about it?
        
         | magicalhippo wrote:
         | I think this is a bit like the dynamic vs static typing
         | discussion that's currently raging in another topic[1].
         | 
         | Being explicitly marked makes it self-documenting. It allows
         | someone to see just the definition to know that it is async.
         | 
         | This is especially useful in conjunction with interfaces (or
         | pure virtual base classes).
         | 
         | In addition there's function pointers to consider.
         | 
         | [1]: https://news.ycombinator.com/item?id=28907154
        
       ___________________________________________________________________
       (page generated 2021-10-18 23:01 UTC)