I have a web app i've been using regularly and develop regularly with gleam on the frontend and backend. I have written very little of the code by hand and use claude to implement everything, open PRs and stuff and it works well. I like that it's typesafe and you can share code between the frontend and backend so easily, and you don't have to get a bunch of config right like you do if you want an all-typescript application. If I was writing it by hand I think I would find there's an annoying amount of boilerplate, but since ai is writing the code for me it's not a big deal.
I never liked currying. It feels more theoretically elegant than practically useful.
IMO it is hard to read (unless you're very familiar with the functions at hand), produces type errors that are not easy to follow (oops, I forgot the last arg), and is too rigid (I often need to partially apply arguments in non left-to-right order).
I never understood why partial application via "slots" isn't more common though (I just made up the term, not sure if this has a name). Like Clojure's:
#(f %2 "foo" %1 "bar")
;; same as
(fn [a b] (f b "foo" a "bar"))
To your point on "Gleam: the bad" and the ecosystem being small, I would add that this community has a history of activism behaviour. Some like that, I'm out.
I don’t have a problem with activism per se, but it does put me off how the official website tries to make the language and community look extremely friendly and cutesy, only to immediately break that facade. If that’s the look you’ve decided to go for, at least try and commit to it!
We do still read code. Most people are not doing a fully unseen development strategy because we have needs around efficiency, security, compliance etc and we can’t simply blame it on our agents like we don’t control them like OpenAI do
We might still read them, but let’s set that aside. Some languages may offer ways to eliminate entire classes of bugs. Gleam and Haskell-ish languages do that through very strong type systems and expressive high-level functional constructs. Rust similarly eliminates a ton of memory errors through its borrow checker. LLMs aren’t infallible, so this can result in better quality code (or if you believe every bug will still be caught…less code to do it).
Gleam also runs on BEAM, which has important runtime characteristics vs other languages. That will impact your system and how it scales even if you never look at the code.
I mean, even if you've stopped even reading code (good luck with that), the right abstraction should make things things easier for the LLM. A good rich type system to stop incorrect code, linters to catch common errors. A good set of battery-included system libraries. BEAM should provide a good abstraction for highly parallel and distributed systems, which means the LLM doesn't need to build all those abstractions itself. If you're building a distributed system, it should be like providing a set of good guardrails, guiding the LLM in building a correct system.
I've seen even the best models try to build & debug parallel and distributed systems. The results are always a bit uneven at best, even with a good harness and a lot of guidance.
The disadvantage of niche languages is that the LLM won't quite know the language as well due to less training data being available. But if you actually need to build something distributed, then this might be a good trade-off.
Who's this "we" you speak about. There is a small subset of programmers who have become effectively become managers and ask their AI employees to do things. The rest of us still regularly read and write code.
Even in an AI intensive workflow, reading code remains a huge quality gate and I'd be wary of any software which hasn't been reviewed by humans.
Moreover, to me coding carefully is still a hobby, a pleasure, a craft. Gleam is exactly the kind of language that makes this such a pleasant activity.
> why do we care about programming languages when we no longer read programming languages directly?
Because, we do?
You may not, which is fine. A lot of developers may not... that's fine. I guess you're all employed and don't risk your livelihood when things go wrong.
I do though. I take responsibility.
And just like with any junior developer I guide AI and I do review what it creates in the project that matter. (Personal tools I've entirely vibe-coded, never any client projects though)
1. In a lot of cases, even if you're pure vibecoding and not reviewing any code, its still useful to be able to read it - you can then verify and reason about various aspects. LLMs are often flat out wrong on niche issues of performance etc, so for cases like this, not being able to read code is a big risk.
2. "Languages optimized for LLMs" sounds awesome, but so far, to me at least, it seems like LLMs work best in the same situations as humans- good test coverage, low-complexity, clean architecture, etc.
For what it's worth, I still parse code changes and feel uncomfortable if I struggle to understand code output without assistance.
On the "languages for LLMs front", isn't that a bit "cart-before-horse"? Doubt we are anywhere near the limit of what a model could do with a static verifiable language, even more so since stuff like TS has massive training data, any new language wouldn't benefit in such a way.
Add to that, I'd rather be able to understand the output, partly for aforementioned reasons, partly because we have seen with post Spud GPT reasoning/summarisation issues what happens when being able to read model output becomes even slightly harder. Having model-focused languages would only exacerbate such issues.
Also, absolutely not a Maths expert so take this for an utter layman regurgitating of what I have read, but apparently the Lean proofs by OpenAI are very hard to parse even for the experts in the field, lovingly called "Clanker Proofs", even when they are valid.
Having not just correctness but also human understanding as a goal has merit, so there is that to consider too. Rather models get more efficient at using what we have (and can understand+maintain as humans if need be) then make it more opaque.
I wrote this to show my appreciation of this small-ish but beautiful language.
Thanks! I really liked the concrete examples. Spending most of my days with the monster that is modern Swift, Gleam feels like fresh air.
I have a web app i've been using regularly and develop regularly with gleam on the frontend and backend. I have written very little of the code by hand and use claude to implement everything, open PRs and stuff and it works well. I like that it's typesafe and you can share code between the frontend and backend so easily, and you don't have to get a bunch of config right like you do if you want an all-typescript application. If I was writing it by hand I think I would find there's an annoying amount of boilerplate, but since ai is writing the code for me it's not a big deal.
Overall, I recommend it.
What framework did you use for Gleam? I feel the last time I looked that was one of the big absent libraries.
if the ai is writing everything wouldn't it be better to choose a more popular language?
What's the fuckin point of any language ergonomic if you're not reading or writing it.
Had a great talk on Gleam at the Carolina Code Conference a couple of years ago by Dillon Mulroy, now with Cloudflare I believe.
https://carolina.codes/speakers/2024/dillon-mulroy
That site is also partially powered by Gleam on the backend.
Was in person for this talk! Dillon did a great job, obviously passionate about the language and its ecosystem.
Gleam is really a delightful language with great ideas, but the lack of currying is a tragedy.
Missing currying feels a little to me like walking in FP land with one leg cut off.
I never liked currying. It feels more theoretically elegant than practically useful.
IMO it is hard to read (unless you're very familiar with the functions at hand), produces type errors that are not easy to follow (oops, I forgot the last arg), and is too rigid (I often need to partially apply arguments in non left-to-right order).
I never understood why partial application via "slots" isn't more common though (I just made up the term, not sure if this has a name). Like Clojure's:
Does Gleam have something like that?A deal breaker, and just when I was starting to get excited!
Plenty of practical reasons for currying, but the biggest (imo) is for use with the pipe operator.
If they don't have partial application now, what are the odds they'll have it in the future?
Apart from the language, what's the developer experience like, especially doing full-stack?
F# showed a lot of promise with Fable, but the community never quite got the tooling right, I think for a lack of energy/funding.
I found the tooling to be quite comprehensive, the LSP is high-quality for a small project.
There are a few rough patches too. For example, I have yet to find out how to run a single test and not the whole suite.
I've been keen to try it out for a while, I might do something with it in the near future.
To your point on "Gleam: the bad" and the ecosystem being small, I would add that this community has a history of activism behaviour. Some like that, I'm out.
> Some like that, I'm out.
And a third group couldn't care less either way.
I have a few decades on my back, I am a father, a husband, a nerd... I once was young too, believe it or not, and I had ideals and I fought for them.
If you don't participate in this, why does it bother you? Unless they are active around your doorstep, that is.
What kind of activism? Isn't activism just "doing something to try and make a larger change"?
I wasn't particularly aware of that to be honest. What kind?
https://wiki.alopex.li/GleamGrumpiness
I don’t have a problem with activism per se, but it does put me off how the official website tries to make the language and community look extremely friendly and cutesy, only to immediately break that facade. If that’s the look you’ve decided to go for, at least try and commit to it!
You know you don't need to follow hold their CoC in any way to use the language right?
Do you only use languages that you can contribute to their codebase?
opensource is activism
Hey! I know this!
[flagged]
We do still read code. Most people are not doing a fully unseen development strategy because we have needs around efficiency, security, compliance etc and we can’t simply blame it on our agents like we don’t control them like OpenAI do
Relevant Calvin & Hobbes strip:
https://static0.cbrimages.com/wordpress/wp-content/uploads/2...
We might still read them, but let’s set that aside. Some languages may offer ways to eliminate entire classes of bugs. Gleam and Haskell-ish languages do that through very strong type systems and expressive high-level functional constructs. Rust similarly eliminates a ton of memory errors through its borrow checker. LLMs aren’t infallible, so this can result in better quality code (or if you believe every bug will still be caught…less code to do it).
Gleam also runs on BEAM, which has important runtime characteristics vs other languages. That will impact your system and how it scales even if you never look at the code.
I mean, even if you've stopped even reading code (good luck with that), the right abstraction should make things things easier for the LLM. A good rich type system to stop incorrect code, linters to catch common errors. A good set of battery-included system libraries. BEAM should provide a good abstraction for highly parallel and distributed systems, which means the LLM doesn't need to build all those abstractions itself. If you're building a distributed system, it should be like providing a set of good guardrails, guiding the LLM in building a correct system.
I've seen even the best models try to build & debug parallel and distributed systems. The results are always a bit uneven at best, even with a good harness and a lot of guidance.
The disadvantage of niche languages is that the LLM won't quite know the language as well due to less training data being available. But if you actually need to build something distributed, then this might be a good trade-off.
Who's this "we" you speak about. There is a small subset of programmers who have become effectively become managers and ask their AI employees to do things. The rest of us still regularly read and write code.
Even in an AI intensive workflow, reading code remains a huge quality gate and I'd be wary of any software which hasn't been reviewed by humans.
Moreover, to me coding carefully is still a hobby, a pleasure, a craft. Gleam is exactly the kind of language that makes this such a pleasant activity.
> why do we care about programming languages when we no longer read programming languages directly?
Because, we do?
You may not, which is fine. A lot of developers may not... that's fine. I guess you're all employed and don't risk your livelihood when things go wrong.
I do though. I take responsibility.
And just like with any junior developer I guide AI and I do review what it creates in the project that matter. (Personal tools I've entirely vibe-coded, never any client projects though)
I'd make two cases:
1. In a lot of cases, even if you're pure vibecoding and not reviewing any code, its still useful to be able to read it - you can then verify and reason about various aspects. LLMs are often flat out wrong on niche issues of performance etc, so for cases like this, not being able to read code is a big risk.
2. "Languages optimized for LLMs" sounds awesome, but so far, to me at least, it seems like LLMs work best in the same situations as humans- good test coverage, low-complexity, clean architecture, etc.
For what it's worth, I still parse code changes and feel uncomfortable if I struggle to understand code output without assistance.
On the "languages for LLMs front", isn't that a bit "cart-before-horse"? Doubt we are anywhere near the limit of what a model could do with a static verifiable language, even more so since stuff like TS has massive training data, any new language wouldn't benefit in such a way.
Add to that, I'd rather be able to understand the output, partly for aforementioned reasons, partly because we have seen with post Spud GPT reasoning/summarisation issues what happens when being able to read model output becomes even slightly harder. Having model-focused languages would only exacerbate such issues.
Also, absolutely not a Maths expert so take this for an utter layman regurgitating of what I have read, but apparently the Lean proofs by OpenAI are very hard to parse even for the experts in the field, lovingly called "Clanker Proofs", even when they are valid.
Having not just correctness but also human understanding as a goal has merit, so there is that to consider too. Rather models get more efficient at using what we have (and can understand+maintain as humans if need be) then make it more opaque.