1. 48
  1.  

  2. 10

    I love the look of these error messages. As someone who doesn’t use Erlang ecosystem at all, I’m interested in trying this language out because these look so inviting! Great work.

    1. 2

      Thank you for your support! :)

    2. 5

      Really like the import cycle message! Reminds me of the one in Elm’s compiler!

      1. 2

        It was a direct inspiration :)

      2. 3

        I really dislike this visually noisy style of error message. It makes things much harder to scan visually through a list of them, and forces my eyes to seek around for the useful bit of information.

        I understand that it’s trying to be helpful, but a clear, well phrased error with all the involved locations is more useful to me. Especially since I am already looking at the code in my editor.

        1. 11

          So far the feedback has been the inverse, and there’s a more general trend to more verbose error messages (Elm, Haskell, Rust, OCaml, etc) so I feel confident in having this style by default

          I would be open to having a more conventional and concise style for errors behind a flag, and I intend to have a suitable LSP error format that works well in editors.

          If you’ve any specific suggestions please do open an issue on GitHub! Thank you

          1. 3

            Yeah, codespan at least has a short diagnostic mode - I think we can do work to improve it though! Been doing a bunch of work on codespan recently after having attempted to use annotate-snippets-rs - hopefully Gleam will eventually be able to take advantage of it!

            1. 2

              Thanks for all your work, it’s really a great library. I also tried annotate-snippeta-rs but decided codespan was much more to my liking.

        2. 2

          It’s the first time I hear about Gleam. After working with Elm for a bit, Gleam’s syntax reads like a joy. But I couldn’t find the high-level goals of the language (not that I’m against a new one). What is it meant for and how it’s different from e.g. Elixir?

          1. 2

            We have some guiding ideas here: https://gleam.run/#principles

            The language aims to fill a similar niche to Elixir. We wish to make a friendly productivity oriented language primarily for making networked services that scale. The main difference is the focus for how this productivity is to be achieved: Elixir focuses on metaprogramming, Gleam focuses on having a robust static type system.

            The aim is for Gleam to live alongside Elixir, and to hopefully make the ecosystem richer as a whole.