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'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.
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.
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.
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.
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 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 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.
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.
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.
[edit - this might have been ambiguous. I meant that it shows he really cares about the fine details.]
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
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.
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.
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.
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.
All I understand from the frontpage is that it's typesafe. Good I guess? Then there is something about Erlang which I never used.
[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
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.
The lack or excess of commas doesn't upset any reasonable person in the slightest.
And almost nobody writes sentences like "I love her and she loves me back" with a comma before "and".
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 think you're overthinking the cost of compiling to source, and also underestimating how common it is.