I've also been wanting to make Gleam my primary language (am generally a Typescript dev), and I have not had any issue with using it with LLMs (caveat, I'm obviously still new with it, so might just be ignorant).
In fact, I'd say most of the Gleam code that has been generated has been surprisingly reliable and easy to reason about. I suspect this has to do with the static typing, incredible language tooling, and small surface area of the language.
I literally just copy the docs from https://tour.gleam.run/everything/ into a local MD file and let it run. Packages are also well documented, and Claude has had no issue looping with tests/type checking.
In the past month I've built the following, all primarily with Claude writing the Gleam parts:
- A realtime holiday celebration app for my team where Gleam manages presence, cursor state, emojis, and guestbook writes (still rough): https://github.com/devdumpling/snowglobe
- A private autobattler game backend built for the web
While it's obviously not as well-trodden as building in typescript or Go or Rust, I've been really happy with the results as someone not super familiar with the BEAM/Erlang.
EDIT: Sorry I don't have demos up for these yet. Wasn't really ready to share them but felt relevant to this thread.
> 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.
There's a flywheel where programmers choose languages that LLMs already understand, but LLMs can only learn languages that programmers write a sufficient amount of code in.
Because LLMs make it that much faster to develop software, any potential advantage you may get from adopting a very niche language is overshadowed by the fact that you can't use it with an LLM. This makes it that much harder for your new language to gain traction. If your new language doesn't gain enough traction, it'll never end up in LLM datasets, so programmers are never going to pick it up.
Pure anecdote. Over the last year I've taken the opportunity to compare app development in Swift (+ SwiftUI and SwiftData) for iOS with React Native via Expo. I used Cursor with both OpenAI and Anthropic models. The difference was stark. With Swift the pace of development was painfully slow with confused outputs and frequent hallucinations. With React and Expo the AI was able to generate from the first few short prompts what it took me a month to produce with Swift. AI in development is all about force multipliers, speed of delivery, and driving down cost per product iteration. IMO There is absolutely no reason to choose languages, frameworks, or ecosystems with weaker open corpuses.
> 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."
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]"
The comment you are replying to is correct, and you are incorrect.
All OTP APIs are usable as normal within Gleam, the language is designed with it in mind, and there’s an additional set of Gleam specific additions to OTP (which you have linked there).
Gleam does not have access to only a subset of OTP, and it does not have its own distinct OTP inspired OTP. It uses the OTP framework.
I don’t mean to minimize the huge effort by the Gleam team; however, Elixir cannot become Gleam without breaking OTP/BEAM in the same ways Gleam does. As it stands now, Elixir is the superior language between the two, if using the full Erlang VM is your goal.
i just implemented a project in elixir with LLM support and would never have considered that before. (i had never used elixir before) - So who knows maybe it will help adoption?
Gleam is really quite a nice language. I did AoC in it this year as well and came away with the following: (incomplete list for both positive and negative, these are mainly things that come to mind immediately)
Positive:
- It can be pretty performant if you do it right. For example, with some thought I got many days down to double digit microseconds. That said, you do need to be careful how you write it and many patterns that work well in other languages fall flat in Gleam.
- The language server is incredibly good. It autoformats, autocompletes even with functions from not-yet-imported-but-known-to-the-compiler packages, shows hints with regarding to code style and can autofix many of these, autofills missing patterns in pattern matches, automatically imports new packages when you start using them and much much more. It has definitely redefined my view of what an LSP can do for a language.
- The language is generally a joy to work with. The core team has put a lot of effort into devex and it shows. The pipe operator is nice as always, the type system is no haskell but is expressive enough, and in general it has a lot of well-thought out interactions that you only notice after using it for a while.
Negative:
- The autoformatter can be a bit overly aggressive in rewriting (for example) a single line function call with many arguments to a function call with each argument on a different line. I get that not using "too much" horizontal space is important, but using up all my vertical space instead is not always better.
- The language (on purpose) focuses a lot on simplicity over terseness, but sometimes it gets a little bit much. 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. OTOH, I have also seen people who really really like this part of Gleam so YMMV.
- Sometimes the libraries are a bit lacking. There are no matrix libraries as far as I could find. One memoisation library had a mid-AoC update to fix it after the v1.0 release had broken it but nobody noticed for months. The maintainer did push out a fix within a day of realizing it was broken though. The ones that exist and are maintained are great though.
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 -> ...
}
}
}
> - It can be pretty performant if you do it right. For example, with some thought I got many days down to double digit microseconds.
Was this the time of everything or just the time of your code after loading in the text file etc.?
The hello world starter takes around 110 ms to run on my PC via the script generated with `gleam export erlang-shipment` and 190 ms with `gleam run`.
Is there a way to make this faster, or is the startup time an inherent limitation of Gleam/the BEAM VM?
The time reported by the "gladvent" package when running with the "--timed" option. AFAICT that does not count compilation (if needed), VM startup time, any JITting happening, or reading in the text file. I'm fine with that tbh, I'm more interested in the time actually spent solving the problem. For other languages I wouldn't count language-specific time like compilation time either.
As to whether you can make startup time faster, I suppose you could keep a BEAM running at all times and have your CLI tools hotswap in some code, run it, and get the results back out or something. That way you can skip VM startup time. Since the BEAM is targeted more at very long-running (server) processes with heaps and heaps of concurrency, I don't think ultrafast startup time is really a focus of it.
> 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.
I like Gleam, but I am somewhat annoyed by the fact, that I don't have the full functional freedom in calling recursive (inner) functions wherever I want. I don't know, why new functional languages do not get this right all the way, straight from some rnrs document or implementation. Another thing is the separate operators like .> and .< and so on. What I liked were of course pipes and pattern matching.
To me it felt less elegant than Scheme (GNU Guile) which I usually use (with nice parallelism if I want to, pipelines, and also pattern matching), and, aside from syntax, conceptually perhaps less elegant than Erlang. On the other hand it has static typing.
I also tried OCaml this year, but there are issues in the ecosystem making a truly reproducible environment/setup, because opam doesn't produce proper lock files (only version numbers) and it seemed silly to not be able to even include another file, without reaching for dune, or having to specify every single file/module on command line for the OCaml compiler. So I was left unsatisfied, even though the language is elegant and I like its ML-ness. I wish there was a large ecosystem around SML, but oh well ...
Might be I should take another look at Erlang soon, or just finally get started with Haskell. Erlang using rebar3 should have proper lock files, has pattern matching, and if I remember correctly no such limitations for calling functions recursively. No longer sure how or whether Erlang did inner functions though.
Heh, similar thoughts! The main difference that I only used Scheme for SICP, and I've used a bit of Haskell.
I like Haskell in theory, but: just to get a hello world takes a lot of CPU and disk space. The standard library is full of exceptions (you can use a different prelude, that opens a whole different can of worms). The ergonomics of converting between the thousand different string types are awful.
So, you being basically me, I have some recommendations:
Idris (2): good stdlib, has dependent types. A beautiful language. The compiler is self-hosted and bootstrapped by lisp - very elegant! The ecosystem is basically nonexistent though.
PureScript: also improves on Haskell in many ways. But, it's more of a frontend language, and though you can do backend, you're stuck with JavaScript runtime. Oh well.
It seems like it should be a common feature to be able to view between each array operation in a debugger without having to augment the code with `echo`
The out of bounds handling didn't seem all that good to me. Sure you can filter out undefined. You could also just make a function that returns an empty array if out of bounds, or array of 1 element if not.
// JS
function getElemFromGrid(grid, x, y) {
return (x < 0 || x >= grid.width ||
y < 0 || y >= grid.height)
? []
: [grid.elems[y][x]]
}
...
neighbors = [
...getElemFromGrid(grid, x + 1, y + 0),
...getElemFromGrid(grid, x + 1, y + 1),
...getElemFromGrid(grid, x + 0, y + 1),
...getElemFromGrid(grid, x - 1, y + 1),
...getElemFromGrid(grid, x - 1, y + 0),
...getElemFromGrid(grid, x - 1, y - 1),
...getElemFromGrid(grid, x + 0, y - 1),
...getElemFromGrid(grid, x + 1, y - 1),
]
I also find grids made of 2 dimensional array to be code small. An array of arrays is NOT A GRID as there is nothing enforcing the inner arrays to be the same length as each other. Also, in efficienct code it would be better to provide a 1 dimensional array and bounds. Now, out of bounds checks based on accessing outside the array won't work. You need to check actual bounds. Again giving preference using a helper
I haven't explored the BEAM ecosystem much. And this post actually got me motivated enough to try it out.
The more programming languages we play with, the better we become as engineers. We learn the different design decisions that go into each language. And we learn the language of Computer Science itself.
Plus, Advent of Code!
So I finally got everything installed. But then I realized there are no easily accessible offline docs. I don't have Internet service at home. So I have to grab service when I can make it out.
So it looks like mix can download offline hexdocs, but I don't have elixir installed. And there's a hexdocs_offline dev package for Gleam. But it errors out on "gleam/dynamic does not have a 'from' value.
Maybe it's a "teaching moment" about the basics of the language. But I have to run out to another appointment now, so these teaching moments don't always help.
Anyways, I guess I'll dive in after the holidays and just wget the tour or get some well regarded projects for reference. I'm actually still really excited with all the functional features.
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.
This sounds like the kind of situation where the LSP could suggest the simpler code, I'll see if there's an issue for it already and suggest it if not.
Not many people use elm directly but it has influenced the design of so many frameworks and libraries.
Right now I’m toying with the idea of building a GNOME application in rust, and the framework I’m using is relm4 which provides elm like abstractions over gtk-rs.
Previously I’ve built web applications with F# and elmish, which again provides elm like abstractions for building F# applications.
Just so no one misunderstands this. The creator (Evan) didn't get into, or start, any drama himself that I ever noticed. I'd argue he's a very chill and nice dude.
I've been on the edges of the community for probably a decade now (lurker), and all of the drama came from other people who simply didn't like the BDFL and slow releases strategy.
Yeah I'm not a front end dev but I do kind of keep track of what's going on in that space. From what I saw it seemed Elm was all but dead. Maybe that's not true, but that was the impression from the outside looking in.
I'm a backend dev mostly and use Elm for all my frontend needs. Yes there are some things compiler-side that could be improved, but basically it's fine.
I appreciate not having to keep up with new releases!
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).
I've considered playing around with it. Every now and then I tell myself I'm gonna learn front end dev, but as soon as I start looking at it (FE in general not Lustre specifically) I get depressed and give up lol
I looked at lustre for a recent project and it seems very nice. But the ecosystem is pretty small yet (I could find no examples of auth, for one), so I ended up going with liveview.
I'm hoping it succeeds and gets bigger because I really like its ergonomics.
One thing im wondering with the LLM age we seem to be entering: is there value in picking up a language like this if theres not going to be a corpus of training data for an LLM to learn from? Id like to invest the time to learn Gleam, but I treat a language as a tool, or a means to an end. I feel like more and more I'm reaching for the tool to get the job done most easily, which are languages that LLMs seem to gel with.
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.
I personally find it much more painful to generate valid Rust code that compiles and does what I want than e.g. valid python code that runs and does what I want.
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.
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?
If you're fortunate, you can find companies with a passion for good code who use lesser-known languages. Picking Erlang, or Haskell, or OCaml generally filters out candidates who don't share your interest in seeing what can be done outside the mainstream.
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.
I’m more interested in what happens when a language is designed specifically for llms? When doing vibe coding a lot of code is a lot more verbose than I’d do normally. Do we drop down the abstraction level because llms are just so good a churning out boilerplate?
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.
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).
I have similar concerns to you - how well a language works with LLMs is indeed an issue we have to consider. But why do you assume that it's the volume of training data that drives this advantage? Another assumption, equally if not more valid IMO, is that languages which have fewer, well-defined, simpler constructs are easier for LLMs to generate.
Languages with sprawling complexity, where edge cases dominate dev time, all but require PBs of training data to be feasible.
Languages that are simple (objectively), with a solid unwavering mental model, can match LLMs strengths - and completely leap-frog the competition in accurate code gen.
I don't know Gleam at all so I can't comment on that specifically, but I think everyone has the experience of a coworker who writes C++ as if it's C or Python as if its Java or whatever else.
A language doesn't have to be unique to still have a particular taste associated with its patterns and idioms, and it would unfortunate if LLM influence had the effect of suppressing the ability for that new style to develop.
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.
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.
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.
the flip side of that, right now ai coding agents try to generate code, not software.
it seems semi intuitive to me that a typesafe, functional programming language with referential transparency would be ideal if you could decompose a program to small components and code those.
once you have a referentially transparent function with input/out tests you can spin on that forever until its solved and then be sure that it works.
I've looked at Gleam before but it didn't seem to have any mechanism for dynamic dispatch like interfaces or type classes. Did it change in the meantime?
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.
It’s discouraged to pass around structs of functions to replicate type classes in Gleam. Instead the preference is to not type class style patterns in your projects, favouring a concrete style instead.
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.
Something I really hope Gleam figures out is a way to streamline the Elm architecture. We see the Elm architecture mostly in web apps, but I think that model is a really good idea for a lot of applications!
But I think two things really hold it back:
* it's verbose.
* they compose awkwardly.
Neither of these are showstoppers, but I think fixing these problems--maybe with something like syntax-level support--could really lead to a beautiful programming language.
I keep running into Gleam posts and podcasts and videos. I think it could be an especially attractive alternative to JS for UI with the Lustre library. Haven't tried it yet, my backlog is ever growing...
It’s really good. But it needs generics. This is a huge downside. It’s a typed and clean functional programming language but it arbitrarily followed golangs early philosophy of no generics. Ironically golang is one of the most hated languages among many fp advocates.
By the developers own action of adding generics ultimately the golang team admits they were wrong or that generics are better. If gleam gets popular I think much of the same will occur.
There’s simply too much repeated code without generics. I tried writing a parser combinator in gleam and it wasn’t pretty.
There are multiple levels of possible generics at play here: the container type and the element type. You can have a map/reduce/filter that operate on any element type (generic elements) while still being specialized to linked lists. On the other hand, you might prefer a generic map that can operate on any container type and any element type, so that you can use the same map method and the same function to map over arrays of numbers, sets of numbers, lists of numbers, trees of numbers, or even functions of numbers!
Haskell allows both sorts of generics. In Haskell parlance they call this higher-kinded polymorphism and the generic version of map they call fmap (as a method of the class Functor).
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
Gleam is a beautiful language, and what I wish Elixir would become (re:typing).
For those that don't know its also built upon OTP, the erlang vm that makes concurrency and queues a trivial problem in my opinion.
Absolutely wonderful ecosystem.
I've been wanting to make Gleam my primary language, but I fear LLMs have frozen programming language advancement and adoption for anything past 2021.
But I am hopeful that Gleam has slid just under the closing door and LLMs will get up to speed on it fast.
I've also been wanting to make Gleam my primary language (am generally a Typescript dev), and I have not had any issue with using it with LLMs (caveat, I'm obviously still new with it, so might just be ignorant).
In fact, I'd say most of the Gleam code that has been generated has been surprisingly reliable and easy to reason about. I suspect this has to do with the static typing, incredible language tooling, and small surface area of the language.
I literally just copy the docs from https://tour.gleam.run/everything/ into a local MD file and let it run. Packages are also well documented, and Claude has had no issue looping with tests/type checking.
In the past month I've built the following, all primarily with Claude writing the Gleam parts:
- A websocket-first analytics/feature flag platform (Gleam as the backend): https://github.com/devdumpling/beacon
- A realtime holiday celebration app for my team where Gleam manages presence, cursor state, emojis, and guestbook writes (still rough): https://github.com/devdumpling/snowglobe
- A private autobattler game backend built for the web
While it's obviously not as well-trodden as building in typescript or Go or Rust, I've been really happy with the results as someone not super familiar with the BEAM/Erlang.
EDIT: Sorry I don't have demos up for these yet. Wasn't really ready to share them but felt relevant to this thread.
> 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.
There's a flywheel where programmers choose languages that LLMs already understand, but LLMs can only learn languages that programmers write a sufficient amount of code in.
Because LLMs make it that much faster to develop software, any potential advantage you may get from adopting a very niche language is overshadowed by the fact that you can't use it with an LLM. This makes it that much harder for your new language to gain traction. If your new language doesn't gain enough traction, it'll never end up in LLM datasets, so programmers are never going to pick it up.
23 replies →
Pure anecdote. Over the last year I've taken the opportunity to compare app development in Swift (+ SwiftUI and SwiftData) for iOS with React Native via Expo. I used Cursor with both OpenAI and Anthropic models. The difference was stark. With Swift the pace of development was painfully slow with confused outputs and frequent hallucinations. With React and Expo the AI was able to generate from the first few short prompts what it took me a month to produce with Swift. AI in development is all about force multipliers, speed of delivery, and driving down cost per product iteration. IMO There is absolutely no reason to choose languages, frameworks, or ecosystems with weaker open corpuses.
The motivation isn’t there to create new languages for humans when you’re programming at a higher level of abstraction now (AI prompting).
It’d be like inventing a new assembly language when everyone is writing code in higher level languages that compile to assembly.
I hope it’s not true, but I believe that’s what OP meant and I think the concern is valid!
7 replies →
> 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]"
Hi, I’m the creator of Gleam!
The comment you are replying to is correct, and you are incorrect.
All OTP APIs are usable as normal within Gleam, the language is designed with it in mind, and there’s an additional set of Gleam specific additions to OTP (which you have linked there).
Gleam does not have access to only a subset of OTP, and it does not have its own distinct OTP inspired OTP. It uses the OTP framework.
24 replies →
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.
Gleam uses regular OTP, it doesn’t have a distinct OTP inspired framework. Source: I’m the author of Gleam.
9 replies →
> what I wish Elixir would become (re:typing).
Elixir is slowly rolling out set-theoretic typing: https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...
I dunno, my unfounded guess is that gradual type systems are super complex and very hard to get right.
Why use something complex and half working, when you can have the real thing?
2 replies →
I don’t mean to minimize the huge effort by the Gleam team; however, Elixir cannot become Gleam without breaking OTP/BEAM in the same ways Gleam does. As it stands now, Elixir is the superior language between the two, if using the full Erlang VM is your goal.
I use many of the otp functions in gleam on thr regular, what functionality cant i call?
Gleam can call any erlang function, and can somewhat handle the idc types. [ im sure it has another name ].
Did i miss something that gleam fails on, because this is one of my concerns.
3 replies →
i just implemented a project in elixir with LLM support and would never have considered that before. (i had never used elixir before) - So who knows maybe it will help adoption?
[flagged]
I don’t know anything about gleam. I couldn’t find anything as “shoving political ideologies” on their code of conduct https://github.com/gleam-lang/gleam/blob/main/CODE_OF_CONDUC...
Examples?
1 reply →
Gleam is really quite a nice language. I did AoC in it this year as well and came away with the following: (incomplete list for both positive and negative, these are mainly things that come to mind immediately)
Positive:
- It can be pretty performant if you do it right. For example, with some thought I got many days down to double digit microseconds. That said, you do need to be careful how you write it and many patterns that work well in other languages fall flat in Gleam.
- The language server is incredibly good. It autoformats, autocompletes even with functions from not-yet-imported-but-known-to-the-compiler packages, shows hints with regarding to code style and can autofix many of these, autofills missing patterns in pattern matches, automatically imports new packages when you start using them and much much more. It has definitely redefined my view of what an LSP can do for a language.
- The language is generally a joy to work with. The core team has put a lot of effort into devex and it shows. The pipe operator is nice as always, the type system is no haskell but is expressive enough, and in general it has a lot of well-thought out interactions that you only notice after using it for a while.
Negative:
- The autoformatter can be a bit overly aggressive in rewriting (for example) a single line function call with many arguments to a function call with each argument on a different line. I get that not using "too much" horizontal space is important, but using up all my vertical space instead is not always better.
- The language (on purpose) focuses a lot on simplicity over terseness, but sometimes it gets a little bit much. 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. OTOH, I have also seen people who really really like this part of Gleam so YMMV.
- Sometimes the libraries are a bit lacking. There are no matrix libraries as far as I could find. One memoisation library had a mid-AoC update to fix it after the v1.0 release had broken it but nobody noticed for months. The maintainer did push out a fix within a day of realizing it was broken though. The ones that exist and are maintained are great though.
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:
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!
double space before each line for code formatting
1 reply →
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.
There are (some) guards available though? You could rewrite your example as:
Guards are a bit limited in that they cannot contain function calls, but that's a problem of the BEAM and not something Gleam could control.
4 replies →
In Gleam we would typically write this code with `use`, which doesn’t introduce nesting.
> - It can be pretty performant if you do it right. For example, with some thought I got many days down to double digit microseconds.
Was this the time of everything or just the time of your code after loading in the text file etc.? The hello world starter takes around 110 ms to run on my PC via the script generated with `gleam export erlang-shipment` and 190 ms with `gleam run`. Is there a way to make this faster, or is the startup time an inherent limitation of Gleam/the BEAM VM?
The time reported by the "gladvent" package when running with the "--timed" option. AFAICT that does not count compilation (if needed), VM startup time, any JITting happening, or reading in the text file. I'm fine with that tbh, I'm more interested in the time actually spent solving the problem. For other languages I wouldn't count language-specific time like compilation time either.
As to whether you can make startup time faster, I suppose you could keep a BEAM running at all times and have your CLI tools hotswap in some code, run it, and get the results back out or something. That way you can skip VM startup time. Since the BEAM is targeted more at very long-running (server) processes with heaps and heaps of concurrency, I don't think ultrafast startup time is really a focus of it.
> 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.
I like Gleam, but I am somewhat annoyed by the fact, that I don't have the full functional freedom in calling recursive (inner) functions wherever I want. I don't know, why new functional languages do not get this right all the way, straight from some rnrs document or implementation. Another thing is the separate operators like .> and .< and so on. What I liked were of course pipes and pattern matching.
To me it felt less elegant than Scheme (GNU Guile) which I usually use (with nice parallelism if I want to, pipelines, and also pattern matching), and, aside from syntax, conceptually perhaps less elegant than Erlang. On the other hand it has static typing.
I also tried OCaml this year, but there are issues in the ecosystem making a truly reproducible environment/setup, because opam doesn't produce proper lock files (only version numbers) and it seemed silly to not be able to even include another file, without reaching for dune, or having to specify every single file/module on command line for the OCaml compiler. So I was left unsatisfied, even though the language is elegant and I like its ML-ness. I wish there was a large ecosystem around SML, but oh well ...
Might be I should take another look at Erlang soon, or just finally get started with Haskell. Erlang using rebar3 should have proper lock files, has pattern matching, and if I remember correctly no such limitations for calling functions recursively. No longer sure how or whether Erlang did inner functions though.
Heh, similar thoughts! The main difference that I only used Scheme for SICP, and I've used a bit of Haskell.
I like Haskell in theory, but: just to get a hello world takes a lot of CPU and disk space. The standard library is full of exceptions (you can use a different prelude, that opens a whole different can of worms). The ergonomics of converting between the thousand different string types are awful.
So, you being basically me, I have some recommendations:
Idris (2): good stdlib, has dependent types. A beautiful language. The compiler is self-hosted and bootstrapped by lisp - very elegant! The ecosystem is basically nonexistent though.
PureScript: also improves on Haskell in many ways. But, it's more of a frontend language, and though you can do backend, you're stuck with JavaScript runtime. Oh well.
> The standard library is full of exceptions
By the way, the number of partial functions is base that throw compiler warnings is increasing, for example:
https://hackage.haskell.org/package/base-4.21.0.0/docs/Prelu...
I hope it will increase further.
If you like ML-ness try ReScript v12. It occupies a nice middle-ground between OCaml and Gleam.
The `echo` part seemed interesting but it made me think, debuggers need this as a built in feature. If I have
It seems like it should be a common feature to be able to view between each array operation in a debugger without having to augment the code with `echo`
The out of bounds handling didn't seem all that good to me. Sure you can filter out undefined. You could also just make a function that returns an empty array if out of bounds, or array of 1 element if not.
I also find grids made of 2 dimensional array to be code small. An array of arrays is NOT A GRID as there is nothing enforcing the inner arrays to be the same length as each other. Also, in efficienct code it would be better to provide a 1 dimensional array and bounds. Now, out of bounds checks based on accessing outside the array won't work. You need to check actual bounds. Again giving preference using a helper
When I was debugging through f# code they definitely had that.
I haven't explored the BEAM ecosystem much. And this post actually got me motivated enough to try it out.
The more programming languages we play with, the better we become as engineers. We learn the different design decisions that go into each language. And we learn the language of Computer Science itself.
Plus, Advent of Code!
So I finally got everything installed. But then I realized there are no easily accessible offline docs. I don't have Internet service at home. So I have to grab service when I can make it out.
So it looks like mix can download offline hexdocs, but I don't have elixir installed. And there's a hexdocs_offline dev package for Gleam. But it errors out on "gleam/dynamic does not have a 'from' value.
Maybe it's a "teaching moment" about the basics of the language. But I have to run out to another appointment now, so these teaching moments don't always help.
Anyways, I guess I'll dive in after the holidays and just wget the tour or get some well regarded projects for reference. I'm actually still really excited with all the functional features.
Honestly it’s very much worth it! Look into this https://hexdocs.pm/hexdocs_offline/index.html
I don’t know gleam, but surely
Could be written
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.
This sounds like the kind of situation where the LSP could suggest the simpler code, I'll see if there's an issue for it already and suggest it if not.
1 reply →
That is correct.
Gleam is a great language. It didn't click for me when I was trying it out, but I'm glad to see more people enjoying it.
And I wonder if Gleam + Lustre could become the new Elm.
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.
Not many people use elm directly but it has influenced the design of so many frameworks and libraries.
Right now I’m toying with the idea of building a GNOME application in rust, and the framework I’m using is relm4 which provides elm like abstractions over gtk-rs.
Previously I’ve built web applications with F# and elmish, which again provides elm like abstractions for building F# applications.
1 reply →
> all the conflict with the creator
Just so no one misunderstands this. The creator (Evan) didn't get into, or start, any drama himself that I ever noticed. I'd argue he's a very chill and nice dude.
I've been on the edges of the community for probably a decade now (lurker), and all of the drama came from other people who simply didn't like the BDFL and slow releases strategy.
1 reply →
Yeah I'm not a front end dev but I do kind of keep track of what's going on in that space. From what I saw it seemed Elm was all but dead. Maybe that's not true, but that was the impression from the outside looking in.
5 replies →
> the lack of compiler releases
I'm a backend dev mostly and use Elm for all my frontend needs. Yes there are some things compiler-side that could be improved, but basically it's fine.
I appreciate not having to keep up with new releases!
Which conflicts? Gleam seems to be released often?
1 reply →
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).
Anecdotically I recently got into Ruby, via Sinatra, and enjoy the experience.
What are you lacking in ruby and rails, besides the types?
1 reply →
I've considered playing around with it. Every now and then I tell myself I'm gonna learn front end dev, but as soon as I start looking at it (FE in general not Lustre specifically) I get depressed and give up lol
3 replies →
This Lustre? https://www.lustre.org/
Seems to be a filesystem, how would it replace a database?
2 replies →
I looked at lustre for a recent project and it seems very nice. But the ecosystem is pretty small yet (I could find no examples of auth, for one), so I ended up going with liveview.
I'm hoping it succeeds and gets bigger because I really like its ergonomics.
One thing im wondering with the LLM age we seem to be entering: is there value in picking up a language like this if theres not going to be a corpus of training data for an LLM to learn from? Id like to invest the time to learn Gleam, but I treat a language as a tool, or a means to an end. I feel like more and more I'm reaching for the tool to get the job done most easily, which are languages that LLMs seem to gel with.
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.
There's certainly a lot more JS code out there to train on, but the quality of the Elixir code is likely overall much better.
I personally find it much more painful to generate valid Rust code that compiles and does what I want than e.g. valid python code that runs and does what I want.
3 replies →
in my daily experience Claude Code writes better Elixir code than JS (React). Surely this has to do with the quality of the training material
2 replies →
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.
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?
If you're fortunate, you can find companies with a passion for good code who use lesser-known languages. Picking Erlang, or Haskell, or OCaml generally filters out candidates who don't share your interest in seeing what can be done outside the mainstream.
1 reply →
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.
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.
I’m more interested in what happens when a language is designed specifically for llms? When doing vibe coding a lot of code is a lot more verbose than I’d do normally. Do we drop down the abstraction level because llms are just so good a churning out boilerplate?
1 reply →
I think as ai tools actually learn languages that functional languages will win out as they are much easier to reason about.
it’s easy enough for them as soon as they have an RL environment for the language
This is the answer. We need online learning for our own code bases and macros.
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.
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).
The Gleam language, yes all of it, fits in a context window (https://tour.gleam.run/everything/)
I have similar concerns to you - how well a language works with LLMs is indeed an issue we have to consider. But why do you assume that it's the volume of training data that drives this advantage? Another assumption, equally if not more valid IMO, is that languages which have fewer, well-defined, simpler constructs are easier for LLMs to generate.
Languages with sprawling complexity, where edge cases dominate dev time, all but require PBs of training data to be feasible.
Languages that are simple (objectively), with a solid unwavering mental model, can match LLMs strengths - and completely leap-frog the competition in accurate code gen.
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.
I don't know Gleam at all so I can't comment on that specifically, but I think everyone has the experience of a coworker who writes C++ as if it's C or Python as if its Java or whatever else.
A language doesn't have to be unique to still have a particular taste associated with its patterns and idioms, and it would unfortunate if LLM influence had the effect of suppressing the ability for that new style to develop.
This was one of my bigger worries for LLM coding: we might develop path dependence on the largest tools and languages.
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.
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.
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.
the flip side of that, right now ai coding agents try to generate code, not software.
it seems semi intuitive to me that a typesafe, functional programming language with referential transparency would be ideal if you could decompose a program to small components and code those.
once you have a referentially transparent function with input/out tests you can spin on that forever until its solved and then be sure that it works.
Of course there is, especially if you believe that LLMs further improve on reasoning.
where do you think the corpus of training data comes from?
I've looked at Gleam before but it didn't seem to have any mechanism for dynamic dispatch like interfaces or type classes. Did it change in the meantime?
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.
It’s discouraged to pass around structs of functions to replicate type classes in Gleam. Instead the preference is to not type class style patterns in your projects, favouring a concrete style instead.
4 replies →
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.
What you are saying is: no, it doesn't.
Of course dynamic dispatch can be implemented in almost every language. The Linux kernel uses dynamic dispatch with C!
But that's a hack, not a language feature.
2 replies →
Something I really hope Gleam figures out is a way to streamline the Elm architecture. We see the Elm architecture mostly in web apps, but I think that model is a really good idea for a lot of applications!
But I think two things really hold it back:
* it's verbose.
* they compose awkwardly.
Neither of these are showstoppers, but I think fixing these problems--maybe with something like syntax-level support--could really lead to a beautiful programming language.
I keep running into Gleam posts and podcasts and videos. I think it could be an especially attractive alternative to JS for UI with the Lustre library. Haven't tried it yet, my backlog is ever growing...
fortunately the blog title police stepped in as soon as possible https://news.ycombinator.com/item?id=45426996
> You can do [first, ..rest] and you can do [first, second].
> But you cannot do [first, ..middle, last].
I don't think you're supposed to do that! It's probably expensive!
Gleam should add Go as an target. That would have a huge potentital, as the Go runtime is second to none, and its ecosystem is enormous.
Nice, thanks for the write-up! Any pros/cons that jump out to you for someone whose been trying to pick up Elixir on the side?
Thank you! I have not played around with Elixir just yet, sadly, so I can't help there, I'm afraid.
I don't know if I'm the only one experiencing this: It's too hard to find the download link from their website.
I think most people will use package managers to install it, or will use docker images to run code in.
Ruined by ligatures. Use them in your own private coding time, not when trying to communicate with others. It obfuscates rather than clarifies.
I actually agree. I don’t even use them in my private code. I will look into removing them from my blog!
For a quick fix: `font-variant-ligatures: none;` on body or similar.
3 replies →
'Ruined' is a bit strong, isn't it?
[dead]
[dead]
It’s really good. But it needs generics. This is a huge downside. It’s a typed and clean functional programming language but it arbitrarily followed golangs early philosophy of no generics. Ironically golang is one of the most hated languages among many fp advocates.
By the developers own action of adding generics ultimately the golang team admits they were wrong or that generics are better. If gleam gets popular I think much of the same will occur.
There’s simply too much repeated code without generics. I tried writing a parser combinator in gleam and it wasn’t pretty.
Gleam has always had generics! There’s no Gleam version without them
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.
That’s the worse is better philosophy which maybe doesn’t matter as much anymore especially with AI
4 replies →
Perhaps this is a silly question but how do you do functional with no generics? Arent they pretty much required for map/reduce/filter?
Sorry my comment was wrong. It’s been a while when I messed with gleam and I remember it was missing a critical thing but I misremembered what it was.
Gleam doesn’t support interfaces. Not generics. You are completely right.
There are multiple levels of possible generics at play here: the container type and the element type. You can have a map/reduce/filter that operate on any element type (generic elements) while still being specialized to linked lists. On the other hand, you might prefer a generic map that can operate on any container type and any element type, so that you can use the same map method and the same function to map over arrays of numbers, sets of numbers, lists of numbers, trees of numbers, or even functions of numbers!
Haskell allows both sorts of generics. In Haskell parlance they call this higher-kinded polymorphism and the generic version of map they call fmap (as a method of the class Functor).
Gleam does have generics.
Most Scheme implementations don't have generics, and you have to deal with a different map function for every data structure.
Gauche has a generic sequence interface which is great, and it's one of the reasons as a Python user I like Gauche as my "daily driver" Scheme.
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
the comment is wrong, what Gleam lacks is interfaces.
Which feels super strange, but doesn't seem to really be a problem, e.g. imagine a language where you'd write
Gleam wants you to write
edit: found an article that explained this a bit better https://mckayla.blog/posts/all-you-need-is-data-and-function...
1 reply →