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.
this is what grinds my gears with gleam. afaik its not really possible to interact with elixir libraries? A project exists to try to make this 'easier' but the fact that it was not baked-in as first class is a huge smell to me https://github.com/gleam-lang/mix_gleam/
Perfect example: Clojure. Clojure is the textbook esoteric programmers dream... but it's SUPER easy to sell and integrate in a typical Java shop. Why? Clojure is Java. You can use everything on Maven. You can interop with any Java tooling. No hacks or BS required... it's a native compatibility. The fact that the Gleam did not opt for this level of congruence is mind boggling to me.
I could be wrong btw so please correct me if I am. I am genuinely interested in using Gleam in place of Elixir (I think they nailed syntax and got rid of a lot of bullshit) but it is unfortunately not a drop-in replacement. It should be.
There are two sides to compatibility with Elixir: using Gleam in Elixir and using Elixir in Gleam. The former is harder, the latter is easier (with caveats).
Using Gleam in an Elixir project did/does rely on mix_gleam. I've used it some years ago and it worked then, but I haven't had recent experiences. There is a pull request[0] to Elixir to add built-in support for Gleam and as I understand it the Gleam team have made several changes to Gleam tooling to facilitate it, but it's unmerged as of now.
Using Elixir in a Gleam project is just an external function away, just like using Erlang or JavaScript (when using the JS target). E.g.
You can also write .ex files in your codebase and use functions from them as externals and they'll be compiled by Gleam.
The two main issues on that side are macros and structs. Since Gleam doesn't know about Elixir source or Elixir macros, you can't use them directly. But you can have an .ex file that uses macros and then you can call functions from that file. Structs are trickier, because they're just dynamic maps with a special key-value pair, and maps in Gleam (called Dict) have fixed types for the keys and values. That means you can't model a struct as a Dict. Gleam uses records for its own custom types, so what you can do is either use records on the Elixir side (with the Record module or by hand), or map the Elixir side data structures to be more palatable for Gleam (and vice versa) in your external functions --- which is what you generally do with externals anyway. Of course, if you only intend to pass the Elixir structs around and then back to Elixir, you can model them as external types that are then opaque to Gleam.
Exactly the opposite -- in a lot of ways, mainstream languages represent a compromise that gives the worst of all worlds for the benefit of popularity. With AI, you can take advantage of unpopular esoteric languages that have measurable advantages over mainstream languages. Before, the choice for a mainstream language was too strong because of network effects. Now with AI those effects don't matter as much, so being mainstream isn't as much of an advantage.
The copious training data on mainstream languages doesn't really translate as a network effect, and therefore is kind of a red herring because the AI can use all that training on new languages as well. e.g. if you use a esoteric language that is vaguely object oriented, the AI will use its vast training on object oriented programs and apply it to your language instead of falling over because your language isn't Python and it doesn't have training data on it.
Moreover, the AI is trained on copious amounts of PL research, so it's not like the ideas in a new language are completely new to it.
In that Tencent study less common languages got easier problems. Which explains why racket also performed suspiciously well in it. The authors recognize the problem themselves. I like elixir, but it's imo embarrassing how often elixir people cite that study despite it not actually supporting what they claim.
That showed about what we expect, that popular languages like python, javascript, java, C#, etc do best, while less popular languages like Common Lisp, Ocaml, Zig, etc do slightly worse. But the difference is small enough I'd still just choose whatever language and ecosystem I know best that is appropriate for a project.
What they did is they gave the AI a huge pile of docs and said "implement this". But they didn't give the AI any tests as part of its objective. I was under the impression it's generally common practice to use a test-driven development approach with AI, so I think it would have been more representative for them to have split their test corpus in half: one half it could see during implementation, and then the could test on the other half.
Also, they restricted access from the internet, so I think this would have disadvantaged less popular languages.
I would definitely be skeptical of a study that finds using an LLM/agent to write sqlite in JS being better than writing in Zig, but it strongly depends on what “better” or “worse” mean.
It means how much of the sqlite test suite it passed. They were just measuring correctness, not performance or memory consumption, where of course Zig should win.
But the aim of that experiment was measuring correctness of llm written code in different languages, so used sqlite as a benchmark considering it's fairly complex software with a comprehensive test suite. It is not suggesting that because a language scores better on that benchmark it'd be better suited to writing the next sqlite, due to obvious other factors like performance...
A more popular language like what? The more popular choice that I could think of was typescript and the world around typescript and javascript is so big and fragmented I think you'd end up with it the ai doing things in different ways in different places. Gleam is a smaller ecosystem but it also just feels better organized and more consistent which helps for keeping things consistent in your app.
That mindset is a bit dated when models can pull up docs for a few years now. You can even have it write itself a little guide for lesser known languages within its own agents file.
Programming models have been sophisticated enough for some time to not be restricted to specific languages. It's rather like the difference between a junior developer (who knows how to use a specific language) and a mid developer (who knows who to program generally).
Is there any research that supports what you are saying here? I agree it mostly works, but I’d expect more API hallucinations and test cycles at a minimum.
Not sure why you're asking this? But i mean if a language is more readable and has good typesafety it's easier for llms to understand, plus a lot of times you want to read and understand it even if you're not typing it out yourself
That's also not true at all. The most efficient languages for an LLM are the ones that have the largest datasets to reference. It knows the shape of a billion lines of Python. There's no evidence to suggest that "a more ergonomic language" burns less tokens cause it probably has to do multiple sweeps to get it "right". Otherwise some "agent/token efficient" language would've already been built and we'd all be using it. The defacto are just the most popular languages and that's not a coincidence.
Only if they gain that ergonomic advantage without complicating flow of control. Metaprogramming is costly for example, in the past so have been operator overloading and lazy evaluation.
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"))
I think the single hole version is a good compromise compared to actual currying or multiple holes, since it's strictly better than something like first or last argument threading (e.g. ->, ->> in Clojure), easier to reason about than currying, and in my experience most of the time you'll only be dealing with one argument to pass piping anyway. Anonymous functions are fine for the cases you need more flexibility.
As I mentioned in my other comment, they do have partial application with _, and it works like a charm for piping!
It's automatic currying which is absent.
Ymmv, but you can get pretty far with a convention: order arguments by _how likely they are to be closed_ within any given context. As a full-time F# developer that covered >95% of what we were doing.
An alternative is providing variations on a function that "bundle" sets of arguments, and then making the bundle the first parameter, but that only makes sense when the "bundles" occur together a lot.
I would rather see syntax to make partial application on arbitrary named or positional slots as ergonomic as possible. How much has that been explored by existing languages?
What I've seen: (A) anonymous functions with placeholders (see above), (B) currying (ML), (C) binding variations defined with the function itself (Scala, I think?).
One approach that I haven't seen yet (maybe some language has it?) is named bindings for arbitrary partial application. I _think_ that would be a little tighter than anonymous functions, but I'd need to see it in action.
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.
Fair point, I am with you on that. I guess just had a bad first impression on drama that I've seen as a spectator through the public channels that stuck.
That could be repaired, just don't care enough to spend time there again I guess.
It doesn't police peoples' personal beliefs outside the community. It only says that while participating in the community you agree not to harass people and try to contribute in a positive way.
I wonder if you have past experiences that are coloring your interpretation of this, because I'm really unsure where you're getting any of this from.
People working on an open-source language aren't 19-year-olds on twitter, you're using the wrong heuristic here. They're there mostly to talk programming and work on a project together. The CoC is pretty standard language that you'd find at most conferences you attend. It specifically enumerates bigoted actions because several contributors are members of the LGBT community. The last thing many of them want is to deal with culture war nonsense seeping into their fun hobby.
> The last thing many of them want is to deal with culture war nonsense seeping into their fun hobby.
This is bullshit.
Typically we are talking about the same category of people that become Reddit mods. Those are full blown adults where internet drama and culture war nonsense is their actual hobby. The open source thing beneath it is the side project.
It's the reason why I avoid getting involved with open source communities like billionaires avoid taxes.
That said, my original point is not to avoid Gleam as a language. The language itself looks pretty interesting. You don't need to stare at the CoC to use the language.
I am honestly a bit confused because this whole comment chain looks like someone is starting culture war and drama? But you mean that the people who use gleam tend to be into culture wars, not the OP poster in the chain?
Culture wars come up in every Gleam thread. How often do you see culture war comments in a Rust, Elixir, Javascript, Etc thread? Essentially never. The Gleam founder's bigotry is a distraction at best.
I dunno about the others, but the icon for the Rust discord is the Rust logo superimposed on the pride flag, so they are not subtle about their position on the topic, and it has therefore been a topic of discussion in that community.
The reality of online spaces is, you can either make Nazis aware they're not welcome at the door, or you can let them know when they start making trouble. Either way, if you want to keep your online community copasetic, eventually you have to tell Nazis to fuck off.
I’m guess those are not the people he/she considers their “contemporaries”, who likely adopted that language much more recently and use it in a different way.
Agreed. Treat people well seemed to be the Gleam desire.
The counterarguments from the other party (seemed like one person with multiple accounts to me) were about their disbelief in trans people and the idea behind the Black Lives Matter movement (coupling it with some organization that copied the name and stole some donations)
I am on that thread as well. The issue with these "codes of conduct" isn't that they exist, it's that their purveyors force the "code" upon every participant regardless of forum.
If you don't support their special interests in completely unrelated venues, you are persona non grata and will either fall in line or be excommunicated. It's a sophisticated form of control via identity politics.
I think you're seriously overreacting; you don't need to believe the same things that they do, all the CoC states is that if you want to engage with the community, you agree not to harass people. Every community has similar expectations; having it in a markdown just makes it more explicit.
You might be letting your personal experiences pollute things. The CoC never says that. It's anti-harassment language, and specifically enumerates what that might look like. Some contributors are members of the LGBT community, and I'm sure don't want to debate their personal identity when they're there to contribute to a project and write code.
I... Think many of us would like evidence to back this up. Can you demonstrate that the Gleam community has done this, specifically? Because it really seems, to me at least, that this is a bit of straw-manning.
I mean, yeah — people won't want to be in community with someone who transgresses against their social norms and values. Freely choosing with whom you associate is not a "form of control". You're still welcome to use the project.
Sounds to me like a lot of divisive American politics, as usual.
I have no problem with a community setting whatever acceptance criteria they like.
If the license did the same, I could see a case of being a bit of overzealousness.
I couldn't find if that was the issue, but if your problem is that the creator and the community have political opinions and don't like people with incompatible ones, then that's just society...
> but if your problem is that the creator and the community have political opinions and don't like people with incompatible ones, then that's just society...
No, I am fine with incompatible views and I often seek them in order to grow. I do not enjoy echo chambers and I usually prefer and welcome disparate, including contrarian, opinions.
It's more like I don't want Ideology served with Programming Language, it feels like a distraction to me when I am in that mode. I usually consume Ideology under a different context, where I find it more productive and can contribute better to it.
I think you have a reasonable position here, so I understand where you come from.
I find this whole thread here interesting because until today I wasn't confronted by any of this, even though I joined the Discord and had a pleasant time (and will keep doing).
So I guess all I have to say on this is I don't think the "ideology" is that much served with the programming language. Yes I read that there's a code of conduct and that annoyed some people. But like I downloaded Gleam, I coded with it, I talked to people, and the thought police didn't knock on my door. So I guess what I mean is that it feels a little overblown.
Thanks for understanding it, and yes not everyone draws the line at the same boundaries.
Once in a while I try to push my boundaries, but then again I like to choose where I do this. For this one, I prefer not to do it in a work adjacent environment with strangers on the internet.
That aside, the language sounds fun hope you create cool things with it!
> "As a community, we want to be friendly too. People from around the world, of all backgrounds, genders, and experience levels are welcome and respected equally. See our community code of conduct for more.
Black lives matter. Trans rights are human rights. No nazi bullsh*t. "
> I don't think the "ideology" is that much served with the programming language.
But it's in the language, and I'm almost not joking.
If you think about it, Gleam encodes worst possible meaning of communism. Those kind where one size fits all because there is no other size. Utopia where everybody are equal because there is no way to be better.
Also there is a funny thing about it. In this sense Gleam surpasses even Go, which is deliberately built to make developers as interchangable and average as possible. Can we count that as an example of horseshoe theory?..
Yes, people who build programming languages view PL design as a form of self expression; like artists who use a painting to capture and communicate the beauty of a flower, PL designers try to communicate beautiful system design using languages.
So it's very often the case that languages built by a single dev or small team often reflect their worldview and opinions. Take a look at Urbit by Curtis Yarvin, a man who believes in neo feudalism built a programming system that expresses neofeudalistic ideals pretty explicitly. Programming language design is about organizing systems of information to perform useful work, and its a very short hop from there to thinking about organizing systems of people. Or vice versa.
> creator and the community have political opinions and don't like people with incompatible ones, then that's just society
Why are my political views relevant? This is a programming language. Nobody is popping into the Gleam issue tracker and mentioning politics, nobody is violating the "code of conduct" there.
The "code of conduct" exists solely to lambast people who disagree with the author's special interests in other irrelevant spaces. This is the "paradox of tolerance" in codified form.
I mean it's only relevant if you bring it with you in their community. You don't sign your soul away when you download the compiler. Do you have the same issue with all the ToS asking you to not be a nazi and whatnot on a given platform?
Maybe you could be specific, instead of just spreading FUD? I read through the discussion you linked, and I have no idea what you’re talking about, so to me your comment comes of as just FUD.
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!
> "Contribute to their codebase" includes bug reports and seeking help with errata and other issues.
That is exceedingly rare. The vast majority of times you will either find your answer online to work your way around issues.
> It might be problematic to use a language where needed help could be preceded by Twitter or HN background and allegiance check.
I would remind you that we have LLMs now. One of the greatest gifts of LLMs is not having to rely on talking to people online to figure out issues when using a language/framework/library.
Both searching for answers online and consulting LLM’s depends on prior human works or interactions, and (from what I know) their feasibility scales with the language’s popularity. I should expect both approaches to work much more reliably for Perl or Python than they would for Gleam or Newlisp.
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
Which tangentially brings up another analogy: many high level languages don’t compile directly to assembly but to an intermediate language first (LLVM). We don’t read the LLVM code ourselves.
I don't want to say what people should and shouldn't do, and a world in which all the world's professionals spend their days talking to sycophantic machines with only a loose commitment to the truth is really funny to me.
But, high level languages don't really lose precision in any way that matters (except when you need extreme performance, resistance to timing attacks, or niche stuff like that). Natural language on the other hand loses precision that's usually important, so I don't see how your comparison is valid.
Not seeing it. “We do still read code” implies neither that every single person does, nor that they need to master the language being read. Taken together, it seems to me that you need a fair bit of extrapolation (or a presupposition that programming languages are already obsolete when that’s the very point being contested) to make the analogy work.
Deterministic vs None-Deterministic, understanding what compiled code does also is possible without Assembly knowledge, not so necessarily with models, where I do like to at least understand what has happened and quite often find a crime or five.
Heck, OpenAI can't even get their models to reliably do what they intend, so yeah.
Ok, I feel you know what this is actually about, but here spelled out:
Do any of the optimizations you mentioned affect the underlying behavior of the run code? Semantics...
If not, it doesn't fit to LLM use, where this is very much the case. We can talk about bugs in compilers and undefined behaviours and so on and so forth all the livelong day, but you know as well as I that this is not of the same scope of impact.
I could and in the past would have written a long diatribe about how pure compilation to assembly is deterministic, thus making this not really suitable and that while yes, there are things like JVM that aren't 100%, we have contracts, docs, specs and, because of them, an expectation of consistency that LLMs do not deliver. I did not because I thought that was not necessary, but see my error now, that is my mistake.
There is the observable behaviour, and the machine code instructions that actually get generated in every single case for the same kind of text input.
Which for example, unless you can exactly replicate the world every single time a PGO data gathering session is done, there are no guarantees that the compiler will generate exactly the same machine code pattern, when given various PGO files generated at different occurrences.
Thanks, yes. To get back to the "We do still read Assembly code in the world of compilers" analogy, in the case of LLM usage, the observable behaviour is...
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.
I’d love to see some numbers on this, but this is not my impression from the communities I participate in (such as the Elixir forum.). Amongst programmers who are employed, I suspect it is a majority at this point who use agents to write code. It is hopefully a small minority who never read code, but it’s certainly growing.
There is a huge gap between "uses agents" and "never reads code to the point that it isn't even needed to design the language to be human-readable anymore".
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.
this is what grinds my gears with gleam. afaik its not really possible to interact with elixir libraries? A project exists to try to make this 'easier' but the fact that it was not baked-in as first class is a huge smell to me https://github.com/gleam-lang/mix_gleam/
Perfect example: Clojure. Clojure is the textbook esoteric programmers dream... but it's SUPER easy to sell and integrate in a typical Java shop. Why? Clojure is Java. You can use everything on Maven. You can interop with any Java tooling. No hacks or BS required... it's a native compatibility. The fact that the Gleam did not opt for this level of congruence is mind boggling to me.
I could be wrong btw so please correct me if I am. I am genuinely interested in using Gleam in place of Elixir (I think they nailed syntax and got rid of a lot of bullshit) but it is unfortunately not a drop-in replacement. It should be.
There are two sides to compatibility with Elixir: using Gleam in Elixir and using Elixir in Gleam. The former is harder, the latter is easier (with caveats).
Using Gleam in an Elixir project did/does rely on mix_gleam. I've used it some years ago and it worked then, but I haven't had recent experiences. There is a pull request[0] to Elixir to add built-in support for Gleam and as I understand it the Gleam team have made several changes to Gleam tooling to facilitate it, but it's unmerged as of now.
Using Elixir in a Gleam project is just an external function away, just like using Erlang or JavaScript (when using the JS target). E.g.
You can also write .ex files in your codebase and use functions from them as externals and they'll be compiled by Gleam.The two main issues on that side are macros and structs. Since Gleam doesn't know about Elixir source or Elixir macros, you can't use them directly. But you can have an .ex file that uses macros and then you can call functions from that file. Structs are trickier, because they're just dynamic maps with a special key-value pair, and maps in Gleam (called Dict) have fixed types for the keys and values. That means you can't model a struct as a Dict. Gleam uses records for its own custom types, so what you can do is either use records on the Elixir side (with the Record module or by hand), or map the Elixir side data structures to be more palatable for Gleam (and vice versa) in your external functions --- which is what you generally do with externals anyway. Of course, if you only intend to pass the Elixir structs around and then back to Elixir, you can model them as external types that are then opaque to Gleam.
[0] https://github.com/elixir-lang/elixir/pull/14262
is this not adequate?
https://gleam.run/frequently-asked-questions/#Can-I-use-Elix...
https://github.com/lustre-labs/lustre for the frontend. The backend uses wisp
if the ai is writing everything wouldn't it be better to choose a more popular language?
Exactly the opposite -- in a lot of ways, mainstream languages represent a compromise that gives the worst of all worlds for the benefit of popularity. With AI, you can take advantage of unpopular esoteric languages that have measurable advantages over mainstream languages. Before, the choice for a mainstream language was too strong because of network effects. Now with AI those effects don't matter as much, so being mainstream isn't as much of an advantage.
The copious training data on mainstream languages doesn't really translate as a network effect, and therefore is kind of a red herring because the AI can use all that training on new languages as well. e.g. if you use a esoteric language that is vaguely object oriented, the AI will use its vast training on object oriented programs and apply it to your language instead of falling over because your language isn't Python and it doesn't have training data on it.
Moreover, the AI is trained on copious amounts of PL research, so it's not like the ideas in a new language are completely new to it.
Another BEAM-based language, Elixir, came in first in a recent agentic coding study: https://dashbit.co/blog/why-elixir-best-language-for-ai
In that Tencent study less common languages got easier problems. Which explains why racket also performed suspiciously well in it. The authors recognize the problem themselves. I like elixir, but it's imo embarrassing how often elixir people cite that study despite it not actually supporting what they claim.
A much more recent and imo more realistic comparison of different languages with ai, is openai's study reimplementing sqlite in different languages: https://openai.com/index/low-resource-programming-languages/
That showed about what we expect, that popular languages like python, javascript, java, C#, etc do best, while less popular languages like Common Lisp, Ocaml, Zig, etc do slightly worse. But the difference is small enough I'd still just choose whatever language and ecosystem I know best that is appropriate for a project.
What they did is they gave the AI a huge pile of docs and said "implement this". But they didn't give the AI any tests as part of its objective. I was under the impression it's generally common practice to use a test-driven development approach with AI, so I think it would have been more representative for them to have split their test corpus in half: one half it could see during implementation, and then the could test on the other half.
Also, they restricted access from the internet, so I think this would have disadvantaged less popular languages.
I would definitely be skeptical of a study that finds using an LLM/agent to write sqlite in JS being better than writing in Zig, but it strongly depends on what “better” or “worse” mean.
It means how much of the sqlite test suite it passed. They were just measuring correctness, not performance or memory consumption, where of course Zig should win.
But the aim of that experiment was measuring correctness of llm written code in different languages, so used sqlite as a benchmark considering it's fairly complex software with a comprehensive test suite. It is not suggesting that because a language scores better on that benchmark it'd be better suited to writing the next sqlite, due to obvious other factors like performance...
A more popular language like what? The more popular choice that I could think of was typescript and the world around typescript and javascript is so big and fragmented I think you'd end up with it the ai doing things in different ways in different places. Gleam is a smaller ecosystem but it also just feels better organized and more consistent which helps for keeping things consistent in your app.
Why's that?
Lots and lots of production code to train AI models.
That mindset is a bit dated when models can pull up docs for a few years now. You can even have it write itself a little guide for lesser known languages within its own agents file.
Programming models have been sophisticated enough for some time to not be restricted to specific languages. It's rather like the difference between a junior developer (who knows how to use a specific language) and a mid developer (who knows who to program generally).
Thanks for creating Gleam!
Is there any research that supports what you are saying here? I agree it mostly works, but I’d expect more API hallucinations and test cycles at a minimum.
No problem!
I don't have anything formal to share, but in my testing I've found it works much the same in all languages now.
The entire gleam language tour fits comfortably in a modern LLM context window. You're one web search away from "training" it yourself.
I'm not sure how much that matters. I suspect and anecdotally hear/see that compiler errors and docs are as/more important.
Too much schlock in the manifold, IMHO.
What's the fuckin point of any language ergonomic if you're not reading or writing it.
Not sure why you're asking this? But i mean if a language is more readable and has good typesafety it's easier for llms to understand, plus a lot of times you want to read and understand it even if you're not typing it out yourself
More ergonomic languages burn fewer LLM tokens to get the same result.
That's also not true at all. The most efficient languages for an LLM are the ones that have the largest datasets to reference. It knows the shape of a billion lines of Python. There's no evidence to suggest that "a more ergonomic language" burns less tokens cause it probably has to do multiple sweeps to get it "right". Otherwise some "agent/token efficient" language would've already been built and we'd all be using it. The defacto are just the most popular languages and that's not a coincidence.
Only if they gain that ergonomic advantage without complicating flow of control. Metaprogramming is costly for example, in the past so have been operator overloading and lazy evaluation.
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?Yes Gleam allows you to do f(arg, _)
See the relevant docs: https://tour.gleam.run/everything/#functions-function-captur...
But that's a single argument right?
Seems more limiting than the closure way. Scala allows multiple _ but in turn that doesn't allow changing ordering.
TBH, I feel this stuff is not really worth it,
I think the single hole version is a good compromise compared to actual currying or multiple holes, since it's strictly better than something like first or last argument threading (e.g. ->, ->> in Clojure), easier to reason about than currying, and in my experience most of the time you'll only be dealing with one argument to pass piping anyway. Anonymous functions are fine for the cases you need more flexibility.
Are there any physicists out there who are reminded of abstract index notation for tensors?
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?
As I mentioned in my other comment, they do have partial application with _, and it works like a charm for piping! It's automatic currying which is absent.
And that's fine, because currying forces you into impossible tradeoffs when choosing argument order.
Ymmv, but you can get pretty far with a convention: order arguments by _how likely they are to be closed_ within any given context. As a full-time F# developer that covered >95% of what we were doing.
An alternative is providing variations on a function that "bundle" sets of arguments, and then making the bundle the first parameter, but that only makes sense when the "bundles" occur together a lot.
I would rather see syntax to make partial application on arbitrary named or positional slots as ergonomic as possible. How much has that been explored by existing languages?
What I've seen: (A) anonymous functions with placeholders (see above), (B) currying (ML), (C) binding variations defined with the function itself (Scala, I think?).
One approach that I haven't seen yet (maybe some language has it?) is named bindings for arbitrary partial application. I _think_ that would be a little tighter than anonymous functions, but I'd need to see it in action.
But Haskell has nice little functions for switching argument order, and people can easily make them in other currying languages.
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.
Tangent: the correct approach looks like filtering the suite down to a single test rather than running individual tests independently.
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.
Fair point, I am with you on that. I guess just had a bad first impression on drama that I've seen as a spectator through the public channels that stuck.
That could be repaired, just don't care enough to spend time there again I guess.
Couldn't agree more with this. Having ideals and principles isn't a bad thing, we all do.
I for one am thankful for their warning. Saved me precious time.
Suggestions about cool projects are just as important as warnings about uncool projects.
Yes, it's just that I don't deem them uncool.
Same as art by Hitler... if I would like it, I would like it, doesn't matter that I think he was one of the worst human beings.
So: I just argued, that there is a third way to view it.
You may, of course, see it completely differently and deem this project "uncool" for whatever reasons you want!
What kind of activism? Isn't activism just "doing something to try and make a larger change"?
Does "larger [political] change" need to run sidecar to a programming language?
I wasn't particularly aware of that to be honest. What kind?
I saw a thread once from the language creator and community owner that left an impression on me https://news.ycombinator.com/item?id=46614727
Wait, people are upset because they have a code of conduct?
People are upset because their "code of conduct" extends far beyond the reasonable purview of the project.
You may not participate if you hold and espouse ideals contrary to theirs in unrelated spaces.
Read the CoC again: https://github.com/gleam-lang/gleam/blob/main/CODE_OF_CONDUC...
It doesn't police peoples' personal beliefs outside the community. It only says that while participating in the community you agree not to harass people and try to contribute in a positive way.
I wonder if you have past experiences that are coloring your interpretation of this, because I'm really unsure where you're getting any of this from.
Eh, the controbutor covenant thing does have a tendency to attract people that are really into culture war and internet drama.
That said, their CoC does not block anyone from merely using the language.
People working on an open-source language aren't 19-year-olds on twitter, you're using the wrong heuristic here. They're there mostly to talk programming and work on a project together. The CoC is pretty standard language that you'd find at most conferences you attend. It specifically enumerates bigoted actions because several contributors are members of the LGBT community. The last thing many of them want is to deal with culture war nonsense seeping into their fun hobby.
> People working on an open-source language aren't 19-year-olds on twitter
You don't say? https://x.com/louispilfold
> "the maintainer is a legitimate communist. i will not be supporting this language"
What type of individual do you suppose attaches their identity to this type of quote?
I mean, sure he's on Twitter but he's in his 30s...
> The last thing many of them want is to deal with culture war nonsense seeping into their fun hobby.
This is bullshit.
Typically we are talking about the same category of people that become Reddit mods. Those are full blown adults where internet drama and culture war nonsense is their actual hobby. The open source thing beneath it is the side project.
It's the reason why I avoid getting involved with open source communities like billionaires avoid taxes.
That said, my original point is not to avoid Gleam as a language. The language itself looks pretty interesting. You don't need to stare at the CoC to use the language.
I am honestly a bit confused because this whole comment chain looks like someone is starting culture war and drama? But you mean that the people who use gleam tend to be into culture wars, not the OP poster in the chain?
> But you mean that the people who use gleam tend to be into culture wars, not the OP poster in the chain?
Er... No?
I think I was clear that you can use the language without getting involved with the drama related to the community behind the codebase.
I'm gonna be honest, based on this thread it sounds more like the CoC is repelling people that are really into culture wars and internet drama.
Culture wars come up in every Gleam thread. How often do you see culture war comments in a Rust, Elixir, Javascript, Etc thread? Essentially never. The Gleam founder's bigotry is a distraction at best.
I dunno about the others, but the icon for the Rust discord is the Rust logo superimposed on the pride flag, so they are not subtle about their position on the topic, and it has therefore been a topic of discussion in that community.
The reality of online spaces is, you can either make Nazis aware they're not welcome at the door, or you can let them know when they start making trouble. Either way, if you want to keep your online community copasetic, eventually you have to tell Nazis to fuck off.
What bigotry?
I’m out of the loop.
Whatever confirms your priors.
What is interesting here is that most likely I am on the same side of the political aisle as the people there.
I still find that sort of talk insufferable. Gives me mid-2010s "woke" bullshit vibes (god the slang of my contemporaries is horrid).
Contemporaries? "Woke" has been part of AAVE for almost a full century.
I’m guess those are not the people he/she considers their “contemporaries”, who likely adopted that language much more recently and use it in a different way.
What does the code of conduct say?
I didn’t see a link to it.
[dead]
Where is the "activism behavior"? All I see in the thread is other people whining because they disagree with the Gleam community's values.
Agreed. Treat people well seemed to be the Gleam desire.
The counterarguments from the other party (seemed like one person with multiple accounts to me) were about their disbelief in trans people and the idea behind the Black Lives Matter movement (coupling it with some organization that copied the name and stole some donations)
Couldn't find it either, and my experience with the gleam community is that they're very welcoming and positive people.
I am on that thread as well. The issue with these "codes of conduct" isn't that they exist, it's that their purveyors force the "code" upon every participant regardless of forum.
If you don't support their special interests in completely unrelated venues, you are persona non grata and will either fall in line or be excommunicated. It's a sophisticated form of control via identity politics.
I think you're seriously overreacting; you don't need to believe the same things that they do, all the CoC states is that if you want to engage with the community, you agree not to harass people. Every community has similar expectations; having it in a markdown just makes it more explicit.
Sure, you don't need to "believe" the same things they do, but if you are vocal about your ideals on Twitter, for instance, you are unwelcome.
"Don't publicly disagree with my ideals or I will use my little fiefdom to destroy you."
You might be letting your personal experiences pollute things. The CoC never says that. It's anti-harassment language, and specifically enumerates what that might look like. Some contributors are members of the LGBT community, and I'm sure don't want to debate their personal identity when they're there to contribute to a project and write code.
I... Think many of us would like evidence to back this up. Can you demonstrate that the Gleam community has done this, specifically? Because it really seems, to me at least, that this is a bit of straw-manning.
I mean, yeah — people won't want to be in community with someone who transgresses against their social norms and values. Freely choosing with whom you associate is not a "form of control". You're still welcome to use the project.
Sounds to me like a lot of divisive American politics, as usual.
I have no problem with a community setting whatever acceptance criteria they like.
If the license did the same, I could see a case of being a bit of overzealousness.
I couldn't find if that was the issue, but if your problem is that the creator and the community have political opinions and don't like people with incompatible ones, then that's just society...
> but if your problem is that the creator and the community have political opinions and don't like people with incompatible ones, then that's just society...
No, I am fine with incompatible views and I often seek them in order to grow. I do not enjoy echo chambers and I usually prefer and welcome disparate, including contrarian, opinions.
It's more like I don't want Ideology served with Programming Language, it feels like a distraction to me when I am in that mode. I usually consume Ideology under a different context, where I find it more productive and can contribute better to it.
I think you have a reasonable position here, so I understand where you come from.
I find this whole thread here interesting because until today I wasn't confronted by any of this, even though I joined the Discord and had a pleasant time (and will keep doing).
So I guess all I have to say on this is I don't think the "ideology" is that much served with the programming language. Yes I read that there's a code of conduct and that annoyed some people. But like I downloaded Gleam, I coded with it, I talked to people, and the thought police didn't knock on my door. So I guess what I mean is that it feels a little overblown.
Thanks for understanding it, and yes not everyone draws the line at the same boundaries.
Once in a while I try to push my boundaries, but then again I like to choose where I do this. For this one, I prefer not to do it in a work adjacent environment with strangers on the internet.
That aside, the language sounds fun hope you create cool things with it!
> I don't think the "ideology" is that much served with the programming language
Their ideology is literally on the front page of https://gleam.run/
On the front page or not, I think nchagnet's point is that, in practice, he doesn't bump into it much.
Whether that's good enough for you or not is up to you.
you mean this?
> "As a community, we want to be friendly too. People from around the world, of all backgrounds, genders, and experience levels are welcome and respected equally. See our community code of conduct for more. Black lives matter. Trans rights are human rights. No nazi bullsh*t. "
> I don't think the "ideology" is that much served with the programming language.
But it's in the language, and I'm almost not joking.
If you think about it, Gleam encodes worst possible meaning of communism. Those kind where one size fits all because there is no other size. Utopia where everybody are equal because there is no way to be better.
Also there is a funny thing about it. In this sense Gleam surpasses even Go, which is deliberately built to make developers as interchangable and average as possible. Can we count that as an example of horseshoe theory?..
Yes, people who build programming languages view PL design as a form of self expression; like artists who use a painting to capture and communicate the beauty of a flower, PL designers try to communicate beautiful system design using languages.
So it's very often the case that languages built by a single dev or small team often reflect their worldview and opinions. Take a look at Urbit by Curtis Yarvin, a man who believes in neo feudalism built a programming system that expresses neofeudalistic ideals pretty explicitly. Programming language design is about organizing systems of information to perform useful work, and its a very short hop from there to thinking about organizing systems of people. Or vice versa.
> creator and the community have political opinions and don't like people with incompatible ones, then that's just society
Why are my political views relevant? This is a programming language. Nobody is popping into the Gleam issue tracker and mentioning politics, nobody is violating the "code of conduct" there.
The "code of conduct" exists solely to lambast people who disagree with the author's special interests in other irrelevant spaces. This is the "paradox of tolerance" in codified form.
I mean it's only relevant if you bring it with you in their community. You don't sign your soul away when you download the compiler. Do you have the same issue with all the ToS asking you to not be a nazi and whatnot on a given platform?
Maybe you could be specific, instead of just spreading FUD? I read through the discussion you linked, and I have no idea what you’re talking about, so to me your comment comes of as just FUD.
On the Gleam homepage under the Friendly heading it says “Black lives matter. Trans rights are human rights. No nazi bullsh*t.”
That’s probably what the OP meant by “activism”.
https://gleam.run/
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?
"Contribute to their codebase" includes bug reports and seeking help with errata and other issues.
It might be problematic to use a language where needed help could be preceded by Twitter or HN background and allegiance check.
> "Contribute to their codebase" includes bug reports and seeking help with errata and other issues.
That is exceedingly rare. The vast majority of times you will either find your answer online to work your way around issues.
> It might be problematic to use a language where needed help could be preceded by Twitter or HN background and allegiance check.
I would remind you that we have LLMs now. One of the greatest gifts of LLMs is not having to rely on talking to people online to figure out issues when using a language/framework/library.
Both searching for answers online and consulting LLM’s depends on prior human works or interactions, and (from what I know) their feasibility scales with the language’s popularity. I should expect both approaches to work much more reliably for Perl or Python than they would for Gleam or Newlisp.
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
That is like arguing everyone should master Assembly when using high level languages. :)
Which tangentially brings up another analogy: many high level languages don’t compile directly to assembly but to an intermediate language first (LLVM). We don’t read the LLVM code ourselves.
But LLVM compilation is deterministic. LLM code gen isn’t.
Only when not used alongside PGO data or as a JIT, as its inputs are not deterministic in first place.
No it isn’t. I think you read into my comment too much.
I don't want to say what people should and shouldn't do, and a world in which all the world's professionals spend their days talking to sycophantic machines with only a loose commitment to the truth is really funny to me.
But, high level languages don't really lose precision in any way that matters (except when you need extreme performance, resistance to timing attacks, or niche stuff like that). Natural language on the other hand loses precision that's usually important, so I don't see how your comparison is valid.
Who said “everyone”?
We do still read code. => We do still read Assembly code in the world of compilers.
Not seeing it. “We do still read code” implies neither that every single person does, nor that they need to master the language being read. Taken together, it seems to me that you need a fair bit of extrapolation (or a presupposition that programming languages are already obsolete when that’s the very point being contested) to make the analogy work.
And indeed, some people still do.
Deterministic vs None-Deterministic, understanding what compiled code does also is possible without Assembly knowledge, not so necessarily with models, where I do like to at least understand what has happened and quite often find a crime or five.
Heck, OpenAI can't even get their models to reliably do what they intend, so yeah.
AOT without PGO, manual memory management, traditional optimisations vs AOT with PGO, JIT, tracing GC, machine learning optimisation passes.
Which have what to do with the relationship between assembly and the higher level language?
It is the answer to you Deterministic vs None-Deterministic.
If you don't get the difference, I get there isn't much that you know about how instruction selection works, across all those approaches.
Ok, I feel you know what this is actually about, but here spelled out:
Do any of the optimizations you mentioned affect the underlying behavior of the run code? Semantics...
If not, it doesn't fit to LLM use, where this is very much the case. We can talk about bugs in compilers and undefined behaviours and so on and so forth all the livelong day, but you know as well as I that this is not of the same scope of impact.
I could and in the past would have written a long diatribe about how pure compilation to assembly is deterministic, thus making this not really suitable and that while yes, there are things like JVM that aren't 100%, we have contracts, docs, specs and, because of them, an expectation of consistency that LLMs do not deliver. I did not because I thought that was not necessary, but see my error now, that is my mistake.
There is the observable behaviour, and the machine code instructions that actually get generated in every single case for the same kind of text input.
Which for example, unless you can exactly replicate the world every single time a PGO data gathering session is done, there are no guarantees that the compiler will generate exactly the same machine code pattern, when given various PGO files generated at different occurrences.
Thanks, yes. To get back to the "We do still read Assembly code in the world of compilers" analogy, in the case of LLM usage, the observable behaviour is...
Assembly naturally,
https://www.phoronix.com/news/Frame-X11-Server-Assembly
Relevant Calvin & Hobbes strip:
https://static0.cbrimages.com/wordpress/wp-content/uploads/2...
Wow I bet this one is ironically taped up on a lot of mathematicians’ office doors since LLMs started proving lots of theorems.
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.
I’d love to see some numbers on this, but this is not my impression from the communities I participate in (such as the Elixir forum.). Amongst programmers who are employed, I suspect it is a majority at this point who use agents to write code. It is hopefully a small minority who never read code, but it’s certainly growing.
There is a huge gap between "uses agents" and "never reads code to the point that it isn't even needed to design the language to be human-readable anymore".
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.