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

81–90 of 189 posts

Re: The Gleam Programming Language

#81

Post by __jonas »

heliumtera wrote: post #69

One of the best things about erlang/elixir is the repl driven development/manual testing. Gleam has no `interpreted` story, right? Something like clojure, common lisp, etc. I think this matters because debugging on beam is not THAT great, there are tools in erlang/elixir to facilitate debugging, like inspect() or dbg(). If anyone has experience in this language, what is the mindset with gleam? How you guys debug?

> If anyone has experience in this language, what is the mindset with gleam? How you guys debug?

There is the echo keyword now, which is comparable to elixir's dbg(), I use that a lot.

Lacking a REPL, what I normally do is make a dev module, like 'dev/playground.gleam' where I'm testing things out (this is something that the gleam compiler supports, /dev is similar to /test) and then run it with 'gleam run -m playground'.

Sometimes I also use the Erlang shell. You can get an Erlang shell with all the gleam modules from your project loaded in with the 'gleam shell' command. You just need to know the Erlang syntax, and how Gleam modules are named when compiled to Erlang (they use an '@' separator, so gleam/json becomes 'gleam@json').

Re: The Gleam Programming Language

#82

Post by andypants »

sfvisser wrote: post #9
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.

While I don't agree with the OP about type systems, I understand what they mean about erlang. When an erlang node joins a cluster, it can't make any assumptions about the other nodes, because there is no guarantee that the other nodes are running the same code. That's perfectly fine in erlang, and the language is written in a way that makes that situation possible to deal with (using pattern matching).

Re: The Gleam Programming Language

#83

Post by isodev »

behnamoh wrote: post #28

I'd rather them stick with ONE: JS or BEAM. Everytime a project claims it can do multiple things at once, it can't do either very well. It's confusing too. Is Gleam suitable for distributed computing like Elixir/Erlang on BEAM? Would that answer change if I compile it to JS?

My “intro to gleam” was a lustre form for my blog, where people could submit feedback. So I was able to create a neatly separated client module in Gleam and compile it to JavaScript so I can insert it in my static blog page. The server part was a separate gleam module with erlang as a target. They shared models and some constants with a “shared” module - just like the tutorial.

I find this kind of explicit separation very powerful. It also removes some of the anxiety if something will end up in a client bundle when it’s supposed to be server only.

Re: The Gleam Programming Language

#85

Post by librasteve »

okkdev wrote: post #61
librasteve wrote: post #37

thought I’d try the showcase example in Raku ( https://raku.org ), so this Gleam import gleam/io pub fn main() { io.println("hello, friend!") } becomes this Raku say “hello, friend!” well maybe you really want to have a main() so you can pass in name from the command line #!/usr/bin/env raku sub MAIN($name) { say "hello, $name!” }

Raku looks sweet, but what is the point of this comparison? :)

I love coding in Raku - and I am sure that Gleam is nice too. But I get the feeling that Raku is underappreciated / dismissed by many due to the perl5 / perl6 history. So my thinking is, when I see a new language showcase an example on their website, presumably a carefully chosen snippet that showcases their language at its best, I like to see how Raku compares to that.

You know the take-aways from the comparison are quite instructive:

- do I need to import the io lib? (shouldn't this just be included)

- do I need a main() in every script? (does this rule out one liners like `> raku -e "say 'hi'"`)

- is `io.println` quite an awkward way to spell `print`?

I am not making the case that these are right or wrong language design decisions, but I do think that they are instructive of the goals of the designers. In the case of raku its "batteries included" and a push for "baby raku" to be as gentle on new coders as eg. Python.

Re: The Gleam Programming Language

#86

Post by preommr »

librasteve wrote: post #37

thought I’d try the showcase example in Raku ( https://raku.org ), so this Gleam import gleam/io pub fn main() { io.println("hello, friend!") } becomes this Raku say “hello, friend!” well maybe you really want to have a main() so you can pass in name from the command line #!/usr/bin/env raku sub MAIN($name) { say "hello, $name!” }

Oh God, they actually put that awful logo front and center.

I'd always thought it would be a go-like thing where the put the mascot away for everything except for the minor hero section or buried in the footer.

RIP Perl.

Re: The Gleam Programming Language

#87

Post by brandonpollack2 »

worthless-trash wrote: post #5
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.

I rarely serialise every type in my gleam code, My quick back of the napkin math is less than 5%.

But 100 percent of projects writing the same stuff

Re: The Gleam Programming Language

#88

Post by lexx »

Lyngbakr wrote: post #84
lexx wrote: post #80

Gleam is ready and is amazing. We use gleam as the main language in our company

What's the product/use case?

We are a web agency, so client projects that are open to use a new language and our products like:

https://news.ycombinator.com/item?id=46530011

Re: The Gleam Programming Language

#89

Post by threethirtytwo »

nesarkvechnep wrote: post #36
pkos98 wrote: post #27

Coming from Elixir, I gave Gleam a try for a couple of days over the holidays. Reasons I decided not to pursue: - No ad-hoc polymorphism (apart from function overloading IIRC) means no standard way of defining how things work. There are not many conventions yet in place so you won’t know if your library supports eg JSON deserialization for its types - Coupled with a lack of macros, this means you have to implement ev…

I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism. The community doesn’t use protocols except “for data”. Whatever that means. Global singleton processes everywhere. I’m really discouraged by the practices I observe but it’s the most enjoyable language for me still.

>I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism.

That’s true for Elixir as practiced, but it’s the wrong conclusion for Gleam.

Elixir doesn’t care about ad-hoc polymorphism because in Elixir it’s a runtime convention, not a compile-time guarantee. Protocols don’t give you universal quantification, exhaustiveness, coherence, or refactoring safety. Missing cases become production crashes, not compiler errors. So teams sensibly avoid building architecture on top of them.

In a statically typed language, ad-hoc polymorphism is a different beast entirely. It’s one of the primary ways you encode abstraction safely. The compiler enforces that implementations exist, pushes back on missing cases, and lets you refactor without widening everything into explicit pattern matches.

That’s exactly why people who like static types do care about it.

Pointing to Elixir community norms and concluding “nobody cares” is mixing up ecosystem habits with language design. Elixir doesn’t reward those abstractions, so people don’t use them. Gleam is explicitly targeting people who want the compiler to carry more of the burden.

If Gleam is “Elixir with types,” fine, lack of ad-hoc polymorphism is consistent. If it’s “a serious statically typed language on the BEAM,” then the absence is a real limitation, not bikeshedding.

Static types aren’t about catching typos. They’re about moving failure from runtime to compile time. Ad-hoc polymorphism is one of the main tools for doing that without collapsing everything into concrete types.

That’s why the criticism exists, regardless of how Elixir codebases look today.

Post reply on HN