Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Gleam Programming Language

gleam.run

Post reply on HN
Print view View original

1–10 of 189 posts

Re: The Gleam Programming Language

#2

Post by rapnie »

Now here's a type-safe functional programming language I recently bumped into, which with their focus on simplicity, ease of use, and developer experience, and compiling to either Erlang or Javascript, is really tempting to delve in deeper.

Re: The Gleam Programming Language

#4

Post by ocean_moist »

brandonpollack2 wrote: post #3

I really like the idea of gleam but I don't want to hand implement serialization for every type (even with an LSP action) in 2026.

Biggest issue with this language. But... fairly trivial to implement codegen with gleam/glance[0]. No good libraries do this well right now (e.g. support for discriminated unions).

[0] https://hexdocs.pm/glance/glance.html

Re: The Gleam Programming Language

#8

Post by tombert »

I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely.

Honestly, and I realize that this might get me a bit of flack here and that’s obviously fine, but I find type systems start losing utility with distributed applications. Ultimately everything being sent over the wire is just bits. The wire doesn’t care about monads or integers or characters or strings or functors, just 1’s and 0’s, and ultimately I feel like imposing a type system can often get in the way more than it helps. There’s so much weirdness and uncertainty associated with stuff going over the wire, and pretty types often don’t really capture that.

I haven’t tried Gleam yet, and I will give it a go, and it’s entirely possible it will change my opinion on this, so I am willing to have my mind changed.

Re: The Gleam Programming Language

#9

Post by sfvisser »

tombert wrote: post #8

I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely. Honestly, and I realize that this might get me a bit of flack here and that’s obviou…

I don’t understand this comment, yes everything going over the wire is bits, but both endpoints need to know how to interpret this data, right? Types are a great tool to do this. They can even drive the exact wire protocol, verification of both data and protocol version.

So it’s hard to see how types get in the way instead of being the ultimate toolset for shaping distributed communication protocols.

Re: The Gleam Programming Language

#10

Post by jakelazaroff »

tombert wrote: post #8

I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely. Honestly, and I realize that this might get me a bit of flack here and that’s obviou…

Interesting! I don't share that view at all — I mean, everything running locally is just bits too, right? Your CPU doesn't care about monads or integers or characters or strings or functors either. But ultimately your higher level code does expect data to conform to some invariants, whether you explicitly model them or not.

IMO the right approach is just to parse everything into a known type at the point of ingress, and from there you can just deal with your language's native data structures.

Post reply on HN