- 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.

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.

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?

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.

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

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?

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

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.

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.

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

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

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.

  import gleam/io

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

  say “hello, friend!”

  #!/usr/bin/env raku

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