News for hackers. Stuff that matters.

A comment on The Gleam Programming Language. Parent comment

Re:The Gleam Programming Language by hayleighdotdev on Wednesday January 14, 2026 @03:41AM (#46613757)
> 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

[ Parent | on HN ]
Re:The Gleam Programming Language by pkos98 on Wednesday January 14, 2026 @03:48AM (#46613803)
Isn’t this the proof of my point - How does the need of writing „@external“ annotations by hand not contradict the point of being „out of the box“ usable?

Hayleigh, when I asked on the discord about how to solve my JSON problem in order to get structured logging working, you replied that I’m the first one to ask about this.

Now reading this: > 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

Certainly makes me even more feel like gatekeeping.

[ Parent | on HN ]
Re:The Gleam Programming Language by okkdev on Wednesday January 14, 2026 @04:14AM (#46613964)
How does it contradict it? Without any modification/installation you can interop with Erlang/Javascript. How is that not out of the box usability of the Erlang/JS ecosystem? Syntax isn't as seamless as Elixir, but we need a way to tell Gleam what types are being passed around.

Why do you feel like a gatekeeper? Your opinion is valid, it's just that the interop statement was wrong.

[ Parent | on HN ]
Re:The Gleam Programming Language by cmoski on Wednesday January 14, 2026 @05:05AM (#46614267)
Yeah, it's there out of the box but it's certainly not seamless. For an Elixir dev, it is more friction than you're used to. It is the cost of static types.
[ Parent | on HN ]
Re:The Gleam Programming Language by nextaccountic on Wednesday January 14, 2026 @05:05AM (#46614273)
That's FFI bindings. I need to provide the function signature of every API, because Erlang isn't statically typed. It's okay if some library provides it (like the linked , but I don't want to write this by hand if I can avoid it. And it's definitely not out of box, someone has to write the bindings for it to work

It would be different if I didn't have to write bindings and Gleam integrated automatically with foreign APIs. For Erlang that's probably not possible, but for the Javascript ecosystem it could make use of Typescript signatures maybe. (it would be very hard though)

[ Parent | on HN ]
Re:The Gleam Programming Language by widdershins on Wednesday January 14, 2026 @04:46AM (#46614157)
I don't think Hayleigh was trying to gatekeep, just noting that some developers prefer features that Gleam intentionally omits.

As for the @external annotations, I think you're both right to a degree. Perhaps we can all agree to say: Gleam can use most libraries from Erlang/Elixir, but requires some minimal type-annotated FFI bindings to do so (otherwise it couldn't claim to be a type-safe language).

[ Parent | on HN ]
Re:The Gleam Programming Language by lpil on Wednesday January 14, 2026 @06:11AM (#46614706)
This is the same as Elixir, you need to specify what Erlang function to use in that language if you want to use Erlang code. The only difference is that Gleam has a more verbose syntax for it.
[ Parent | on HN ]
Re:The Gleam Programming Language by rkangel on Wednesday January 14, 2026 @09:23AM (#46616369)
In Elixir you just call the Erlang function directly. It's basically the same as calling an Elixir function, just with a different naming convention.

In Gleam, you first have to declare the function type and THEN you can call the function directly.

This is probably the lightest way you can bridge between statically and dynamically typed languages, but it's not the same as Elixir.

[ Parent | on HN ]
Re:The Gleam Programming Language by lpil on Wednesday January 14, 2026 @09:26AM (#46616395)
Sorry, I've been unclear.

The runtime behaviour and cost of calling an Erlang function is the same in Elixir and Gleam, however the syntax is more verbose in Gleam as it asks for type information, while in Elixir this is optional.

[ Parent | on HN ]