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.
> Like at some point the neatness of doing all loops as recursion wears off and it's just tiring.
Odd, but I believe you, lol. Elixir's list comprehensions take a `:reduce` option which makes accumulating values a bit more "familiar" and I often use over `reduce`:
for a <- list, reduce: []
acc ->
[a | acc]
end
Not sure if there is something like that in Erlang (or Gleam for that matter).
If you already have a list in Erlang, you can use map and the foldl/foldr reducers. But there's no general for-loop. You're expected to use tail recursion.
Also tbh, I don't like reduce either. I agree with that article posted on HN a while back about devs not liking reduce. Just want to insert into my list or whatever, not have to check how exactly reduce works in this particular language.
Ya, I was saying as an alternative to a more dynamic-looking loop. And I should note that `for` is confusing in Elixir because it is not a for loop, it's a list comprehension. Also, `<-` is actually a match operator and can cause confusion if you think of it as a for loop. I'm actually not sure why they went with `for`. At one point it was `lc`. I do think `for` is better than `lc`, heh.
But yes, I don't hate reduce, but I do try and avoid it in favour of a higher level version if its available. My only real problem with reduce is that I sometimes forget the parameter order, which is why I like using list comprehensions since the accumulator gets labelled.
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.
I think a Rust programmer is more likely to prefer Gleam to Elixir, but I don't think there is much link between Gleam and Rust, and I especially do not thing that Gleam should only be considered over Elixir if you are already a Rust programmer.
You said:
>I'd say if you know and like Rust, then Gleam should be easy to pick up but otherwise I'd try Elixir.
This is way too strong and narrow statement. Gleam is statically typed garbage collected language, closer to OCaml than Rust. Elixir if you like dynamically typed instead.
Nah, the gradual angle is not what makes a type system tricky to implement. Plus we have published a few papers discussing how we are typing Elixir and how our approach is sound.
It's very possible that I'm misunderstanding you! I'm mostly just saying that Gleam is very unlike Rust, so if you pick it or avoid it for Rust related reasons you may not be making the most informed decision.
The languages that Gleam is most like might be Standard ML, OCaml, Elm, and F#.
You seem to be interpreting the statements as technical comparisons of the languages, but ch4s3 was (by my read) commenting on the overall ability of a programmer to jump from one language to another.
That is: they aren't similar languages on a technical level, but if you know Rust, you should be able to make the jump to Gleam pretty quickly.
Aye, I am saying that jumping from Rust to Gleam isn't easy because the languages are so different. "How do I do X in Gleam like I would in Rust" is one of the most common categories of support question from newcomers who assumed they were similar.
I use Rust and prefer Elixir over Gleam because Elixir has Lisp-style macros (Gleam doesn't), uses OTP directly, has the fantastic IEx REPL (Gleam has no counterpart), and has Phoenix, the best web framework I've ever used.
> I'd say if you know and like Rust, then Gleam should be easy to pick up
I think by sentiments like this, people mean if you know unions, records, and pattern matching then you'll more easily pick up another language that has unions, records, and pattern matching.
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.
The concurrency model in Go is also poorly suited to the BEAM's process model. Goroutines share a heap so you can't do a lot of things safely that processes can do. Having independent memory space for a process allows you to free it safely when work is done without GCing everything and you can also safely share data because you have a copy not a ref.
Surprisingly yes! JavaScript's allocator and garbage collection system is quite well suited to immutable programming.
Rust is a very poor compile target as the compiler is slow and not commonly available, and the aspects of Rust that make it good for humans to write make it a poor choice for compilers to target. With humans the produced code is verified, but with a compiler the compiler is what is to be verified, so the inflexibility of Rust are largely a hindrance compared to other native compilation targets.
What lower-level language do you think aside from rust which can be more helpful for the purposes of being a compile target, nim/D both support garbage collection and non garbage collection, so would languages like these be more preferable
I really love gleam and its community and I would really really love if gleam could be more like golang though, which can help it in compiling to machine code
gleam language but with the developer experience of golang (cross portability/small binaries/fast compiled language which is fast to compile) is honestly one of my fever dreams and I would love to know if it can ever be a reality!
For that sort of compilation target more flexibility is beneficial, so C, Wasm, LLVM IR, Cranelift IR etc are better than Go, Nim, and D in my opinion.
> cross portability/small binaries/fast compiled language which is fast to compile
You don't need native compilation to build fast single file executables for a program, there's ways one can achieve this with Gleam today. Bundling the BEAM into your Gleam application executable with something like Gleepack is one option, and this will produce smaller executables than Go will by default for many applications.
I don't get the impression that javascript is among Gleam's targets because of performance.
- server target: BEAM
- client target: js
Once you've covered those bases, you're kind of done.
If the server needs to do something special in an OS process... might as well let the OS mediate that interaction so that it can be fully generic, rather than trying to bend the language around whatever the unknown action might be.
Gleam is my new default language and ecosystem. Until last year, I first reached for .NET on new projects. ".NET everywhere" and such. But Blazor apps are huge and slow. These days I often advocate first for Gleam. With Lustre and Tauri it can run anywhere.
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.
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.
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.
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.
JavaScript is useful in lots of places, and even if one compile target is especially good for in-browser user interfaces that doesn't mean that language is specifically intended for user interface development.
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.
So, you started by making a pointed comment about that the language has no string interpolation when it's ostensibly for building UIs, so I'm not sure why you're surprised you're getting responses like mine or the one from lpil. Gleam is not ostensibly meant for building UIs just because it targets JS, and while you don't get string interpolation in the way you might get in other languages you can go pretty far with the <> syntax.
To answer your question about why you would use Gleam when you're running code in a JS engine, it's the same about any language that compiles down to another, such as Clojure, and you can take your pick of those reasons: preference, syntax, pragmatism, etc. I'm not sure what kind of answer you're looking for beyond that.
I'm looking for the intention behind it. They chose two compilation targets. That made things harder. They had a reason. That's what I'm asking about.
None of your reasons ("preference, syntax, pragmatism") fully explain the situation without more context. Whose preference? What syntax are users even seeing? Why is it pragmatic?
Compilation targets are generally chosen based on performance characteristics and where the code is actually expected to be run. If you're not expecting the code to run on the client, then there's no reason to use JavaScript. V8 performance is better when single-threaded, but then why use the actor model?
When I go to the ClojureScript website, they have a whole section about why they chose JavaScript as a compilation target[0]. Notably, it mentions the word "client" multiple times.
It's a general purpose language (as mentioned several times) and compiling to js eg. for lustre webapps (elm-ish). I've contributed to the js compiler once only and can't find a way to use more gleam at my job but I'd say having failsafe actor based erlang backend + ssr + rich strongly typed reactive frontend all in one language is really cool.
It seems your stuck on js-only for ui and somehow rejecting compile to js. If you don't wanna use it fine but I'm not sure what you're looking for in this thread...
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".
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).
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.
English has no central authority, so the lines between grammar and style can get fuzzy. Most guides would say you need an "and" after the second comma, but some make an exception if the clauses are "very short and alike in form". See Wikipedia's article Comma splice if you are interested in the pedantics. https://en.wikipedia.org/wiki/Comma_splice
You still didn't answer: am I supposed to write "I'm eating a hot dog she's listening to radio" without a comma for that sentence to be grammatical? Or am I supposed to always insert "and" into it?
With or without a comma, without a conjunction like "and" the example is a run on sentence and is ungrammatical. You should join the clauses with a conjunction, and including a comma before the conjunction is a common style.
There's a caveat where some style guides permit using a comma without a conjunction in specific contexts, but most don't.
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".
A subordinating conjunction like if turns an independent clause into a dependent clause, so you don’t use a comma.
> And almost nobody writes sentences like "I love her and she loves me back" with a comma before "and".
In informal writing, people frequently leave out commas for everything but lists.
But it’s also very common to see it used “correctly”. In any kind of writing where someone would be expected to proofread what they wrote, I’d expect it.
The comma prevents readers initially grouping words incorrectly.
“I called John and Mary answered.”
Your brain will start to parse that as “I called John and Mary” before backtracking once you hit the last word.
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.
> all the Erlang formats can be decompiled into Erlang source code
Nope, I'm not buying. This is roughly "any executable binary can be decompiled to C" which is kinda true, but we both know it's not how the real world works.
Compilation is lossy, parsing to AST is almost lossless.
> the cost of compiling to source
But now you paid this cost a second time. To build textual Erlang source programmatically, you need some kind of AST anyway, as I highly doubt you were using direct text templating. So you had an incomplete copy of Erlang Abstract Format, which is THE Erlang AST, but had to write your own pretty-printing.
If I were to implement code generation targeting BEAM in language X I would start with making some tool(in Erlang) to fetch abstract format definition from erl_parse typespecs and make code generator to X emitting matching definitions and ETF serialization code. It is relatively simple, it is unavoidable anyway, and it lets me avoid bothering with textual Erlang puctuation.
I just don't get it. It's not even fun!
Also I'm currently playing with idea of compiling Core Erlang via OCaml backend, there is a mirror problem - parsing of Core into OCaml terms. And no way I'm implementing proper lexing/parsing of Core, I'm going with ETF right from start.
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
> Like at some point the neatness of doing all loops as recursion wears off and it's just tiring.
Odd, but I believe you, lol. Elixir's list comprehensions take a `:reduce` option which makes accumulating values a bit more "familiar" and I often use over `reduce`:
Not sure if there is something like that in Erlang (or Gleam for that matter).If you already have a list in Erlang, you can use map and the foldl/foldr reducers. But there's no general for-loop. You're expected to use tail recursion.
Also tbh, I don't like reduce either. I agree with that article posted on HN a while back about devs not liking reduce. Just want to insert into my list or whatever, not have to check how exactly reduce works in this particular language.
> you can use map and the foldl/foldr reducers
Ya, I was saying as an alternative to a more dynamic-looking loop. And I should note that `for` is confusing in Elixir because it is not a for loop, it's a list comprehension. Also, `<-` is actually a match operator and can cause confusion if you think of it as a for loop. I'm actually not sure why they went with `for`. At one point it was `lc`. I do think `for` is better than `lc`, heh.
But yes, I don't hate reduce, but I do try and avoid it in favour of a higher level version if its available. My only real problem with reduce is that I sometimes forget the parameter order, which is why I like using list comprehensions since the accumulator gets labelled.
The "for" might be inspired by Python list comprehension
I was fortunate enough to use Erlang professionally for a couple of years. I agree: the syntax is quite comfortable.
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.
There are dozens of us! Erlang is a great language, elixir just feels kinda flimsy and over-macro’d to me somehow.
What was your background before Erlang? I came from Ruby, so Elixir felt much more like home than Erlang.
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...
You don't think that Gleam has more familiar syntax to a Rust dev than Elixir? Or that the type system might feel more familiar?
I think a Rust programmer is more likely to prefer Gleam to Elixir, but I don't think there is much link between Gleam and Rust, and I especially do not thing that Gleam should only be considered over Elixir if you are already a Rust programmer.
So I said:
> I'd say if you know and like Rust, then Gleam should be easy to pick up
And you think that:
> a Rust programmer is more likely to prefer Gleam to Elixir
Are we maybe splitting hairs here?
You said: >I'd say if you know and like Rust, then Gleam should be easy to pick up but otherwise I'd try Elixir.
This is way too strong and narrow statement. Gleam is statically typed garbage collected language, closer to OCaml than Rust. Elixir if you like dynamically typed instead.
Obligatory comment that elixir is now gradually typed: https://news.ycombinator.com/item?id=48388324
Tbh gradual typing sounds like a nightmare. Probably impossible to implement correctly, whatever your definition of "correctly".
Nah, the gradual angle is not what makes a type system tricky to implement. Plus we have published a few papers discussing how we are typing Elixir and how our approach is sound.
It's very possible that I'm misunderstanding you! I'm mostly just saying that Gleam is very unlike Rust, so if you pick it or avoid it for Rust related reasons you may not be making the most informed decision.
The languages that Gleam is most like might be Standard ML, OCaml, Elm, and F#.
You seem to be interpreting the statements as technical comparisons of the languages, but ch4s3 was (by my read) commenting on the overall ability of a programmer to jump from one language to another.
That is: they aren't similar languages on a technical level, but if you know Rust, you should be able to make the jump to Gleam pretty quickly.
Aye, I am saying that jumping from Rust to Gleam isn't easy because the languages are so different. "How do I do X in Gleam like I would in Rust" is one of the most common categories of support question from newcomers who assumed they were similar.
It can take a moment to understand that things are done quite differently in the two languages due to being so different: https://gleam.run/frequently-asked-questions/#How-does-Gleam...
> The languages that Gleam is most like might be Standard ML, OCaml, Elm, and F#.
And guess which languages inspired several things in Rust.
The ML family clearly inspired Rust greatly, but the end result is very different.
I use Rust and prefer Elixir over Gleam because Elixir has Lisp-style macros (Gleam doesn't), uses OTP directly, has the fantastic IEx REPL (Gleam has no counterpart), and has Phoenix, the best web framework I've ever used.
Yes, exactly my point! Being a Rust user doesn’t mean you are going to prefer or even understand Gleam.
> I'd say if you know and like Rust, then Gleam should be easy to pick up
I think by sentiments like this, people mean if you know unions, records, and pattern matching then you'll more easily pick up another language that has unions, records, and pattern matching.
Yep, that's essentially what I mean. There's even this official cheatsheet[1] that shows a lot of overlap.
[1] https://gleam.run/cheatsheets/gleam-for-rust-users/
This shows only the base syntax and has nothing of the language functionality, so is incapable of showing overlap between the languages.
Again you’re really reading way past what I’m saying. The superficial stuff is the reason it may be a good first place to look.
You’re being contrarian for no reason.
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?
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.
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
I have project language called spite. You can write apps in it or out of it.
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.
The concurrency model in Go is also poorly suited to the BEAM's process model. Goroutines share a heap so you can't do a lot of things safely that processes can do. Having independent memory space for a process allows you to free it safely when work is done without GCing everything and you can also safely share data because you have a copy not a ref.
There is this: https://github.com/ergo-services/ergo which i keep meaning to take a look at, but never seem to quite get around to…
It looks reasonable but I’d have to see how they actually do memory management.
An JavaScripts is? Rust is probably a more performant target regardless
Surprisingly yes! JavaScript's allocator and garbage collection system is quite well suited to immutable programming.
Rust is a very poor compile target as the compiler is slow and not commonly available, and the aspects of Rust that make it good for humans to write make it a poor choice for compilers to target. With humans the produced code is verified, but with a compiler the compiler is what is to be verified, so the inflexibility of Rust are largely a hindrance compared to other native compilation targets.
What lower-level language do you think aside from rust which can be more helpful for the purposes of being a compile target, nim/D both support garbage collection and non garbage collection, so would languages like these be more preferable
I really love gleam and its community and I would really really love if gleam could be more like golang though, which can help it in compiling to machine code
gleam language but with the developer experience of golang (cross portability/small binaries/fast compiled language which is fast to compile) is honestly one of my fever dreams and I would love to know if it can ever be a reality!
For that sort of compilation target more flexibility is beneficial, so C, Wasm, LLVM IR, Cranelift IR etc are better than Go, Nim, and D in my opinion.
> cross portability/small binaries/fast compiled language which is fast to compile
You don't need native compilation to build fast single file executables for a program, there's ways one can achieve this with Gleam today. Bundling the BEAM into your Gleam application executable with something like Gleepack is one option, and this will produce smaller executables than Go will by default for many applications.
I don't get the impression that javascript is among Gleam's targets because of performance.
- server target: BEAM
- client target: js
Once you've covered those bases, you're kind of done.
If the server needs to do something special in an OS process... might as well let the OS mediate that interaction so that it can be fully generic, rather than trying to bend the language around whatever the unknown action might be.
For that there is Lisette. Close to gleam, compiles to Go.
I just learned about Lisette, and from there Gala. Any thoughts on Lisette vs Gala?
You just described Lisette. Its very close to gleam, and compiles to Go.
Gleam is my new default language and ecosystem. Until last year, I first reached for .NET on new projects. ".NET everywhere" and such. But Blazor apps are huge and slow. These days I often advocate first for Gleam. With Lustre and Tauri it can run anywhere.
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.
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 :)
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.
Louis is amazing. So cool to see how he's grown this project since starting it.
Amazing news! Thank you!
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.
...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.
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.
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.
It's a general purpose programming language, like OCaml, Python, or Scheme. It's not intended for any specific business domain.
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?
JavaScript is useful in lots of places, and even if one compile target is especially good for in-browser user interfaces that doesn't mean that language is specifically intended for user interface development.
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.
So, you started by making a pointed comment about that the language has no string interpolation when it's ostensibly for building UIs, so I'm not sure why you're surprised you're getting responses like mine or the one from lpil. Gleam is not ostensibly meant for building UIs just because it targets JS, and while you don't get string interpolation in the way you might get in other languages you can go pretty far with the <> syntax.
To answer your question about why you would use Gleam when you're running code in a JS engine, it's the same about any language that compiles down to another, such as Clojure, and you can take your pick of those reasons: preference, syntax, pragmatism, etc. I'm not sure what kind of answer you're looking for beyond that.
I'm looking for the intention behind it. They chose two compilation targets. That made things harder. They had a reason. That's what I'm asking about.
None of your reasons ("preference, syntax, pragmatism") fully explain the situation without more context. Whose preference? What syntax are users even seeing? Why is it pragmatic?
Compilation targets are generally chosen based on performance characteristics and where the code is actually expected to be run. If you're not expecting the code to run on the client, then there's no reason to use JavaScript. V8 performance is better when single-threaded, but then why use the actor model?
When I go to the ClojureScript website, they have a whole section about why they chose JavaScript as a compilation target[0]. Notably, it mentions the word "client" multiple times.
[0] https://clojurescript.org/about/rationale
It's a general purpose language (as mentioned several times) and compiling to js eg. for lustre webapps (elm-ish). I've contributed to the js compiler once only and can't find a way to use more gleam at my job but I'd say having failsafe actor based erlang backend + ssr + rich strongly typed reactive frontend all in one language is really cool.
It seems your stuck on js-only for ui and somehow rejecting compile to js. If you don't wanna use it fine but I'm not sure what you're looking for in this thread...
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".
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
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).
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.
English has no central authority, so the lines between grammar and style can get fuzzy. Most guides would say you need an "and" after the second comma, but some make an exception if the clauses are "very short and alike in form". See Wikipedia's article Comma splice if you are interested in the pedantics. https://en.wikipedia.org/wiki/Comma_splice
You still didn't answer: am I supposed to write "I'm eating a hot dog she's listening to radio" without a comma for that sentence to be grammatical? Or am I supposed to always insert "and" into it?
With or without a comma, without a conjunction like "and" the example is a run on sentence and is ungrammatical. You should join the clauses with a conjunction, and including a comma before the conjunction is a common style.
There's a caveat where some style guides permit using a comma without a conjunction in specific contexts, but most don't.
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".
>If
A subordinating conjunction like if turns an independent clause into a dependent clause, so you don’t use a comma.
> And almost nobody writes sentences like "I love her and she loves me back" with a comma before "and".
In informal writing, people frequently leave out commas for everything but lists.
But it’s also very common to see it used “correctly”. In any kind of writing where someone would be expected to proofread what they wrote, I’d expect it.
The comma prevents readers initially grouping words incorrectly.
“I called John and Mary answered.”
Your brain will start to parse that as “I called John and Mary” before backtracking once you hit the last word.
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.
> all the Erlang formats can be decompiled into Erlang source code
Nope, I'm not buying. This is roughly "any executable binary can be decompiled to C" which is kinda true, but we both know it's not how the real world works. Compilation is lossy, parsing to AST is almost lossless.
> the cost of compiling to source
But now you paid this cost a second time. To build textual Erlang source programmatically, you need some kind of AST anyway, as I highly doubt you were using direct text templating. So you had an incomplete copy of Erlang Abstract Format, which is THE Erlang AST, but had to write your own pretty-printing.
If I were to implement code generation targeting BEAM in language X I would start with making some tool(in Erlang) to fetch abstract format definition from erl_parse typespecs and make code generator to X emitting matching definitions and ETF serialization code. It is relatively simple, it is unavoidable anyway, and it lets me avoid bothering with textual Erlang puctuation.
I just don't get it. It's not even fun!
Also I'm currently playing with idea of compiling Core Erlang via OCaml backend, there is a mirror problem - parsing of Core into OCaml terms. And no way I'm implementing proper lexing/parsing of Core, I'm going with ETF right from start.
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.