Gleam 1.2.0 release – Fault tolerant Gleam
gleam.run
gleam.run
It's truly a joy to use and the community is very nice. Some features are still missing (e.g, reflection), but I do agree, as a user, with the focus they're putting on the developer experience, as evident is this release.
If anyone else has a Vue application they want to dabble with Gleam in, do check out vleam[1].
Is it fair to call Gleam an Erlang with modern syntax and a HM type system?
It seems it can also compile to JS (not just Erlang's Beam VM) - is the JS target as well supported?
Is performance just the same as Erlang (when compiled to Beam) or there's differences?
Why would someone use Beam instead of Elixir (they now have optional types - not sure how well those work though)? Is there really demand for more than one modern language on top of Erlang's VM?
Kinda. There's a fair amount similar but things like message passing are implemented as a library in gleam [0] rather than being a part of the core language, so you might say the big things that make erlang _erlang_ are not part of Gleam directly.
> is the JS target as well supported?
The experience is pretty good, yeah! The compiler can emit typescript declarations, there's a vite plugin for gleam, I maintain a frontend framework written in gleam and it's all grand.
> Is performance just the same as Erlang (when compiled to Beam) or there's differences?
That's right, perf is the same.
> Why would someone use Gleam instead of Elixir (they now have optional types - not sure how well those work though)? Is there really demand for more than one modern language on top of Erlang's VM?
Few reasons. Elixir's type system work is very much Work In Progress and could be a long time before we get something "finished". Also the semantics and approach have quite different designs: I'd guess folks that like the gradual type experience Elixir is pushing would not like Gleam's type system and vice versa.
There's certainly room for us both on the BEAM (and we do interoperate too!)
For anyone interested, that framework is Lustre[0]. It looks interesting: An Elm-inspired approach to SPAs on the front end, compiling Gleam to javascript. Back end also in Gleam but compiled to Erlang.
Haven't tried it yet but on the list. Kudos, @hayleighdotdev, for putting something that expansive together in a pretty short period of time.
It's worth nothing that while `!` and `receive` are in the core language for Erlang, OTP (the actor framework and what people generally consider the important bit of Erlang) is implemented as a library, just like in Gleam.
ETA: I'm an idiot, I didn't see the "type safe" word on there. That is something worth considering.
I found the comms around typing very confusing, it took me an hour to figure out "is there some damn typing in Elixir or is there not??"
Fly's posts do a great job of this also https://fly.io/blog/skip-the-api/
Edit: lol - I just saw on the homepage that Fly sponsors Gleam.
Not sure whether I will stick with it or leptos/axum or leptos/salvo.rs but I find it very pleasing to work with and the community is super nice!
In the interest of fairness, there's also sprocket [1] which leans much heavier into thing that you might also what a check out.
[0]: https://hexdocs.pm/lustre/lustre/server_component.html [1]: https://sprocket.live
Gleam: a type safe language on the Erlang VM - https://news.ycombinator.com/item?id=38183454 - Nov 2023 (242 comments)
Gleam: A statically typed language for the Erlang VM - https://news.ycombinator.com/item?id=22902462 - Apr 2020 (109 comments)
Gleam 0.15 - https://news.ycombinator.com/item?id=27061500 - May 2021 (78 comments)
If Gleam is good at concurrency why aren't they telling anyone about it, and if it's not good at concurrency what even is the point of it?
> Running on the battle-tested Erlang virtual machine that powers planet-scale systems such as WhatsApp and Ericsson, Gleam is ready for workloads of any size.
> Thanks to a multi-core actor based concurrency system that can run millions of concurrent tasks, fast immutable data structures, and a concurrent garbage collector that never stops the world, your service can scale and stay lightning fast with ease.
It's accompanied by a code example with 200,000 async tasks being spawned.
I ran that code, but it does not run; it tells me that "task" is not defined. I read the "language tour", but it wasn't covered. So I went to the standard library to find out what "task" is, but it's not there. I went to the docs to learn what "async" is, but it's not mentioned. I went to the "gleam for rust users" doc because I was hoping it would give me a "gleam vs rust" concurrency primer, but no luck.
Based on this, I feel that concurrency is maybe an afterthought in Gleam, which surprised me, because that's not what I had expected seeing as it runs on BEAM.
If I had to guess it'll be because it's a light wrapper around Beam/OTP primitives, and the initial audience for Gleam was probably developers already using the Beam with eg Elixir and familiar with its concurrency already. It definitely looks like it's expanded beyond that though.
import gleam/otp/task
I mostly follow from the sidelines, having a deeper buyin with Elixir, but whenever I find the time and a use case I'll build something in Gleam and learn more.
The community voted that the LSP is more important than documenting, polishing, and expanding the actor framework so that is what the core team is currently focusing on.
I find it off-putting to have politics as the third thing on the home page though. Makes me think there is going to be a scissor that cuts the community apart at some point.
("As a Gleam community, we need to have a position on Israel-Palestine!")
Bravo to this community for being explicit about it.
" As a community, we want to be friendly too. People from around the world, of all backgrounds, genders, and experience levels are welcome and respected equally. See our community code of conduct for more.
Black lives matter. Trans rights are human rights. No nazi bullsh*t. "
Considering quite a few contributors in the Gleam community are LGBTQ+ it's seems justified that they want to stand for their contributors rights and safety.
I'm a BLM skeptic because it seems pretty clear to me that the movement has distracted everyone from the real issues of police brutality, under training, and militarization. It's distracting from the real issue of declining social mobility in the US, and it's blaming racism at the same time as nigerian immigrants are falsifying that premise clearly.
Making these things into identity issue means we aren't making progress as we aren't talking about them, we're just screaming at each other and blaming the other side.
People who want to stop people from dying by taking the problem seriously: "nazis". :(
Says more about you than the project.
It isn't the case that even if everyone agrees on the BLM, Trans rights, and the outcome of WWII will agree on future issues of the day. Thier stance sets up an expectation that the language should have an official position on these topics.
I even gave an example.
A community that fosters professionalism rather than explicit ideology won't have this problem.
It's pretty much the same as don't enter into professional relations with the local mafia, it's mostly a matter of scale and available weaponry.
If I recruit you into my organisation I trust that you will not bring in criminals into our enterprise. I would not hire you if I thought that it could bring attention from the fuzz or expose us to extortion.