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.

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.

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 :)

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?

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.

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.

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

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?

A recent post about using Gleam for Advent of Code:

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

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.

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.

One of programming languages with political agenda.

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.

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

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.

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.

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?

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.

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

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

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?

I think they have an issue on homepage: there is no "download/get start" link. All big buttons link to a tour page, and stopped there.

I've always thought this would be an excellent language for coding agents.

thought I’d try the showcase example in Raku (https://raku.org), so this Gleam

  import gleam/io

  pub fn main() {
    io.println("hello, friend!")
  }

becomes this Raku

  say “hello, friend!”

well maybe you really want to have a main() so you can pass in name from the command line

  #!/usr/bin/env raku

  sub MAIN($name) {
    say "hello, $name!”
  }

[dead]

Now here's a type-safe functional programming language I recently bumped into, which with their focus on simplicity, ease of use, and developer experience, and compiling to either Erlang or Javascript, is really tempting to delve in deeper.