[HN Gopher] Asynchronous Everything (2015)
       ___________________________________________________________________
        
       Asynchronous Everything (2015)
        
       Author : mpweiher
       Score  : 32 points
       Date   : 2021-06-12 11:25 UTC (1 days ago)
        
 (HTM) web link (joeduffyblog.com)
 (TXT) w3m dump (joeduffyblog.com)
        
       | dang wrote:
       | Discussed a bit at the time:
       | 
       |  _Asynchronous Everything_ -
       | https://news.ycombinator.com/item?id=10600573 - Nov 2015 (8
       | comments)
        
       | slver wrote:
       | Async will continue to look awkward until we drop explicit
       | "await" on function calls. Awaiting should be the default. If I
       | call "async foo()" then I get back a promise I can explicitly
       | await, but there should be no semantic difference between calling
       | a synchronous function or asynchronous without modifiers.
       | 
       | Not only it makes it more consistent, but you can implement
       | running a synchronous function into a separate thread just by
       | doing "async foo()". Can't get easier.
       | 
       | Lua already has the right idea here (check coroutines), and why
       | it's so useful in game scripts.
        
         | cube2222 wrote:
         | Agreed. That's basically what Go does.
         | 
         | All functions are async, calling functions does an implicit
         | await, and the _go_ keyword let 's you spawn a task without
         | await. (At least that's what semantically happens) This way you
         | can write seemingly imperative blocking code, and have it work
         | fully asynchronously.
         | 
         | It's great, freeing, and avoids the function coloring problem.
         | It's really the feature I miss most when writing other
         | languages.
         | 
         | Though I do understand why performance oriented languages like
         | Rust might want to approach it differently.
         | 
         | I don't, however, see a reason for non-performance oriented
         | ones to use function coloring (unless they're doing full
         | semicolon customization, like Haskell with its monad stacks).
        
           | amelius wrote:
           | > Though I do understand why performance oriented languages
           | like Rust might want to approach it differently.
           | 
           | The thing Rust gets wrong however, is that there should be a
           | smooth path from ergonomics to performance.
        
           | slver wrote:
           | Performance-oriented languages tend to have a strong type
           | system which lets them know well ahead of time what function
           | is being called, so I see no reason why what you describe
           | can't be done there without performance overhead.
        
       ___________________________________________________________________
       (page generated 2021-06-13 23:01 UTC)