[HN Gopher] Std: Execution, Sender/Receiver, and the Continuatio...
       ___________________________________________________________________
        
       Std: Execution, Sender/Receiver, and the Continuation Monad
        
       Author : ingve
       Score  : 26 points
       Date   : 2021-10-17 08:20 UTC (1 days ago)
        
 (HTM) web link (sdowney.org)
 (TXT) w3m dump (sdowney.org)
        
       | gpderetta wrote:
       | As a background the C++ committee decided not to merge the
       | network TS (i.e. ASIO) and instead focus on the sender/receiver
       | proposal. This has been contentious to say the least as ASIO is
       | industry proven while the sender/receiver is more greenfield.
       | 
       | Sender/receiver is also quite complex (although ASIO is not
       | exactly simple) and most likely not ready for C++23, which means
       | that C++ won't have networking for at least 6 more years.
       | 
       | Personally I don't have a strong opinion either way, I like both
       | ASIO and S/R (and have reimplemented significant chunks of both).
       | I think the proposals are not mutually exclusive: ASIO should
       | have been merged now and S/R added at a later time when ready.
       | S/R will need a scheduler anyway and might as well be ASIO.
        
       | sxp wrote:
       | Can anyone recommend a good guide to monads for people with a
       | C/assembly background? I've always had trouble understanding
       | functional programming topics until I could figure out how to
       | implement them in C use a basic struct + function design. I still
       | haven't found a good description of monads and I don't want to
       | spend time learning Haskell so every time I read about monads, I
       | try to understand them and give up after I find the guides
       | uninformative.
        
         | orangea wrote:
         | I think if you don't have the time to learn enough about a
         | language like Haskell to understand how monads work in that
         | language then you are probably better off just not trying to
         | understand them. It is impossible to understand them without
         | having examples.
        
         | JoelMcCracken wrote:
         | https://news.ycombinator.com/item?id=28765401
         | 
         | TL;DR is its a design pattern. You wont really notice the value
         | of them until you see how they solve the same thing over and
         | over again, such as return value checking hell in c (check the
         | second link)
         | 
         | But anyway my advice is to just ignore it; you'll really need
         | to spend some time in e.g. haskell or something else in order
         | to get familiar with them enough to fully grok them
        
           | fezzez wrote:
           | Agree. The best way I can describe it, is that it's a design
           | pattern for a lightweight runtime.
           | 
           | You can use monads to implement exception handling, global
           | state (without actually having global state), and
           | async/await.
           | 
           | It's difficult to explain how all those features can be
           | implemented through one generic interface. But it's easy to
           | see how each of those things would require a "lightweight"
           | runtime.
        
         | corysama wrote:
         | https://www.reddit.com/r/math/comments/ap25mr/a_monad_is_a_m...
        
         | brobdingnagians wrote:
         | It finally clicked for me after reading the chapter [1] in
         | "Functional Programming in C++" [2] on monads; partly because
         | he gives lots of examples in C++ and reasons why they are
         | useful. I've read a few other things too, so I'm not sure if it
         | was the sum totality of all of them, but that book helped. That
         | does require being familiar with C++, but that is probably the
         | closest to C where monads can be clearly modelled and, as
         | others have noted, it is easier to understand the concepts in a
         | language where they can be more concisely modelled.
         | 
         | [1] https://livebook.manning.com/book/functional-programming-
         | in-...
         | 
         | [2] https://www.manning.com/books/functional-programming-in-c-
         | pl...
        
         | chas wrote:
         | Monads are a very different sort of abstraction than the kind
         | that are used most of the time in C programming. In particular,
         | they were originally developed in abstract algebra. Algebraic
         | abstractions are super nice and useful for programming, but
         | really the most accessible way to learn how to use them is to
         | learn Haskell. The way the language is set up makes algebraic
         | abstractions very ergonomic to use and as such, the Haskell
         | world is the most concentrated set of folks thinking
         | algebraically about programming. If you are interested in
         | understanding why monads come up so much and how the
         | abstraction works, learning enough Haskell to write non-trivial
         | programs is the most approachable path.
         | 
         | If you are dead set on learning about monads without learning
         | Haskell (or a related typed functional language), I would focus
         | on understanding Haskell-style functors and then applicative
         | functors because they are simpler than monads, but they are
         | deeply-related algebraic building blocks that are useful
         | abstractions in their own right. When you are comfortable
         | programming with them, monads shouldn't be much of a leap.
        
       | rektide wrote:
       | Some invaluable background information explaining the
       | std::execution in the start. I had no idea. Great write-up. Fun
       | hearing how platforms go about trying to add async.
        
       ___________________________________________________________________
       (page generated 2021-10-18 23:01 UTC)