Hacker News new | past | comments | ask | show | jobs | submit login
Gleam 1.2.0 release – Fault tolerant Gleam (gleam.run)
149 points by crowdhailer 3 months ago | hide | past | favorite | 53 comments



I rewrote large parts of my webapp, Nestful[0], in Gleam.

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].

[0] https://nestful.app

[1] https://github.com/vleam/vleam


What would you like to achieve with reflection? I know there a few niceties around having them but I don't find myself missing reflection.


Amazing how Gleam is moving forward. It seems it's now pretty mature and with great tooling support?!

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?


> Is it fair to call Gleam an Erlang with modern syntax and a HM type system?

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!)

[0]: https://hexdocs.pm/gleam_erlang/


> I maintain a frontend framework written in gleam and it's all grand

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.

[0]: https://hexdocs.pm/lustre/guide/01-quickstart.html


> 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.

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.


Here's an informing podcast episode with Gleam's maintainer, https://changelog.com/podcast/588.


I've never heard of Gleam. Out of curiosity, what does it buy you over something like Elixir? Or rather, why do people prefer it over Elixir (or vanilla Erlang or Joxa or LFE)?

ETA: I'm an idiot, I didn't see the "type safe" word on there. That is something worth considering.


It's type safe, it's important to note that its type system is a Hindley–Milner type system. Same type system family as OCaml, Haskell, Standard ML etc. Its syntax is heavily inspired by Rust. whereas Elixir's syntax is inspired by Ruby and Erlang's inspired by prolog.

https://en.wikipedia.org/wiki/Hindley–Milner_type_system


This article does the one great thing - the first setence of this announcement post tells you what Gleam actually is. Other projects should take note.

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.


Also worth remembering that Elixir is now a 'gradually typed system': https://news.ycombinator.com/item?id=38914407


I don't know what José meant by "officially", but as far as I could see it's still not something that can be actually used. I read it'd be available in 1.17.0 which still isn't out.

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??"


The RC for 1.17 is out, and the notes will tell you what type checks are included: https://github.com/elixir-lang/elixir/releases/tag/v1.17.0-r...


Completely agree. I think they were just excited to make progress but it's not out for anyone to use. I was definitely confused by the comms.


1.17 is in release candidate as of last week, but keeping your expectations moderate is definitely still advisable.


It advertises itself as having a "familiar and modern" syntax where Elixir has a more ruby-like one.


I've been experimenting with gleam the last couple of days.

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!


Fault-tolerant compilation is very cool. The Haskell ecosystem is moving towards it as well: https://github.com/haskellfoundation/tech-proposals/pull/63


I'm jumping in the Gleam wagon as soon as something like Elixir's Phoenix LiveView is available.


Hey there, I maintain a library a called lustre [0] that does similar things to liveview. The linked docs are the API reference, but there's not currently a guide or a robust example on how to put things together (there's a bare minimum one in the repo you can find) – that'll be changing soon, I was just giving a talk about this at Lambda Days ^.^

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


That's seriously cool! I'm going to try and give this a test this weekend.


I've been thinking of creating an app with a type-safe core in gleam, and then using elixir/phoenix for its more mature web / live interfaces.


Can you run Elixir and Gleam concurrently in the same VM and exchange messages between them?


Yes, they both run on the Beam VM and you can seamlessly call the code directly or pass messages between processes written in Gleam or Elixir (or Erlang).


That actually looks like an interesting language, I wonder if it's easy to target wasm with Gleam !?


Class! It’s a lovely language and a nice community. Love to see it make progress.


Related:

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)


I thought that since Gleam is build for BEAM, it should be good at concurrency? I thought that was its whole angle, but there's not a mention of concurrency at all in the docs, it's not built into the standard library, and apparently this is all they offer: https://hexdocs.pm/gleam_otp/

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?


Their home page says it is:

> 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.


Indeed, yes that bit on the homepage is what caused me to write what I did.

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.


It's not an afterthought at all, but due to Gleam being a new language we do not have much documentation for the actor framework, so you are largely expected to be familiar with Erlang's implementation.

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.


Got you. I guess it comes from `gleam/otp/task` in the link you posted, the API matches. But it does seem to be missing from eg the language walkthrough.

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.


Load the module: https://hexdocs.pm/gleam_otp/gleam/otp/task.html

   import gleam/otp/task
How modules work is covered by the language tour, and to do something interesting you'll probably want more than just the task module. The concurrency stuff isn't as fleshed out in Gleam as it is in Elixir or Erlang, as I understand it because it's not the project's focus and due to how the type system works.


I think I've heard that it's implemented as a library because we're not sure about the best way to implement the concurrency stuff. It's easier to experiment in a library than in the core.


Right, yeah, maybe I read that it's something like the typing system putting constraints on direct interop, I'm not sure.

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.


Interesting language. Great web page.

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!")


What I find more offputting is that they aim to be international but mention things that are clearly American-centric (BLM is not an international thing, you know? In most other countries, all people's lives matter and that needs not be said. Saying that in Africa may even be offensive as that kind of implies it wasn't clear that their lives mattered until someone said it?! To me it's almost like a Serbian project mentioning that only people who support Bosnia's independence are welcome - without trying to make any sort of equivalence except for the absurdity of "local" issues spilling outside).


Actually I think this is pretty smart. This will deter people who disagree with those values to even participating in the community.


How about just getting the work done?


It's somewhat naive to think that politics and life are not intertwined. There is no "getting the work done" without a huge amount of hidden politics.

Bravo to this community for being explicit about it.


Calling your political opponents, or even people on the fence, "nazis" is a bit much though.


Seems like you're reading into this. They literally say

" 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.


Yea, but enumerating BLM skeptics in the same breath as nazis is not welcoming, and it's not respectful.

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.


Yes, i agree it does that effectively now. But what about future issues? See my post below.


you will find that not allowing Nazis and the likes into your community generally ties it together, rather than cuts it apart.


Until it doesn't.

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.


The professional thing to do is to not cooperate with people that support obviously criminal states. Don't work with iranians spying on refugees. Don't work with zionists that support the ongoing crimes against the palestinians. Don't work with people that support the russian invasion of Ukraine.

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.


I'll bite, does "the likes" include tankies?


If they’d fracture your community, sure.


"And the like" including people who see that BLM has accomplished not even nothing, but destroyed the small chance of taking the issue of police brutality seriously. It's not a black vs white thing. It's a police vs civilian thing, and a problem of police being under trained.

People who want to stop people from dying by taking the problem seriously: "nazis". :(


Instead of down voting, do watch some videos from Gracie Breakdown: https://www.youtube.com/watch?v=itYfWN65t2A


Wow you read a whole lot of your own biases into that.

Says more about you than the project.


"nazis and the like" implies the other things listed in the same list I think. If the poster didn't mean that then sure. But I think he did.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: