Comment by hayleighdotdev
17 hours ago
> 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...
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.
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).
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.
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)
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.
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.
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.
1 reply →