1. 39

  2. 8

    I liked the bit about the new ? operator. A convincing argument for when something should be turned into a language built-in (in my opinion).

    1. 8

      I’m concerned with how subtle it is. It took me a while to figure out the revised code because I just didn’t see the first ?. I saw the second, but couldn’t figure out how it worked.

      Maybe rust isn’t C, but I’ve never liked control flow macros. I get nervous when I can’t see all the ways out of a function.

      1. 2

        I really like the new operator - but I can understand that people might find it too invisible when glancing at a codebase.

        The big benefit of ? compared to throw of other languages (C++, Java) is that it the underlying concept (Result<T>) forces you to handle the possibility of errors in every layer. Compared to C or Go (both force you to think about adding if err != nil { return err; }).

        So compared to Java/C++ it’s more obvious where errors can happen and compared to C/Go it’s forcing you to handle errors where they happen (just ignoring a Result will result in a compiler warning).

        1. 2

          I’m concerned with how subtle it is.

          But isn’t that the intention? The idea is that it looks like you’d write code almost as if errors don’t exist, while giving the possibility to let errors bubble up. I agree that it hides errors to some extend, but the same is true for checked exceptions or error monads.

          1. 5

            I don’t like exceptions either.

          2. 1

            I share your overall unease with hidden function-exits and would recoil at seeing things like break/continue/goto/return in a macro, but I don’t think all control-flow macros are necessarily bad (e.g. the Linux kernel’s list_for_each or the analogous sys/tree.h traversal macros in BSDland).

          3. [Comment removed by author]

            1. 3

              HKT and do notation has a number of unresolved questions in Rust, ones that might take years to be resolved, if ever.

              The need to make error handling is immediate and affects most Rust users.

              If that ends up being a wart on the language in years, well, at least everyone’s life will be improved between now and then. rust will never be perfect.

              1. 3

                Wouldn’t that require quite large changes to the type system, including higher-kinded types?

                But I agree that it could be more powerful, such that it would also work for e.g. Option…

                1. 1

                  The current implementation might only be the first step. There’s an open RFC discussing the possibility of introducing a new trait that can abstract the handling of the question mark operator. With this, it would be possible to implement it for both Result and Option

                2. 2

                  How could it be more powerful than it is? Please explain, you really got my attention :D

                3. 1

                  At first glance, I really like it. I code mostly backends in Erlang/Elixir. One of the biggest issues of my code is having nested cases (match in Rust or OCaml). Elixir somehow got it solved with the with special form. The RabbitMQ team created Erlando using Erlang’s parse transform (sort of macros) that adds syntax extensions to Erlang, with the do syntax for monads being the most important one to solve somehow this issue.

                  Is there any other way of solving this issue? Is there any other concept that solves this type of problem that is not somehow related to monads?

                  I ask this since the last years it appeared to me that in the end if I don’t have support or tools similar to do notation I keep on reiventing the wheel or non standard tools like Erlando or semi powerful constructs like Elixir with.

                  1. 1

                    I’m looking at the special forms there, and I’m wondering why you need nested matches. It seems like the use case is subsumed by matching on a tuple instead of a single value.