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

I tried Gleam for Advent of Code

blog.tymscar.com

Post reply on HN
Print view View original

151–160 of 223 posts

Re: I tried Gleam for Advent of Code

#151

Post by lawn »

lpil wrote: post #116
lawn wrote: post #109

Earlier quoted context omitted.

Rust has macros that make serde very convenient, which Gleam doesn't have. Could you point to a solution that provides serde level of convenience? Edit: The difference with generating code (like with Gleam) and having macros generate the code from a few tags is quite big. Small tweaks are immediately obvious in serde in Rust, but they drown in the noise in the complete serialization code like with the Gleam tools.

In Gleam code generators are most commonly used, similar to in C#, Go, or Elm.

Yes, my point is that it's not a good experience.

Re: I tried Gleam for Advent of Code

#152

Post by worthless-trash »

innocentoldguy wrote: post #132
bnchrch wrote: post #8

Gleam is a beautiful language, and what I wish Elixir would become (re:typing). For those that don't know its also built upon OTP, the erlang vm that makes concurrency and queues a trivial problem in my opinion. Absolutely wonderful ecosystem. I've been wanting to make Gleam my primary language, but I fear LLMs have frozen programming language advancement and adoption for anything past 2021. But I am hopeful that Gle…

I don’t mean to minimize the huge effort by the Gleam team; however, Elixir cannot become Gleam without breaking OTP/BEAM in the same ways Gleam does. As it stands now, Elixir is the superior language between the two, if using the full Erlang VM is your goal.

I use many of the otp functions in gleam on thr regular, what functionality cant i call?

Gleam can call any erlang function, and can somewhat handle the idc types. [ im sure it has another name ].

Did i miss something that gleam fails on, because this is one of my concerns.

Re: I tried Gleam for Advent of Code

#153

Post by tasuki »

zelphirkalt wrote: post #119

I like Gleam, but I am somewhat annoyed by the fact, that I don't have the full functional freedom in calling recursive (inner) functions wherever I want. I don't know, why new functional languages do not get this right all the way, straight from some rnrs document or implementation. Another thing is the separate operators like .> and . To me it felt less elegant than Scheme (GNU Guile) which I usually use (with nice…

Heh, similar thoughts! The main difference that I only used Scheme for SICP, and I've used a bit of Haskell.

I like Haskell in theory, but: just to get a hello world takes a lot of CPU and disk space. The standard library is full of exceptions (you can use a different prelude, that opens a whole different can of worms). The ergonomics of converting between the thousand different string types are awful.

So, you being basically me, I have some recommendations:

Idris (2): good stdlib, has dependent types. A beautiful language. The compiler is self-hosted and bootstrapped by lisp - very elegant! The ecosystem is basically nonexistent though.

PureScript: also improves on Haskell in many ways. But, it's more of a frontend language, and though you can do backend, you're stuck with JavaScript runtime. Oh well.

Re: I tried Gleam for Advent of Code

#154

Post by tasuki »

troupo wrote: post #144
bnchrch wrote: post #8

Gleam is a beautiful language, and what I wish Elixir would become (re:typing). For those that don't know its also built upon OTP, the erlang vm that makes concurrency and queues a trivial problem in my opinion. Absolutely wonderful ecosystem. I've been wanting to make Gleam my primary language, but I fear LLMs have frozen programming language advancement and adoption for anything past 2021. But I am hopeful that Gle…

> what I wish Elixir would become (re:typing). Elixir is slowly rolling out set-theoretic typing: https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...

I dunno, my unfounded guess is that gradual type systems are super complex and very hard to get right.

Why use something complex and half working, when you can have the real thing?

Re: I tried Gleam for Advent of Code

#155

Post by tasuki »

tempest_ wrote: post #19
scuff3d wrote: post #14

Gleam is a great language. It didn't click for me when I was trying it out, but I'm glad to see more people enjoying it. And I wonder if Gleam + Lustre could become the new Elm.

As a mostly back end dev Elm looked really nice but all the conflict with the creator and then the lack of compiler releases made me shy away a bit. I have bumped into "the Elm architecture" in other projects though and it was nice.

> the lack of compiler releases

I'm a backend dev mostly and use Elm for all my frontend needs. Yes there are some things compiler-side that could be improved, but basically it's fine.

I appreciate not having to keep up with new releases!

Re: I tried Gleam for Advent of Code

#156

Post by tasuki »

culi wrote: post #91
scuff3d wrote: post #48

Earlier quoted context omitted.

Yeah I'm not a front end dev but I do kind of keep track of what's going on in that space. From what I saw it seemed Elm was all but dead. Maybe that's not true, but that was the impression from the outside looking in.

https://iselmdead.info/ I can't believe this is still up tbh. And I can't believe there's still people defending Elm's lack of development > It’s true that there hasn’t been a new release of the Elm compiler for some time. That’s on purpose: it’s essentially feature-complete. Last talk I saw by Evan Czaplicki (from the 2025 Scala Days conf) he seemed to be working on some sort of database language https://www.youtube…

> And I can't believe there's still people defending Elm's lack of development

Why? (I'm one such person defending Elm's lack of development)

Re: I tried Gleam for Advent of Code

#157

Post by pdimitar »

Hasnep wrote: post #142
tymscar wrote: post #72

Earlier quoted context omitted.

You're right, but loads of times I just left that there because I probably did something more involved in the map that I ended up deleting later without realising.

This sounds like the kind of situation where the LSP could suggest the simpler code, I'll see if there's an issue for it already and suggest it if not.

Elixir has one opinionated formatter -- Quokka -- that will rewrite the code above properly. It can also reuse linting rules as rewrite policies. Love using it.

Re: I tried Gleam for Advent of Code

#158

Post by troupo »

tasuki wrote: post #154
troupo wrote: post #144

Earlier quoted context omitted.

> what I wish Elixir would become (re:typing). Elixir is slowly rolling out set-theoretic typing: https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...

I dunno, my unfounded guess is that gradual type systems are super complex and very hard to get right. Why use something complex and half working, when you can have the real thing?

They are working towards "the real thing", whatever your definition of real is.

BTW in the 90s people tried to come up with a type system for Erlang, and failed:

--- start quote ---

Phil Wadler[1] and Simon Marlow [2] worked on a type system for over a year and the results were published in [3]. The results of the project were somewhat disappointing. To start with, only a subset of the language was type-checkable, the major omission being the lack of process types and of type checking inter-process mes-sages. Although their type system was never put into production, it did result in a notation for types which is still in use today for informally annotating types.

Several other projects to type check Erlang also failed to produce results that could be put into production. It was not until the advent of the Dialyzer [4] that realistic type analysis of Erlang programs became possible.

https://lfe.io/papers/%5B2007%5D%20Armstrong%20-%20HOPL%20II...

--- end quote ---

[1] Yes, that Philip Wadler, https://en.wikipedia.org/wiki/Philip_Wadler

[2] Yes, that Simon Marlow, https://en.wikipedia.org/wiki/Simon_Marlow

[3] A practical subtyping system for Erlang https://dl.acm.org/doi/10.1145/258948.258962

[4] https://www.erlang.org/doc/apps/dialyzer/dialyzer.html

Re: I tried Gleam for Advent of Code

#159

Post by tome »

tasuki wrote: post #153
zelphirkalt wrote: post #119

I like Gleam, but I am somewhat annoyed by the fact, that I don't have the full functional freedom in calling recursive (inner) functions wherever I want. I don't know, why new functional languages do not get this right all the way, straight from some rnrs document or implementation. Another thing is the separate operators like .> and . To me it felt less elegant than Scheme (GNU Guile) which I usually use (with nice…

Heh, similar thoughts! The main difference that I only used Scheme for SICP, and I've used a bit of Haskell. I like Haskell in theory, but: just to get a hello world takes a lot of CPU and disk space. The standard library is full of exceptions (you can use a different prelude, that opens a whole different can of worms). The ergonomics of converting between the thousand different string types are awful. So, you being…

> The standard library is full of exceptions

By the way, the number of partial functions is base that throw compiler warnings is increasing, for example:

https://hackage.haskell.org/package/base-4.21.0.0/docs/Prelu...

I hope it will increase further.

Re: I tried Gleam for Advent of Code

#160

Post by lpil »

lawn wrote: post #151
lpil wrote: post #116

Earlier quoted context omitted.

In Gleam code generators are most commonly used, similar to in C#, Go, or Elm.

Yes, my point is that it's not a good experience.

I would be very interested in hearing about your experience writing Gleam and the problems you have!

We regularly collect feedback and haven’t got problems reported here, so your feedback saying otherwise would be a useful data point.

Post reply on HN