With the new 1.20 release does it change the way you see Gleam?

Not ever starting a flame war either but I don’t see why would I abandon a well-maintained ecosystem like Elixir’s for a new language. I am a sucker for Rust so Gleam I loved trying but of course having to invent much of the goodies in the ecosystem – or waiting for somebody else to do it – was, and likely still is, a deal-breaker.

I am no longer the early adopter type. Plenty of other people to take up the torch.

I wish Gleam – and every stricter language really – best of luck. They really do need it, especially in the age of LLMs.

The gap for me is the type system. Gleam type system is so damn good. Very simpler and catch most of the errors that I usually face, even on languages like Elixir. I do hope that the new type system in Elixir cover this gap.

Curious, what are those errors?

Same for me but with enough discipline and richer linting (I and a few others are working hard on that; well, in fairness, they are working on it and I am regularly re-evaluating really) you can go very far as well.

Still not as happy as I’d be with Rust of course but oh well, what can you do. Elixir is amazing and I am not trading BEAM’s runtime for anything else just yet.

Do you think a mix of Gleam and Elixir is something you’d use. Gleam for the core business logic where the invariants are enforced by the type system, and Elixir for the ecosystem and tighter BEAM integration.

I really like Rust as well, the type system is amazing, but too low level which make things complicated for higher level apps. I undertand why all the complexity is there, but if we youre just doing API and web apps, a GC is totally ok, and actually good to hide all the complexity. I think this is where Gleam shines.
I guess Ill need to wait another year to see all the set theoretic types in place, with things like exhaustive matching, to see how Gleam and Elixir play out.

Mostly not knowing when something is nil or not. For example, Im implementing a system that has a struct where diffferent implementations may not fill all the fields. This is really hard to represent in Elixir. Also individually checking every thing is really bad because it has so many fields and the each implementation may decide to fill a field or not. Its 100% possible to work around that, but not as good as the type system handling it for me.

Likely yes but I have no idea how would that look like. Do you have something in mind?

Though to be honest, my struggles in most of 2026 come from the tragic lack of good specs and docs for my own projects (and those I work on for money) which of course means LLMs mess them up if I don’t continually and incrementally create the specs / docs.

So maybe the stronger typing a la Haskell / OCaml style and their more modern cousins Rust / Gleam is not as big a game changer. I still want them, mind you. So many impossible states can be made non-representable and that by itself is a big win.

But I do wonder if Idris / Coq / Shen (and likely many others) are not where we should invest our time. F.ex. with Shen you can express various invariants with specially notated logic (it also supports Prolog syntax if I have noticed correctly).

So I really don’t know these days. Too much has happened in the last 9-ish months and I am desperately trying to catch up. Open to ideas because for the moment I am only slowly spec’ing my projects to help myself and the LLMs I use keep our eyes on the target.

Pure aside from the Gleam discussion, but this is exactly where multiple structs + protocols fit in for Elixir for me. It’s actually pretty intuitive to represent in Elixir even if you can’t do it via complicated type invariants. One struct per implementation and polymorphic behaviour by protocol, even if all that behaviour is is a validation pass + post-parse conversion into a known good common struct type.