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.<p>[edit - this might have been ambiguous. I meant that it shows he really cares about the fine details.]
yea he is super nice.
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.
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.<p><a href="https://gleam.run/frequently-asked-questions/#How-does-Gleam-compare-to-Rust" rel="nofollow">https://gleam.run/frequently-asked-questions/#How-does-Gleam...</a>
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.
> I'd say if you know and like Rust, then Gleam should be easy to pick up<p>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.<p>[1] <a href="https://gleam.run/cheatsheets/gleam-for-rust-users/" rel="nofollow">https://gleam.run/cheatsheets/gleam-for-rust-users/</a>
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.<p>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.<p>1: <a href="https://www.erlang.org/doc/apps/stdlib/erl_parse.html#t:abstract_form/0" rel="nofollow">https://www.erlang.org/doc/apps/stdlib/erl_parse.html#t:abst...</a><p>2: <a href="https://www.erlang.org/doc/apps/stdlib/qlc.html#q/2" rel="nofollow">https://www.erlang.org/doc/apps/stdlib/qlc.html#q/2</a><p>3: <a href="https://www.erlang.org/doc/apps/syntax_tools/merl.html" rel="nofollow">https://www.erlang.org/doc/apps/syntax_tools/merl.html</a>
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.
Pretty exciting change that I didn’t see coming —- I wonder if someone will end up implementing an integration with the Whatsapp Erlang debugger
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.<p>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!
Congratulations to the team! I love Gleam and am genuinely having fun every time I write Gleam code.
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?
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?<p>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.<p>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.<p>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?<p>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?<p>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.<p>[0] <a href="https://clojurescript.org/about/rationale" rel="nofollow">https://clojurescript.org/about/rationale</a>
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!<p>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.
gleam is very much a language of "no" which if you like that, cool, if not, also cool :)
What is Gleam? Where would I want to use it?<p>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?
The misuse of commas is distracting; at least it’s better than reading ai blogs.
idk, i'm not sure about wording.
erlang abstract form still is erlang source, it's ast of erlang source text.
one call to <i>erl_prettypr:format</i> 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.<p>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.<p>I think you're overthinking the cost of compiling to source, and also underestimating how common it is.