I tried Gleam for Advent of Code

> For those that don't know its also built upon OTP, the erlang vm

This isn't correct. It can compile to run on the BEAM: that is the Erlang VM. OTP isn't the Erlang VM; rather, "OTP is set of Erlang libraries and design principles providing middle-ware to develop [concurrent/distributed/fault tolerant] systems."

Gleam itself provides what I believe is a substantial subset of OTP support via a library: https://github.com/gleam-lang/otp

Importantly: "Gleam has its own version of OTP which is type safe, but has a smaller feature set. [vs. Elixir, another BEAM language with OTP support]"

> I fear LLMs have frozen programming language advancement and adoption for anything past 2021.

Why would that be the case? Many models have knowledge cutoffs in this calendar year. Furthermore I’ve found that LLMs are generally pretty good at picking up new (or just obscure) languages as long as you have a few examples. As wide and varied as programming languages are, syntactically and ideologically they can only be so different.

the Erlang vm is called BEAM, not OTP. sadly, Gleam's implementation of OTP is not at the same level as Elixir's or Erlang.

I was also pretty surprised about the performance. It's not C, but it's so much faster than I'd guessed.

I do agree the language server is great. And it works in basically any IDE, which is another huge bonus.

With regards to having to type `list.map`, you actually don't need to! You can do this:

  import gleam/list.{range, map}
  import gleam/int

  pub fn main() {
    range(0,10) |> map(int.to_string) |> echo
  }

Some libraries just aren't there, and I do wonder how hard it would be to port C libraries over. Something I want to play with!

I can live with these negatives. What irritates me the most is the lack of if/else or guards or some kind of dedicated case-distinction on booleans. Pattern matching is great but for booleans it can be kinda verbose. E.g.

   case x < 0 {
     True -> ...
     False -> 
       case x > 10 {
          True -> ...
          False -> 
            case x <= 10 {
               True -> ...
               False -> ...
            }
       }
   }

    case x {
      n if x < 0 -> ...
      n if x > 10 -> ...
      n if x <= 10 -> ...
    }

> Having to type `list.map` instead of `map` or `dict.Dict` instead `Dict` a hundred times does add up over the course of a few weeks, and does not really add a lot of extra readability.

I did it in F# this year and this was my feeling as well. All of the List.map and Seq.filter would have just been better to be called off of the actual list or Seq. Not having the functions attached to the objects really hurts discoverability too.

Re argument formatting, I'd guess it's because it uses the Prettier algorithm which works like that.

However in my experience it's much better than the alternative - e.g. clang-format's default "binpack"ing of arguments (lay them out like prose). That just makes them hard to read and leads to horrible diffs and horrible merge conflicts.

You're right, but loads of times I just left that there because I probably did something more involved in the map that I ended up deleting later without realising.

That is correct.

As a mostly back end dev Elm looked really nice but all the conflict with the creator and then the lack of compiler releases made me shy away a bit.

I have bumped into "the Elm architecture" in other projects though and it was nice.

I recently used Gleam + Lustre for a small app that I normally would have built with Elm + PostgREST. It went very well, and I'm now planning to use it for a larger rewrite (of a rails app).

Go touted it's lack of features as simplicity. And it is: on the language writing side. Go is an incomplete language masquerading as a simple one.

Gleam has always had generics! There’s no Gleam version without them

Perhaps this is a silly question but how do you do functional with no generics? Arent they pretty much required for map/reduce/filter?

I saw your other comment that you meant interface. But an example of a language that went without a feature people thought the language desperately needed was Go with generics. They only added them more than ten years later, when they figured out the best way to implement them.

It might be the same with gleam, with first version in 2019 and 1.0 in 2024. The language authors might think they are either uneeded and lead to anti patterns, or are waiting to see the best way to implement them.

Why does it need generics? There's a great blog post about how you can replace a lot of trait behaviour with just functions. Maybe something like that can be done for generics

    fun sum_all_numbers(Iterable<T> it) { it.fold(...) } # an interface
    sum_all_numbers(a_list) # a list implements iterable

    fun sum_all_numbers(Iterator<T> it) { it.fold(...) } # a concrete type
    sum_all_numbers(a_list.iterator) # get the caller to build the right object

In the medium to long term, if LLMs are unable to easily learn new languages and remap the knowledge they gained from training on different languages, then they will have failed in their mission of becoming a general intelligence.

I feel that was more true 1-2 years ago. These days I find Claude Code write almost as good (or as bad depending on your perspective) Elixir code as JavaScript code and there must be less Elixir code in the training data.

If you just see language as a tool, unless you’re self employed or working in open source, wouldn’t the lack of job market demand for it be the first blocker?

I hope this isn't the future of "new" languages. Hopefully newer AI tools can actually learn a language and they won't be the limiting factor.

Claude reads and writes Gleam just fine. I think as long as the language syntax is well documented (with examples) and has meaningful diagnostics, LLMs can be useful. Gleam has both brilliant docs and diagnostics rivalling Rust. Gleam is also very well designed language wise, not many reserved words, very explicit APIs… also something that helps LLMs.

Contrast with the likes of Swift - been around for years but it’s so bloated and obscure that coding agents (not just humans) have problems using it fully.

On the other hand, if you write a substantial amount of code in a niche languages, the LLMs will pick up your coding style as it's in a sizable chunk of the training corpus.

Its pretty much the same thing as in every previous age, where not having a community of experience and the supporting materials they produce has been a disadvantage to early adopters of a new language, so the people that used it first were people with a particular need that it seemed to address that offset that for them, or that had a particular interest in being in the vanguard.

And those people are the people that develop the body of material that later people (and now LLMs) learn from.

I recently built something in Hare (a very niche new language), and Claude Code was helpful. No where near as good as it is with TypeScript. But it was good enough that I don’t LLMs being in the top 5 reasons a language would fail to get adopted.

Gleam isn’t a very unique language. The loss from generalizing may be less than the improved ergonomics, if not now then as LLMs improve.

This was one of my bigger worries for LLM coding: we might develop path dependence on the largest tools and languages.

Of course there is, especially if you believe that LLMs further improve on reasoning.

claude is really good at elixir. IME, It's really really good with a few "unofficial" tweaks to the language/frameworks, but this could be my bias. the LLM cutoff was a fear of mine, but i think it's actually the opposite. we know that as few as 250 documents can "poison" an LLM, i suspect that (for now) a small language with very higg quality examples can "poison" LLMs for the better.

Seems like you are not target audience for these new languages and that is OK. But I guess there are still many people that want to try new things (on their own even).

Yes, because LLMs don't change the fact that different programming languages have different expressive capabilities. It's easier to say some things in some languages over others. That doesn't change if it's an LLM writing the code; LLMs have finite context windows and limited attention. If you can express an algorithm in 3000 loc in one language but 30 loc in another, the more expressive language is still preferred, even if the LLM can spit out the 3000 lines in 1s. The reason being if the resulting codebase is 10 - 100x larger than it needs to be, that has real costs that are not mitigated by LLMs or agents. All things being equal, you'd still prefer the right tool for the job, which does not imply we should use Python for everything because it dominates the training set, it means we should make sure LLMs have capabilities to write other programming languages equally well before we rely on them too much.

where do you think the corpus of training data comes from?

The answer I’ve seen is “just pass structs of functions around”, which is just one step more explicit than the implicit version we’re all use to, but honestly I kinda like it to free ourselves of all the ceremony around generics.

Gleam has first class functions, so it has dynamic dispatch.

Both of type classes and interfaces desugar to high order functions, so anything you write with them can be written with first class functions, though with a less concise API.

Thank you! I have not played around with Elixir just yet, sadly, so I can't help there, I'm afraid.

[deleted]

I actually agree. I don’t even use them in my private code. I will look into removing them from my blog!

  document.body.style.setProperty('font-variant-ligatures','none','important');

[dead]