[HN Gopher] Extending Rust's Effect System
       ___________________________________________________________________
        
       Extending Rust's Effect System
        
       Author : egnehots
       Score  : 85 points
       Date   : 2024-02-10 08:51 UTC (14 hours ago)
        
 (HTM) web link (blog.yoshuawuyts.com)
 (TXT) w3m dump (blog.yoshuawuyts.com)
        
       | mbStavola wrote:
       | I think there is a lot of value in exploring this idea, even
       | though it's a "big idea." Rust already has a history of taking
       | PLT ideas system programmers don't care about and making it
       | practical _and_ appealing. This could be another one of those
       | things where the effort pays off many fold and we all wonder why
       | other languages don 't do this. It could be as important as
       | generics, traits, or even lifetimes, who knows!
       | 
       | That said, it _is_ incredibly complex and a lot to grok. It 's a
       | completely alien concept to most programmers and there is still
       | some confusion over what this feature even entails. As many
       | people have said, it's questionable if you could truly unify some
       | of these "effects" in a way that is useful or even coherent; you
       | might have a sync and async version of a function that ostensibly
       | does the same thing, but the implementation details could diverge
       | a lot to the point where you might as well have just written two
       | different functions. This sort of feature really needs an
       | exploration of what it would look like in practice for existing,
       | popular APIs, and not just toy examples.
       | 
       | I really am looking forward to the full RFC with the hopes that
       | they nail the sweet spot here and we end up getting a nice effect
       | system that helps me write beautiful, correct, and performant
       | APIs (more so than I can already do today). At the same time, I
       | also want one of the "correct" outcomes of the RFC to be "let's
       | not do this at all." I worry with the amount of excitement and
       | promotion this initiative has that this may end up being adopted
       | by default. I really have no basis for thinking that, but I do
       | keep seeing this pop up and a lot of people have valid questions
       | and concerns that just go unanswered.
        
       | carterschonwald wrote:
       | Basically rust needs to be able to express generics that have the
       | interface popularly known at monads.
        
         | zozbot234 wrote:
         | Effect types as currently understood are closer to Lawvere
         | theories than monads. The biggest difference is that the former
         | can be composed out-of-the-box with no ambiguity, whereas you
         | can't really compose monads without resorting to a clunky
         | "transformers" pattern.
        
           | carterschonwald wrote:
           | That's been clearly disproven for like a decade... you just
           | need to have your effect monad structure be indexed by the
           | set of symbols in question! Especially since the effects are
           | baked into the language. The transformers formulation is only
           | relevant for userland defined semantics!
           | 
           | It doesn't matter if the monadic structure is there in user
           | syntax, it's there in the semantics.
        
             | Rusky wrote:
             | Pretty important distinction when you're specifically
             | talking about the interface being expressed in the
             | language.
        
               | carterschonwald wrote:
               | Actually less than you'd think! Granted I've been
               | tinkering with ways to let users choose how much they
               | wanna see fancy info vs let a compiler do the book
               | keeping. Keeping track of this info in the compiler ir is
               | trivial
        
               | Rusky wrote:
               | What I mean is, merely plopping a Monad trait into Rust
               | and implementing everything in userspace is famously not
               | an effective implementation approach, so your phrasing is
               | bound to confuse people when you are instead referring to
               | the semantics.
        
       | IshKebab wrote:
       | > Not being able to use ? inside of arbitrary closures is an
       | example of an effect mismatch.
       | 
       | Yes! This is probably the most annoying thing about Rust in day
       | to day use IMO. You can work around it but it's always a pain.
        
       | pavlov wrote:
       | The structure of this article makes it unreadable if you don't
       | already know what effects mean in this context.
       | 
       | The introduction promises that the talk will explain what effects
       | are. Finally, some 75% in, after discussing topics like "what
       | happens when we can't be generic over effects", it does get
       | around to answering the question of what effects actually are.
       | But the answer is rather unsatisfying if you don't know these
       | definitions already. For example:
       | 
       | "A lot of languages which have effects provide both effect types
       | and effect handlers. These can be used together, but they are in
       | fact distinct features. In this talk we'll only be discussing
       | effect types."
       | 
       | This doesn't really clarify much.
        
       ___________________________________________________________________
       (page generated 2024-02-10 23:00 UTC)