1. 54
  1. 11

    I am a full-time BEAM programmer and the one thing I find myself missing is a really robust type-driven programming approach. I’m so excited for Gleam and I really hope it becomes a major player in the Erlang VM ecosystem!

    1. 1

      I hope so too! Thank you!

    2. 8

      Interesting. I have been having similar thoughts about error handling in my own current language project. Algebraic result types are awesome, but there needs to be a good way to solve the ‘Hadouken Problem’.

      1. 7

        I love the name ‘Hadouken Problem’. I’m going to have to remember that one!

        If you’re interested in some prior art, when designing try we mostly looked at Haskell’s <-, OCaml’s rebindable let*, Scala’s for, Rust’s ?, Swift’s try, Zig’s catch, Elixir’s with, and some of the proposals for error handling in Go 2.

        1. 4

          Why not a more general monad sequencing syntax, like Scala for? The same issue arises with options.

          1. 5

            A great question, thank you.

            Scala’s for is made possible by interfaces, a feature that Gleam does not have. In future we may add some kind of interface-like polymorphism (such as traits) and then we can revisit try.

            Another reason is that Gleam aims to be very simple, predictable, and conventional. Having monomorphic constructs in the langauge encourages users to all write similar code, which makes the language more easier to learn. We value approachability, productivity, and ease of adoption over conciseness or more exciting language features.

            1. 2

              All good reasons, and I applaud restraint in language features and syntax. I haven’t looked in detail at the docs, but presumably adding monadic interfaces similar to Scala’s option would be another way to solve the hadouken problem without new syntax.

              1. 5

                We do have a result.then function in the standard library (which is >>= in Haskell, but specialised to Result). It works nicely but can get quite verbose when depending on multiple previous results, so this syntax is a welcome addition.

                I was lucky enough to be able to test out try with a junior developer and they found it much more understandable than result.then, which I took as a good omen.

          2. 3

            Have you had a chance to look into the way Frank and Unison do algebraic effects and handlers (Unison uses a strange term ‘ability’ for this)? The nice thing is that you can have multiple effects for different error cases, without needing to build up the error conversion machinery that you would need to do in Rust. The plumbing is also done in a more automatic way, without need for an explicit do/try/for*.

            1. 1

              I’ve not no. I did look in a few other places but I wasn’t able to get a good idea of how it worked in practice, so we opted to stick with what was familiar to us (Result/Either).

              Sorry for the slow reply!

          3. 2

            just use goto ;)

            function register()
            {
            	$msg = '';
            
            	if (empty($_POST)) {
            		goto err;
            	} else if (!$_POST['user_name']) {
            		$msg = 'Empty Username'
            		goto err_msg;
            	} else if (!$_POST['user_password_new']) {
            		$msg = 'Empty Password';
            		goto err_msg;
            	} /* etc */
            
            	create_user();
            	$_SESSION['msg'] = 'You are now registered so please login';
            	header('Location: ' . $_SERVER('PHP_SELF']);
            	exit();
            		
            err_msg:
            	$_SESSION['msg'] = $msg;
            err:
            	register_form();
            }
            
            1. 1

              I agree. I’ve spent years using goto-less programming languages of all kinds and interestingly, I use goto rather often when I go back to C. Not only for the error handling pattern illustrated in your example but even for loops sometimes. Quite often, goto really makes sense where you would recurse in a functional programming language.

              1. 1

                Genuinely not the worst solution but I think 52 years after Dijkstra’s missive we can do a bit better :-)

            2. 2

              Great project! :)

              1. 1

                Thank you!

              2. 1

                Why make try a keyword instead of a method on your object type?

                1. 4

                  Thanks for the question! Gleam doesn’t have methods or objects, it is a functional language based on lambda calculus. We did have try implemented as a function in the standard library, this new try sugar takes that established pattern and made it much more ergonomic.

                  1. 2

                    Ah, I see now your response above. That’s more in line with what I was (poorly) trying to ask. It is good to know that it’s not extra required syntax, and available as a function call.