Enhancing Your Elixir Codebase with Gleam | Hacker News Reader

Enhancing Your Elixir Codebase with Gleam

blog.appsignal.com

64 pointscrowdhailer19 comments

Gleam is beautifully designed, but I don't really understand the concept of "use". I've read every article and documentation I could see about it, but it still doesn't "click". Perhaps using another keyword (instead of "use") would work better?

In general, I find "use" a big deviation from Gleam's philosophy. Everything else in the language is well-defined and serves a specific purpose. "use", however, serves several goals, and thus is ambiguous (in the sense that it doesn't have one well-defined definition). [0, 1]

[0]: https://www.reddit.com/r/ProgrammingLanguages/comments/19ctw...

[1]: https://erikarow.land/notes/using-use-gleam

I've been writing an mbox parser with gleam and use is really hard to grok for me. I get the use, but in contrast to nearly everything else in the language, it just isn't clearly composable with other stuff. The moment use is introduced, everything below becomes part of it. It is hard for me to express this, but use feels overloaded with its use-cases in real world.

> The moment use is introduced, everything below becomes part of it. It is hard for me to express this, but use feels overloaded with its use-cases in real world.

Exactly! It's one of the rare ugly parts of Gleam, and I sincerely hope "use" doesn't catch on (it seems like many people find it inconsistent and won't use it anyway).

You can put the use statement inside brackets (i.e. `{ use xyz ... }`) to limit the scope of the use statement.

I fully agree it's unexpected that everything after the use statement becomes part of the body of the use statement.

Erika wrote “Using use in Gleam” in part because I didn’t understand how to use `use`, so I feel at least a little bit qualified to answer this.

I find that `use` is quite effective when needed. This is the part referenced in her article where I find `use` particularly helpful. Something like:

    fn outer() -> Result(success, failure) {
      result.map(parse_id(), fn(id) {
        ... // More code that uses the id
      })
    }

Becomes:

    fn outer() -> Result(success, failure) {
      use id <- result.map(parse_id())
      ... // More code that uses the id
    }

In more concrete terms, I’m building an application with Gleam and Wisp that uses Wisp’s `require_form`. The type signature for `require_form` is:

    pub fn require_form(
      request: Request(Connection),
      next: fn(FormData) -> Response(Body),
    ) -> Response(Body)

But I get to use it like this:

    use form <- wisp.require_form(req)

I’m not sure if I have the appropriate nomenclature here, and I consider myself a beginner of writing strongly typed functional languages, but when I use `use`, I get to invoke the callback with the value on the left side of the arrow.

As Erika so thoughtfully put it:

> The key is to use `use` when it allows you to highlight the happy path of your code … A use expression is syntax sugar, and it’s always possible to write Gleam code without it, though maybe not as clearly.

You can see more here [1] if you want, but note that there are a lot of structural changes in this codebase while I learn and figure out how to best use Gleam and Wisp :)

1. https://github.com/usepriceflow/app/blob/main/src/app/web/ad...

It doesn’t have multiple purposes, it has one: to enable the use of higher order functions without increasing indentation.

Isn't use part of Elixir?

At least I saw it in Elixir in Action, use GenServer or something...

Correct, `use` is a part of Elixir. When you `use` a module like `use FooModule`, it runs the `__using__` macro defined in `FooModule`. Because `__using__` is a macro, it serves as an extension point that allows modules that define it to "inject" code into the modules that `use` it. This injected code could be anything: function definitions, constants, module definitions, etc.

For example:

  defmodule A do
    defmacro __using__(_env) do
      quote do
        defmodule Math do
          def plus_itself(y) do
            y + y
          end
        end
      end
    end
  end

  defmodule B do
    use A
  end

  B.Math.plus_itself(10) |> IO.inspect() #=> 20

More info: https://hexdocs.pm/elixir/alias-require-and-import.html#use

Two quite different things!

Elixir’s use: https://hexdocs.pm/elixir/main/alias-require-and-import.html...

Gleam’s use: https://tour.gleam.run/advanced-features/use/

I don't know how use works in gleam but, at first brush they seem very different. Use in elixir basically allows you to execute a macro callback in the module `use`ing the other module. In gleam it seems to be a tool for chaining function calls (maybe closer to `with` in elixir?).

Yes, Gleam's "use" is similar to "with" in Koka and some other langs. It's really not the same "use" we are used to (pun intended).

I have been using Gleam on the frontend in production, together with Vue[0] and I can confirm it's a joy to use.

Simplicity is such an advantage for a young language.

[0] https://github.com/vleam/vleam

Took a look at the Vite plugin, nice idea! Thanks for sharing

Ah, the joys of having a compatible data model! I think it’s really cool that Gleam and Elixir can interop so well because they’re both running on the BEAM and can share data structures.

I’m curious to see how Elixir’s very recent (still prototypical) type system addition will change the demand for a language like Gleam.

Hi, I’m the lead developer of Gleam.

I don’t think that Elixir’s types and Gleam’s have much in common, they will provide very different experience. Coupled with there not being much crossover from the Elixir community to the Gleam one I don’t think it’ll have much impact on Gleam.

Hi there!

First, let me make it clear: I'm not trying to knock Gleam and it's type system—it's really cool what you've done.

> Not much crossover from the Elixir community

Interesting! I didn't know that. For the die-hard ML-style type system fans (of which I am one) Gleam will absolutely be the most attractive thing on the BEAM block. I think there is a small contingent of developers who would really rather have a type system who might choose Gleam, but that Elixir's new type system (when it matures to support user-supplied annotations and whatnot) might suffice. I think it's an interesting case to see how adding a type system might shift people's preferences between two established languages.

That said, again please don't see this as a knock on Gleam or me trying to say "well now Gleam is obsolete"—I'm not trying to say that. I hope Gleam has an illustrious future. :)

I thought would be the case too originally, but now that Gleam has been known long enough to get an idea for the sort of people who are attracted to it I don't see Elixir getting types having any real impact on Gleam's uptake.

Elixir and Gleam are very different languages offering very different things.

Elixir's type system is still baking(can't define customs types yet), while Gleam's is ready here. Gleam has (familiar to many) battle-tested Hindley-Milner with great type inference, while Elixir's is a different (still sound) set-theoretic one.

But most importantly, Elixir is, and always will be, a gradually typed language. There will always be parts of it that will remain or encourage dynamic typing and that opens the door to ambiguity. In a statically typed language the compiler enforces type annotations and that is where Gleam shines.

Sure sure, I don't disagree with anything you've said. I do think there are some people who would really have some kind of type system than none at all, and for whom the existence of Gleam might be enough for them to stay away from Elixir; with a (gradual) type system though, that might be enough for a few of them to come back. I'm just curious to see how the landscape shifts.

Reply on news.ycombinator.com