logoalt Hacker News

pkos98 • today at 7:49 AM • 3 replies • view on HN

Coming from Elixir, I gave Gleam a try for a couple of days over the holidays. Reasons I decided not to pursue:

- No ad-hoc polymorphism (apart from function overloading IIRC) means no standard way of defining how things work. There are not many conventions yet in place so you won’t know if your library supports eg JSON deserialization for its types

- Coupled with a lack of macros, this means you have to implement even most basic functionality like JSON (de)serialization yourself - even for stdlib and most popular libs’ structs

- When looking on how to access the file system, I learned the stdlib does not provide fs access as the API couldn’t be shared between the JS and Erlang targets. The most popular fs package for erlang target didn’t look of high quality at all. Something so basic and important.

- This made me realise that in contrast to elixir which not only runs on the BEAM („Erlang“) but also runs with seamless Erlang interop, Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.

There are many things I liked, like the algebraic data types, the Result and Option types, pattern matching with destructuring. Which made me realize what I really want is Rust. My ways lead to Rust, I guess.

Replies

hayleighdotdev • today at 8:41 AM

> Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.

Gleam has access to the entire ecosystem out of the box, because all languages on the BEAM interoperate with one another. For example, here's a function inside the module for gleam_otp's static supervisor:

    @external(erlang, "supervisor", "start_link")
    fn erlang_start_link(
      module: Atom,
      args: #(ErlangStartFlags, List(ErlangChildSpec)),
    ) -> Result(Pid, Dynamic)
As another example, I chose a package[0] at random that implements bindings to the Elixir package blake2[1].

    @external(erlang, "Elixir.Blake2", "hash2b")
    pub fn hash2b(message m: BitArray, output_size output_size: Int) -> BitArray

    @external(erlang, "Elixir.Blake2", "hash2b")
    pub fn hash2b_secret(
      message m: BitArray,
      output_size output_size: Int,
      secret_key secret_key: BitArray,
    ) -> BitArray
It's ok if you don't vibe with Gleam – no ad-hoc poly and no macros are usually dealbreakers for certain types of developer – but it's wrong to say you can't lean on the wider BEAM ecosystem!

[0]: https://github.com/sisou/nimiq_gleam/blob/main/gblake2/src/g...

[1]: https://hex.pm/packages/blake2

➕ show 1 reply
ngruhn • today at 10:35 AM

I'm a bit torn on ad-hoc polymorphism. You can definitely do cool things with it. But, as others have pointed out, it does reduce type safety:

https://cs-syd.eu/posts/2023-08-25-ad-hoc-polymorphism-erode...

nesarkvechnep • today at 8:28 AM

I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism. The community doesn’t use protocols except “for data”. Whatever that means. Global singleton processes everywhere. I’m really discouraged by the practices I observe but it’s the most enjoyable language for me still.

➕ show 3 replies