[HN Gopher] A lowering strategy for control effects in Rust
       ___________________________________________________________________
        
       A lowering strategy for control effects in Rust
        
       Author : todsacerdoti
       Score  : 42 points
       Date   : 2024-01-15 20:38 UTC (2 hours ago)
        
 (HTM) web link (www.abubalay.com)
 (TXT) w3m dump (www.abubalay.com)
        
       | the_duke wrote:
       | Very interesting analysis.
       | 
       | I'm fascinated with effect systems.
       | 
       | In theory they have the potential to make code both simpler and
       | more powerful, because many complex abstractions like generators,
       | async/await, error propagation, injected context, etc can all be
       | built on a simple extensible language primitive.
       | 
       | The by far nicest implementation I've seen is Koka lang [1].
       | Unfortunately it's bound to be a small research language.
       | 
       | In practice I do wonder though if that much power won't make code
       | very confusing to read and write, and if the general programmer
       | should be trusted with that much flexibility.
       | 
       | For Rust specifically, I do wonder how generic effects could slot
       | into a language that was not designed for them upfront, without
       | compromising the design and DX.
       | 
       | [1] https://koka-lang.github.io/koka/doc/index.html
        
         | sp33der89 wrote:
         | Yeah, the learning curve is there, but it has its benefits for
         | software development.
         | 
         | Personally I really am enjoying the one implemented by Unison:
         | https://www.unison-lang.org/docs/fundamentals/abilities/usin...
         | 
         | But Koka's was fun to play around with as well!
        
         | bruce343434 wrote:
         | What about a more imperative shape? What if you could have a
         | closure that "goto"s into the parent function scope?
         | 
         | Or imagine coroutines built with `swapcontext` (man 3).
        
           | zozbot234 wrote:
           | Stackful fibers are an anti-pattern. See Gor Nishanov's
           | review for the C++ ISO committee http://www.open-
           | std.org/JTC1/SC22/WG21/docs/papers/2018/p136... linked from h
           | ttps://devblogs.microsoft.com/oldnewthing/20191011-00/?p=10..
           | . . Notice how it sums things up:
           | 
           | > _DO NOT USE FIBERS!_
        
             | gpderetta wrote:
             | Let's say that not everybody agrees. Also all the issues
             | identified by Gor are due to retrofitting continuations
             | into an existing language as a pure library without
             | compiler help.
        
         | atoav wrote:
         | On the very far end of the spectrum you will have something
         | that may look a bit like mathematical notation. Something
         | describing a relationship extremely concisely, but the hard
         | thing will be figuring out what exactly follows from that
         | concise expression.
         | 
         | I can understand how people could see the appeal in this, but I
         | think this doesn't necessarily make it easier to write good
         | software.
        
         | jacquesm wrote:
         | You see something similar with CL and Clojure (but the latter
         | to a lesser extent): these abstractions are so powerful that
         | those that grok them are able to construct things that others
         | have little chance of understanding without a significant
         | investment in time (if at all). Go does more or less the
         | opposite: it tries to avoid any kind of cleverness.
        
           | closeparen wrote:
           | There's no fundamental objection to requiring people to
           | master difficult concepts in programming: see the ubiquity of
           | the LeetCode Hard interview. Why then is this such a barrier
           | to the adoption of functional programming and sophisticated
           | type systems?
        
         | zozbot234 wrote:
         | > In practice I do wonder though if that much power won't make
         | code very confusing to read and write, and if the general
         | programmer should be trusted with that much flexibility.
         | 
         | This is not for ordinary code, it's for writing support
         | libraries and DSL's. You need this stuff so that the "general
         | programmer" can write code that's as straightforward as
         | possible in its proper context.
        
       | valcron1000 wrote:
       | > Rust should learn from this work and skip the layering. As
       | someone who uses Haskell professionally, 100% agree. Monad
       | transformers are an (unfortunate) solution to the problem of
       | stacking effects, not only due to the required lifting (to pick
       | the appropriate handler), but due to the lack of compositionality
       | and rough UX for the developer. Algebraic effect libraries are a
       | lot easier to use (but I cannot speak for how easy/hard are to
       | implement).
        
       ___________________________________________________________________
       (page generated 2024-01-15 23:00 UTC)