to those curious, erlang abstract form[1] is the AST representation used by the erlang compiler/etc. per [1], you can see that it's canonically made of erlang terms, and you have easy access to routines for manipulating this representation from the standard library; it's really comfy when you need it! it's also the target elixir compiles down to, and the representation manipulated by parse transforms, which in base erlang are the way syntactic sugar (notably qlc[2] and some of the more cutesy pattern matches in merl[3] (which, in turn, manipulates the very same representation to do its job. very meta!)) is done.
most BEAM languages actually settle on erlang abstract format. you'd think core erlang would be more common since it feels more like a traditional functional IR, but basically only LFE does this, because it's a moving target without any particular stability guarantees from release to release.
Erlang is one of those runtimes I've loved since learning about it all the way back in 2008, but I never took time to learn the syntax, but Elixir and Gleam have had me fiddling with the Erlang VM over the years. Happy to see Gleam growing into maturity.
I just learned Erlang this year and I love the syntax. Ending expressions with periods took getting used to, but capital first letters distinguishing variables, non-rebindable variables, semicolons between function clauses, a lack of boilerplate (defmodule et al), a fraction of end keywords, commas separating expression, ... all make for a very fun to use and ergonomic language, IMO.
I haven't tried Gleam yet, though. I'm interested in the focus on simplicity but a little wary because I understand they sacrificed niceties to minimize the language footprint, e.g., pattern matching in function heads. I intend to give it a shot the next time I'm greenfielding something.
Erlang is my favorite functional language out of all the ones I've tried. The matchers, guards, etc are all done very well. But I don't like functional. I used to think it was cool, gave it a real chance using Erlang for years, and eventually decided it's not a good fit for many use cases. Like at some point the neatness of doing all loops as recursion wears off and it's just tiring. It's not like CS algo homework, and even there you often want DP/memoization.
I'm the same. I thought I was an oddball because so many people seemed to prefer Elixir but I like Erlang and its syntax. I wish I had more chances to use it at work but so far it's just been for hobby projects or playing with.
I'd say if you know and like Rust, then Gleam should be easy to pick up but otherwise I'd try Elixir. You can learn most of the language in a few days and be experimenting with BEAM and supervision concepts basically on day one. As a learning exercise I think its worth peoples' time because actors/processes are one of the concurrency models you don't see everywhere but solve interesting problems well.
I don't think that's the case, Rust and Gleam have almost nothing in common beyond having static type systems, and those type systems are very different too.
Shout out to Giacomo's twitch streams. He has taught me about some features of Gleam, Rust, and on top of that he's just a very chill person. He takes time away from his focus to answer questions politely and without judgement. There are dozens of programming streams where the streamer forgets to leave their ego at the door and he is not one of them. I highly recommend following it.
The Gleam community is generally very very nice. I maintain about 200k lines of Gleam[0][1], and they have generally accommodated even my stupidest posts on Discord.
The language itself is as welcoming. Even LLMs are less cranky and output nicer code, not having to deal with React.
Gleam is such a beautiful language. I wish I had the opportunity to use it more. If it could compile (transpile) to a native target like rust or go, it would be truly perfect.
Go's garbage collection isn't well suited for an immutable language like Gleam, so the performance would likely be disappointing compared to other targets.
I love this language, but I have to wonder how much harder it is to grow a niche language these days when everyone is just telling Claude what to build for them. It seems like LLM friendliness is going to become the new benchmark for adoption if it hasn't already, and I find that pretty sad.
The title is a bit misleading because one might imply that Gleam no longer compiles to something Erlang can use (not true).
From the article:
> Over the last few months Giacomo Cavalieri has entirely rewritten Gleam's Erlang code generator that has an entirely different design, and most notably, outputs a different format. Previously Gleam generated Erlang source code, now it generates Erlang abstract forms.
This raises an obvious question. Why Gleam team weren't doing that in the first place? Obviously they didn't have direct Gleam AST -> Erlang source pipeline, they must have had to build some their own custom Erlang AST representation that they then translated into the source code.
We did not (and still don't) have an internal Erlang AST representation in the compiler. Previously we did have a Gleam AST -> printing algebra -> Erlang source pipeline, now we construct a buffer of bytes with the data encoded as Erlang Term Format.
Source was the previous target as at the time Erlang Abstract Terms was not established as the go-to format (Core Erlang was more popular but it did not have a stable API outside of the BEAM, so Gleam's in-Rust compiler could not construct it), and due to the newness of the language having an "escape hatch" where one could abandon Gleam and eject to Erlang was highly valuable. It also meant we could use the Erlang build tool until the Gleam one was ready for use.
I will just say, as of recently, especially thanks to AI, I've been doing projects in Gleam, I am on third Gleam project and it has been very pleasant experience. It takes longer to write but it is much shorter, easier to follow and much more easier to update and change.
> "Transpiler" means a compiler that outputs a human-readable format, such as source code. It's a cool sounding word, but most the time people use it to imply that a given compiler is in some way inferior. This is very silly, as there is nothing about compiling to a human-readable format that makes a compiler easier to implement.
Ok but this footnote comes at the end of a paragraph describing how the previous transpiler implementation was inferior to the new compiler. It's ok to make these distinctions.
The old one had an inferior implementation, but that is unrelated to the output format. We also have a new Erlang source code generator that is used predominantly in the compiler test suite, and it too is superior.
Gleam is a simple functional programming language which leans into static typing , friendly tooling, and a one-way-to-do-it style. You'd want to use it if you enjoy the programming experience it provides.
It is if you want Erlang but typesafe and with a modern syntax. And why would you want Erlang? Erlang was built for making it easy to build fault-tolerant concurrent applications, for example in telecom.
Before the "and", "but", "so", "while", etc. — while most European languages, indeed, (usually) require commas before conjunctions, English is following a somewhat reversed convention. Well, at least the author remembered that they need to omit a comma before "that".
idk, i'm not sure about wording.
erlang abstract form still is erlang source, it's ast of erlang source text.
one call to erl_prettypr:format and text source is back.
word 'transpiler' is still there and there is nothing "pejorative" in it, it's transpilers all the way down everywhere.
but talking pejorative, i was surprised.
my opinion of gleam was already pretty low, but i did not expect to see post-1.0 compiler emitting text erlang source.
maybe it's not that good of idea to implement compiler in language completely foreign to target ecosystem.
I don't think your "it is source as you can convert it back into source" argument holds water as all the Erlang formats can be decompiled into Erlang source code, including the final bytecode itself.
I think you're overthinking the cost of compiling to source, and also underestimating how common it is.
I have never seen a software developer be insecure about their manhood because of the programming language they use. This is equal parts funny and sad.
to those curious, erlang abstract form[1] is the AST representation used by the erlang compiler/etc. per [1], you can see that it's canonically made of erlang terms, and you have easy access to routines for manipulating this representation from the standard library; it's really comfy when you need it! it's also the target elixir compiles down to, and the representation manipulated by parse transforms, which in base erlang are the way syntactic sugar (notably qlc[2] and some of the more cutesy pattern matches in merl[3] (which, in turn, manipulates the very same representation to do its job. very meta!)) is done.
most BEAM languages actually settle on erlang abstract format. you'd think core erlang would be more common since it feels more like a traditional functional IR, but basically only LFE does this, because it's a moving target without any particular stability guarantees from release to release.
1: https://www.erlang.org/doc/apps/stdlib/erl_parse.html#t:abst...
2: https://www.erlang.org/doc/apps/stdlib/qlc.html#q/2
3: https://www.erlang.org/doc/apps/syntax_tools/merl.html
LFE used to compile to core Erlang, but it now also compiles to abstract forms.
https://github.com/lfe/lfe/blob/387d0aa1092bdda0ca17481869e8...
https://github.com/lfe/lfe/blob/387d0aa1092bdda0ca17481869e8...
Erlang is one of those runtimes I've loved since learning about it all the way back in 2008, but I never took time to learn the syntax, but Elixir and Gleam have had me fiddling with the Erlang VM over the years. Happy to see Gleam growing into maturity.
I just learned Erlang this year and I love the syntax. Ending expressions with periods took getting used to, but capital first letters distinguishing variables, non-rebindable variables, semicolons between function clauses, a lack of boilerplate (defmodule et al), a fraction of end keywords, commas separating expression, ... all make for a very fun to use and ergonomic language, IMO.
I haven't tried Gleam yet, though. I'm interested in the focus on simplicity but a little wary because I understand they sacrificed niceties to minimize the language footprint, e.g., pattern matching in function heads. I intend to give it a shot the next time I'm greenfielding something.
Erlang is my favorite functional language out of all the ones I've tried. The matchers, guards, etc are all done very well. But I don't like functional. I used to think it was cool, gave it a real chance using Erlang for years, and eventually decided it's not a good fit for many use cases. Like at some point the neatness of doing all loops as recursion wears off and it's just tiring. It's not like CS algo homework, and even there you often want DP/memoization.
Edit: pure* functional
2 replies →
I'm the same. I thought I was an oddball because so many people seemed to prefer Elixir but I like Erlang and its syntax. I wish I had more chances to use it at work but so far it's just been for hobby projects or playing with.
I was fortunate enough to use Erlang professionally for a couple of years. I agree: the syntax is quite comfortable.
I'd say if you know and like Rust, then Gleam should be easy to pick up but otherwise I'd try Elixir. You can learn most of the language in a few days and be experimenting with BEAM and supervision concepts basically on day one. As a learning exercise I think its worth peoples' time because actors/processes are one of the concurrency models you don't see everywhere but solve interesting problems well.
I don't think that's the case, Rust and Gleam have almost nothing in common beyond having static type systems, and those type systems are very different too.
https://gleam.run/frequently-asked-questions/#How-does-Gleam...
17 replies →
Shout out to Giacomo's twitch streams. He has taught me about some features of Gleam, Rust, and on top of that he's just a very chill person. He takes time away from his focus to answer questions politely and without judgement. There are dozens of programming streams where the streamer forgets to leave their ego at the door and he is not one of them. I highly recommend following it.
Thank you so much!! Reading this really made my day <3
Thank you for Squirrel as well!
massive +1, been watching his streams from time to time, and the man is the definition of a humble and chill person
Aww thank youuu
The Gleam community is generally very very nice. I maintain about 200k lines of Gleam[0][1], and they have generally accommodated even my stupidest posts on Discord.
The language itself is as welcoming. Even LLMs are less cranky and output nicer code, not having to deal with React.
[0]: https://blisswriter.app/
[1]: https://nestful.app/
...And he animates his presentations by hand-drawing each frame transition, which speaks volumes.
[edit - this might have been ambiguous. I meant that it shows he really cares about the fine details.]
Do you have an example you especially like?
3 replies →
yea he is super nice.
Thank you! Too kind
Gleam is such a beautiful language. I wish I had the opportunity to use it more. If it could compile (transpile) to a native target like rust or go, it would be truly perfect.
I would love to see support for wasm and wasi.
I am working on a language called blasphemy which intends to do this.
Looking forward to be able to claim to be “proficient in blasphemy” on my cv! /s
1 reply →
I feel like Go would be a great backend target for Gleam
Go's garbage collection isn't well suited for an immutable language like Gleam, so the performance would likely be disappointing compared to other targets.
6 replies →
For that there is Lisette. Close to gleam, compiles to Go.
1 reply →
You just described Lisette. Its very close to gleam, and compiles to Go.
[flagged]
I love this language, but I have to wonder how much harder it is to grow a niche language these days when everyone is just telling Claude what to build for them. It seems like LLM friendliness is going to become the new benchmark for adoption if it hasn't already, and I find that pretty sad.
You know what they say, Gleam is a dream :)
The title is a bit misleading because one might imply that Gleam no longer compiles to something Erlang can use (not true).
From the article:
> Over the last few months Giacomo Cavalieri has entirely rewritten Gleam's Erlang code generator that has an entirely different design, and most notably, outputs a different format. Previously Gleam generated Erlang source code, now it generates Erlang abstract forms.
The title says it no longer compiles to Erlang source. That's true, it now compiles to an IR of the Erlang compiler.
Louis is amazing. So cool to see how he's grown this project since starting it.
I love seeing how gleam gets better and better with every release, sadly I dont have any projects where I could use gleam :(
Pretty exciting change that I didn’t see coming —- I wonder if someone will end up implementing an integration with the Whatsapp Erlang debugger
The only thing that would be needed for this is for 2 flags to be passed to the Erlang compiler. It would be very trivial!
This raises an obvious question. Why Gleam team weren't doing that in the first place? Obviously they didn't have direct Gleam AST -> Erlang source pipeline, they must have had to build some their own custom Erlang AST representation that they then translated into the source code.
We did not (and still don't) have an internal Erlang AST representation in the compiler. Previously we did have a Gleam AST -> printing algebra -> Erlang source pipeline, now we construct a buffer of bytes with the data encoded as Erlang Term Format.
Source was the previous target as at the time Erlang Abstract Terms was not established as the go-to format (Core Erlang was more popular but it did not have a stable API outside of the BEAM, so Gleam's in-Rust compiler could not construct it), and due to the newness of the language having an "escape hatch" where one could abandon Gleam and eject to Erlang was highly valuable. It also meant we could use the Erlang build tool until the Gleam one was ready for use.
Congratulations to the team! I love Gleam and am genuinely having fun every time I write Gleam code.
I will just say, as of recently, especially thanks to AI, I've been doing projects in Gleam, I am on third Gleam project and it has been very pleasant experience. It takes longer to write but it is much shorter, easier to follow and much more easier to update and change.
Amazing news! Thank you!
> "Transpiler" means a compiler that outputs a human-readable format, such as source code. It's a cool sounding word, but most the time people use it to imply that a given compiler is in some way inferior. This is very silly, as there is nothing about compiling to a human-readable format that makes a compiler easier to implement.
Ok but this footnote comes at the end of a paragraph describing how the previous transpiler implementation was inferior to the new compiler. It's ok to make these distinctions.
The old one had an inferior implementation, but that is unrelated to the output format. We also have a new Erlang source code generator that is used predominantly in the compiler test suite, and it too is superior.
...and many other improvements!
I was surprised to find Matt Mullenweg among the sponsors.
What is Gleam? Where would I want to use it?
All I understand from the frontpage is that it's typesafe. Good I guess? Then there is something about Erlang which I never used.
Gleam is a simple functional programming language which leans into static typing , friendly tooling, and a one-way-to-do-it style. You'd want to use it if you enjoy the programming experience it provides.
It is if you want Erlang but typesafe and with a modern syntax. And why would you want Erlang? Erlang was built for making it easy to build fault-tolerant concurrent applications, for example in telecom.
[flagged]
[flagged]
[flagged]
[flagged]
LLM bot.
Did you read the post?
Let me guess: still no string interpolation in a language ostensibly intended for building user interfaces?
Gleam is not ostensibly intended for building user interfaces.
I still don't know what gleam is for tbh. I like it conceptually. But interop with for instance elixir libraries is not as seamless as you'd like.
2 replies →
Then, why is JavaScript a compilation target? If you're not using it on the client-side, then why not stay exclusive to the BEAM?
8 replies →
gleam is very much a language of "no" which if you like that, cool, if not, also cool :)
The misuse of commas is distracting; at least it’s better than reading ai blogs.
Your semicolon would be more effective as a comma followed by "but". HTH
Which commas are misplaced?
Before the "and", "but", "so", "while", etc. — while most European languages, indeed, (usually) require commas before conjunctions, English is following a somewhat reversed convention. Well, at least the author remembered that they need to omit a comma before "that".
13 replies →
idk, i'm not sure about wording. erlang abstract form still is erlang source, it's ast of erlang source text. one call to erl_prettypr:format and text source is back. word 'transpiler' is still there and there is nothing "pejorative" in it, it's transpilers all the way down everywhere.
but talking pejorative, i was surprised. my opinion of gleam was already pretty low, but i did not expect to see post-1.0 compiler emitting text erlang source. maybe it's not that good of idea to implement compiler in language completely foreign to target ecosystem.
I don't think your "it is source as you can convert it back into source" argument holds water as all the Erlang formats can be decompiled into Erlang source code, including the final bytecode itself.
I think you're overthinking the cost of compiling to source, and also underestimating how common it is.
When will they change their image to not look like girl toys?
Imagine a doctor about to do surgery and opening a toy box
I have never seen a software developer be insecure about their manhood because of the programming language they use. This is equal parts funny and sad.
I’m old enough to remember VB developers so unfortunately cannot concur.
It's not surgery is it. It's programming language and their maintainers like it.
I'm struggling to imagine how this even comes up.
Imagine your doctor is about to begin surgery and walks in with a camel, a crab and a gopher.
And a weird little guy who looks like an artist’s eraser.