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.
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.
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.
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.
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.
Yeah. I know. I use it every day. That doesn't answer my question. Why would I want to write something in Gleam if I want it to run in a JavaScript engine? When would that ever make sense? Could you please just engage with me in good faith?
Multiple compilation targets require increased implementation complexity so you would think they would have a good reason for when you would compile to one target or the other. I couldn't find any information about it on their website, so I was hoping you would actually respond with something helpful rather than... that.
I use it mostly for web APIs / services, it's great for that!
Interop is not seamless since Elixir does not have the same static type system, but it is possible and that does help sometimes. When resizing images for example, I fall back to Elixir's bindings to libvips. I've also used Oban from Gleam in the past.
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".
Informally, commas are "misused" regularly even by native writers, and almost no one notices or cares unless the misuse is frequent and egregious.
Formally, most comma use is an issue of style, not grammar, and style guides differ on when they should and shouldn't be used. The main rule that's actually a matter of grammar is this: commas cannot be used to join two "clauses" (phrases which could be independent sentences) without a conjunction.
i dont think anyone actually cares unless you are in english class or someone wants to feel smug on the internet (you can ignore the 2nd one completely).
So it's "You do need a comma before a conjunction, if it connects two independent clauses" then — "you need a comma before a conjunction" and "it connects two independent clauses" are two fully formed simple sentences, each having its own subject and predicate. See what I mean?
And almost nobody writes sentences like "I love her and she loves me back" with a comma before "and".
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.
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.
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
...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?
Yes! https://discourse.ubuntu.com/t/gleam-and-the-value-of-small/...
Here's his presentations page: https://giacomocavalieri.me/speaking
not from a presentation but he made this nice little syntax postcard https://cdn.bsky.app/img/feed_fullsize/plain/did:plc:vzaxc2i...
yea he is super nice.
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
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 feel like Go would be a great backend target for Gleam
I am working on a language called blasphemy which intends to do this.
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.
Amazing news! Thank you!
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.
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?
You can do a lot more with JavaScript than building UIs.
Yeah. I know. I use it every day. That doesn't answer my question. Why would I want to write something in Gleam if I want it to run in a JavaScript engine? When would that ever make sense? Could you please just engage with me in good faith?
Multiple compilation targets require increased implementation complexity so you would think they would have a good reason for when you would compile to one target or the other. I couldn't find any information about it on their website, so I was hoping you would actually respond with something helpful rather than... that.
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.
I use it mostly for web APIs / services, it's great for that!
Interop is not seamless since Elixir does not have the same static type system, but it is possible and that does help sometimes. When resizing images for example, I fall back to Elixir's bindings to libvips. I've also used Oban from Gleam in the past.
gleam is very much a language of "no" which if you like that, cool, if not, also cool :)
Congratulations to the team! I love Gleam and am genuinely having fun every time I write Gleam code.
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.
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".
Apart from in Australian [0] and Canadian [1] English, where it is generally optional, but used where it can increase clarity or meter.
[0] Australian Government Publishing Service's Style Manual for Authors, Editors and Printers, ISBN: 978 0 7016 3648 7
[1] The Canadian style: a guide to writing and editing https://archive.org/details/canadianstylegui0000unse
As a non-native English speaker I'm always so self conscious when using commas, it feels like I'm always using either too many or too few
Informally, commas are "misused" regularly even by native writers, and almost no one notices or cares unless the misuse is frequent and egregious.
Formally, most comma use is an issue of style, not grammar, and style guides differ on when they should and shouldn't be used. The main rule that's actually a matter of grammar is this: commas cannot be used to join two "clauses" (phrases which could be independent sentences) without a conjunction.
So putting the commas in "I'm eating a hot dog, she's listening to radio, we are having a wonderful time." is grammatically wrong? TIL, I guess.
i dont think anyone actually cares unless you are in english class or someone wants to feel smug on the internet (you can ignore the 2nd one completely).
Don't worry about it.
The lack or excess of commas doesn't upset any reasonable person in the slightest.
You're doing fine. English grammar pedants speak infrequently. Mostly due to the disinterest of the listener.
As a native English speaker, same.
You do need a comma before a conjunction if it connects two independent clauses.
So it's "You do need a comma before a conjunction, if it connects two independent clauses" then — "you need a comma before a conjunction" and "it connects two independent clauses" are two fully formed simple sentences, each having its own subject and predicate. See what I mean?
And almost nobody writes sentences like "I love her and she loves me back" with a comma before "and".
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.