The Gleam Programming Language

[pkos98]

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.

[hayleighdotdev]

> 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

[ngruhn]

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]

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.

[smweber]

I’m trying Gleam out right now, and having most recently been writing Go, I’m really loving: - No nil, instead Option and Result - ADTs - Pattern matching + destructuring - Immutable everything by default - `use` syntactic sugar (weird at first, but once you’re used to it it’s pretty elegant) - LSP server works great for such a young language

But most of all I think the overall simplicity of the language is really what’s standing out to me. So far I think the lack of ad-hoc poly and macros are a plus - it really reduces the impulse to write “magical” code, or code with lots of indirections. In the past I’ve definitely been guilty of over-abstracting things, and I’m really trying to keep things as simple as possible now. Though I’ve yet to try Gleam with a large project - maybe I’ll miss the abstractions as project complexity increases.

I suspect Gleam will be a great language for small to medium sized projects written with LLM assistance (NOT vibecoded) - the small language, strong typing and immutability gives good guardrails for LLM-generated code, and encourages a simple, direct style of programming where a human programmer can keep the whole structure in their head. Letting an LLM run free and not understanding what it’s written is I think where projects run into big problems.

[packetlost]

The use <- syntax is even more crazy when you realize that it's a programmer-friendly way of doing continuation-passing style.

[wiskiy]

I am in love with Gleam! As a young computer science student, I found that Gleam brought back the joy of programming just when I felt like I was seriously burning out. I was never a fan of functional programming languages. I had tried other BEAM languages like Elixir and Erlang before, but Gleam is the one I’ve enjoyed the most :)

[replwoacause]

Have you tried F#? That usually gets a lot of praise in FP discussions.

[behnamoh]

I'd rather them stick with ONE: JS or BEAM. Everytime a project claims it can do multiple things at once, it can't do either very well.

It's confusing too. Is Gleam suitable for distributed computing like Elixir/Erlang on BEAM? Would that answer change if I compile it to JS?

[brandonpollack2]

I really like the idea of gleam but I don't want to hand implement serialization for every type (even with an LSP action) in 2026.

[ocean_moist]

Biggest issue with this language. But... fairly trivial to implement codegen with gleam/glance[0]. No good libraries do this well right now (e.g. support for discriminated unions).

[0] https://hexdocs.pm/glance/glance.html

[lawn]

Indeed. Gleam is a sort-of mix between Elixir and Rust, yet you don't have to explicitly implement serialization for either of them.

It's definitely something they should figure out.

[worthless-trash]

I rarely serialise every type in my gleam code, My quick back of the napkin math is less than 5%.

[virtualwhys]

Dart has the same glaring issue (yes, yes, you can use a codegen library but it's not the same).

[tombert]

I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely.

Honestly, and I realize that this might get me a bit of flack here and that’s obviously fine, but I find type systems start losing utility with distributed applications. Ultimately everything being sent over the wire is just bits. The wire doesn’t care about monads or integers or characters or strings or functors, just 1’s and 0’s, and ultimately I feel like imposing a type system can often get in the way more than it helps. There’s so much weirdness and uncertainty associated with stuff going over the wire, and pretty types often don’t really capture that.

I haven’t tried Gleam yet, and I will give it a go, and it’s entirely possible it will change my opinion on this, so I am willing to have my mind changed.

[erlend_sh]

For a fairly advanced example project I can recommend looking at Quickslice, a dev toolkit for making AT protocol applications.

https://tangled.org/slices.network/quickslice

[idoubtit]

For anyone opening the link and wondering why the expected "gleam.toml" is missing: the project contains 2 Gleam sub-projects. The server/ directory is the BEAM server (no framework) and the client/ directory is the gleam-compiled-js client (lustre framework).

Unfortunately, there are many tests for the server, and none for the client.

[heliumtera]

One of the best things about erlang/elixir is the repl driven development/manual testing.

Gleam has no `interpreted` story, right? Something like clojure, common lisp, etc. I think this matters because debugging on beam is not THAT great, there are tools in erlang/elixir to facilitate debugging, like inspect() or dbg().

If anyone has experience in this language, what is the mindset with gleam? How you guys debug?

[__jonas]

> If anyone has experience in this language, what is the mindset with gleam? How you guys debug?

There is the echo keyword now, which is comparable to elixir's dbg(), I use that a lot.

Lacking a REPL, what I normally do is make a dev module, like 'dev/playground.gleam' where I'm testing things out (this is something that the gleam compiler supports, /dev is similar to /test) and then run it with 'gleam run -m playground'.

Sometimes I also use the Erlang shell. You can get an Erlang shell with all the gleam modules from your project loaded in with the 'gleam shell' command. You just need to know the Erlang syntax, and how Gleam modules are named when compiled to Erlang (they use an '@' separator, so gleam/json becomes 'gleam@json').

[lpil]

You can use all the BEAM debuggers and tracing tools, and Gleam has a print debugging keyword.

Unfortunately there is not yet a plugin for the BEAM debuggers for them to use Gleam syntax.

[phplovesong]

Gleam is nice. However it is still very lacking in the stdlib. You will need lots of dependencies to build something usable. I kind of wish Gleam could target something like Go, then you would have the option to go native without a "heavy" VM like the BEAM.

[cmoski]

Surely the BEAM is one of the major selling points.

[lpil]

In a world with package management there’s no practical difference between the core modules being in one package or multiple packages.

[azhenley]

A recent post about using Gleam for Advent of Code:

https://news.ycombinator.com/item?id=46255991

[lxdlam]

I still suspect the effectiveness of plugging in a type system patch to a complete system, like typescript to javascript. We still observe so many `as any` or `as unknown as` at every corner.

Despite of the suspicion, Gleam provides a better and elegant syntax for those who are not familiar with Erlang or functional programming languages, which I loved most.

[giacomocava]

There’s no “unknown” or “any” in Gleam, it’s not possible to cheat the type system that way

[__jonas]

That doesn’t really apply to Gleam, it’s not a type syntax for another language that can be stripped, it’s its own language that compiles to Erlang and JS

[kunley]

One of programming languages with political agenda.

[YorickPeterse]

The type of people complaining about this are usually the people you don't want in your community to begin with, so I doubt Gleam is missing out here.

[lexx]

Since when not being an asshole is a political agenda?

[tkzed49]

human rights are not politics

[KevinMS]

red flag for future drama that might cause problems, one of the reasons I walked away

[lpil]

All open source projects are political by their very nature.

[UnknownUser1234]

Not having a crappy app is my political agenda.

[qwertfisch]

As with many languages that compile to a VM, I always ask myself: that’s all nice, but how do I interact with anything OUTSIDE of my program?

Can I do networking? Can I do system calls to my OS? Display graphics and sound? Can I import a C library that will do all that and call its functions? And if so, how? I just can’t see it from any documentation. Yes, I can call functions from other BEAM-based languages, but then I’m going in circles.

[__jonas]

If you mean specifically on the BEAM (ignoring JS runtimes), the two options are ports and NIFs, both of which unfortunately have their drawbacks.

The Erlang docs on this are here: https://www.erlang.org/doc/system/overview.html

[akanapuli]

I am really interested in whether anyone has evaluated the performance of Gleam? The language is simple, easy to understand, like `Go` for example, but is it really performant like Go, or does it have any performance cost since it runs on top of a VM?

[onlyrealcuzzo]

I'm working on a similar language.

The facts about Gleam:

1. It runs on the BEAM - exceptionally slow compared to Go, but infinitely scalable by default in a way that Go is not - in practice, very rarely matters.

2. They will argue the slowness doesn't matter -> if ~97% of time is spent waiting on I/O -> you can be 10x slower and that means you're only ~30% for typical applications -> it's easier to scale more machines on the BEAM than it is to scale a single machine -> this is true, but largely irrelevant in Go's core market -> it's almost as if Go was built by smart people.

3. The reality is that predictability is much harder to guarantee once you start moving components to different machines. Correct, predictable distributed computing makes correct, predictable concurrent programming look easy.

4. The BEAM does not allow shared memory, Go does (unsafely). There are many cases where the performance impact of this is night and day (why Go ultimately allowed unsafety).

I assume Gleam claims to make this just work. But as someone working in this space, this seems like trying to abstract away the difference between taking a boat to Europe or a plane.

Gleam may be nice if you're building something for the BEAM (massively scalable single app that just makes sense with the actor model, typically chat / telecom).

Though I question why you would use it over Elixir.

Go's syntax kind of blows, but it is so INCREDIBLY good at what it does, that you are not going to beat Go by just having better syntax and being "infinitely scalable" by default.

In practice, Go is easily scalable enough for almost anyone. If it isn't congrats, you're a $10B+ company. You can afford to rearchitect and optimize your hot paths.

[lexx]

Gleam is ready and is amazing. We use gleam as the main language in our company

[Lyngbakr]

What's the product/use case?

[pjmlp]

Glean is interesting from language nerd point of view, however I never had a reason to use Erlang at work, and probably never will, and I suspect that relates to most folks.

[misiek08]

It’s funny how we avoid the technologies we can’t complain about much. Seeing an Elixir projects on production I always wonder „why we are not using it more often”. More talking about Elixir here.

For Elixir I saw a simple distributed job scheduler - it was dead simple in code and was ripped, because it didn’t require maintenance for ~8 years just working without issue and people who knew anything about it left company or switched part of company and acted as they forgot everything.

The other example is medium sized (in terms of features and code) web app - maintained by <30 people now, delivering more than 800 people at the other company, no stress, no issues and with great DX because of the BEAM (other company is drowning in JVM based nano-services).

[gregors]

I suspect you've also had zero reason to use the vast majority of programming languages at work in any meaningful capacity outside of the normal top ones. That's normally how tech decisions work. That certainly doesn't negate the possible benefits of other languages.

Others use Erlang and Elixir quite effectively and successfully in several billion dollar businesses apart from nerd aspects. It will be interesting to me personally if Gleam also has its day in the sun.

[liampulles]

I'm now working on a real world legacy Elixir project in my day job and man oh man do I miss well defined types. Coming from Go, it makes a huge difference to my productivity when I'm able to click through fields and find usages of things, which comes down to the excellence of the Go language server. I know that the Elixir language server can infer some of this, but the language server in my experience is very fickle and flat out doesn't work if you have an older Elixir project.

I'm paying keen attention to Gleam to see if it can provide a robust development experience in this way, in the longer term.

[mercer]

Do the big updates to Elixir's type system help at all? afaik the most recent update added a huge amount of coverage that should extend to older code automatically.

[tekkk]

Well. Coming from TS, Gleam just wasn't/isn't my jam. It's a nice programming language research project, but it just goes against the grain for me a little too much. All the made-up rules early returning always being weird `use` call, the type boilerplate—no inline object types as I remember. Lot of inventions that just makes me go "why?" Like the opposite ideology of Go. And yes I've used Haskell before (didn't like it) and Rust (kinda like it) and others in smaller quantity.

I am more excited about making things rather than fetishizing about some language paradigms so, I acknowledge that Gleam just isn't for me. I did give me the insight that for me, it might be the best to stick with the common denominator languages for the foreseeable future.

[brightball]

Saw a great talk about Gleam last year at the Carolina Code Conference.

https://youtu.be/vyEWc0-kbkw?si=AayavKhhoqO5Mydh

[s_trumpet]

I have worked extensively on Elixir in the past and had a decent enough time, some warts aside. How different is programming in Gleam in the day-to-day apart from type safety?