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

91–100 of 223 posts

Re: I tried Gleam for Advent of Code

#91

Post by culi »

scuff3d wrote: post #48
tempest_ wrote: post #19

Earlier quoted context omitted.

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.

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.com/watch?v=9OtN4iiFBsQ

Re: I tried Gleam for Advent of Code

#92

Post by merlincorey »

schrodinger wrote: post #81
Uehreka wrote: post #55

Earlier quoted context omitted.

> I fear LLMs have frozen programming language advancement and adoption for anything past 2021. Why would that be the case? Many models have knowledge cutoffs in this calendar year. Furthermore I’ve found that LLMs are generally pretty good at picking up new (or just obscure) languages as long as you have a few examples. As wide and varied as programming languages are, syntactically and ideologically they can only be…

The motivation isn’t there to create new languages for humans when you’re programming at a higher level of abstraction now (AI prompting). It’d be like inventing a new assembly language when everyone is writing code in higher level languages that compile to assembly. I hope it’s not true, but I believe that’s what OP meant and I think the concern is valid!

I believe prompting an AI is more like delegation than abstraction especially considering the non-deterministic nature of the results.

Re: I tried Gleam for Advent of Code

#93

Post by abound »

schrodinger wrote: post #81
Uehreka wrote: post #55

Earlier quoted context omitted.

> I fear LLMs have frozen programming language advancement and adoption for anything past 2021. Why would that be the case? Many models have knowledge cutoffs in this calendar year. Furthermore I’ve found that LLMs are generally pretty good at picking up new (or just obscure) languages as long as you have a few examples. As wide and varied as programming languages are, syntactically and ideologically they can only be…

The motivation isn’t there to create new languages for humans when you’re programming at a higher level of abstraction now (AI prompting). It’d be like inventing a new assembly language when everyone is writing code in higher level languages that compile to assembly. I hope it’s not true, but I believe that’s what OP meant and I think the concern is valid!

I would argue it's more important than ever to make new languages with new ideas as we move towards new programming paradigms. I think the existence of modern LLMs encourages designing a language with all of the following attributes:

- Simple semantics (e.g. easy to understand for developers + LLMs, code is "obviously" correct)

- Very strongly typed, so you can model even very complex domains in a way the compiler can verify

- Really good error messages, to make agent loops more productive

- [Maybe] Easily integrates with existing languages, or at least makes it easy to port from existing languages

We may get to a point where humans don't need to look at the code at all, but we aren't there yet, so making the code easy to vet is important. Plus, there's also a few bajillion lines of legacy code that we need to deal with, wouldn't it be cool if you could port (or at least extend it) it into some standardized, performant, LLM-friendly language for future development?

Re: I tried Gleam for Advent of Code

#94

Post by riffraff »

akkad33 wrote: post #33
threethirtytwo wrote: post #7

It’s really good. But it needs generics. This is a huge downside. It’s a typed and clean functional programming language but it arbitrarily followed golangs early philosophy of no generics. Ironically golang is one of the most hated languages among many fp advocates. By the developers own action of adding generics ultimately the golang team admits they were wrong or that generics are better. If gleam gets popular I t…

Why does it need generics? There's a great blog post about how you can replace a lot of trait behaviour with just functions. Maybe something like that can be done for generics

the comment is wrong, what Gleam lacks is interfaces.

Which feels super strange, but doesn't seem to really be a problem, e.g. imagine a language where you'd write

    fun sum_all_numbers(Iterable it) { it.fold(...) } # an interface
    sum_all_numbers(a_list) # a list implements iterable
Gleam wants you to write

    fun sum_all_numbers(Iterator it) { it.fold(...) } # a concrete type
    sum_all_numbers(a_list.iterator) # get the caller to build the right object
edit: found an article that explained this a bit better https://mckayla.blog/posts/all-you-need-is-data-and-function...

Re: I tried Gleam for Advent of Code

#95

Post by isodev »

marliechiller wrote: post #2

One thing im wondering with the LLM age we seem to be entering: is there value in picking up a language like this if theres not going to be a corpus of training data for an LLM to learn from? Id like to invest the time to learn Gleam, but I treat a language as a tool, or a means to an end. I feel like more and more I'm reaching for the tool to get the job done most easily, which are languages that LLMs seem to gel wi…

Claude reads and writes Gleam just fine. I think as long as the language syntax is well documented (with examples) and has meaningful diagnostics, LLMs can be useful. Gleam has both brilliant docs and diagnostics rivalling Rust. Gleam is also very well designed language wise, not many reserved words, very explicit APIs… also something that helps LLMs.

Contrast with the likes of Swift - been around for years but it’s so bloated and obscure that coding agents (not just humans) have problems using it fully.

Re: I tried Gleam for Advent of Code

#96

Post by miki123211 »

lpil wrote: post #57
sbuttgereit wrote: post #29

Earlier quoted context omitted.

> For those that don't know its also built upon OTP, the erlang vm This isn't correct. It can compile to run on the BEAM: that is the Erlang VM. OTP isn't the Erlang VM; rather, "OTP is set of Erlang libraries and design principles providing middle-ware to develop [concurrent/distributed/fault tolerant] systems." Gleam itself provides what I believe is a substantial subset of OTP support via a library: https://github…

Hi, I’m the creator of Gleam! The comment you are replying to is correct, and you are incorrect. All OTP APIs are usable as normal within Gleam, the language is designed with it in mind, and there’s an additional set of Gleam specific additions to OTP (which you have linked there). Gleam does not have access to only a subset of OTP, and it does not have its own distinct OTP inspired OTP. It uses the OTP framework.

> Hi, I’m the creator of Gleam!

What's the state of Gleam's JSON parsing / serialization capabilities right now?

I find it to be a lovely little language, but having to essentially write every type three times (once for the type definition, once for the serializer, once for the deserializer) isn't something I'm looking forward to.

A functional language that can run both on the backend (Beam) and frontend (JS) lets one do a lot of cool stuff, like optimistic updates, server reconciliation, easy rollback on failure etc, but that requires making actions (and likely also states) easily serializable and deserializable.

Re: I tried Gleam for Advent of Code

#97

Post by IshKebab »

WJW wrote: post #60

Gleam is really quite a nice language. I did AoC in it this year as well and came away with the following: (incomplete list for both positive and negative, these are mainly things that come to mind immediately) Positive: - It can be pretty performant if you do it right. For example, with some thought I got many days down to double digit microseconds. That said, you do need to be careful how you write it and many patt…

Re argument formatting, I'd guess it's because it uses the Prettier algorithm which works like that.

However in my experience it's much better than the alternative - e.g. clang-format's default "binpack"ing of arguments (lay them out like prose). That just makes them hard to read and leads to horrible diffs and horrible merge conflicts.

Re: I tried Gleam for Advent of Code

#98

Post by girvo »

lpil wrote: post #59
agos wrote: post #37

Earlier quoted context omitted.

the Erlang vm is called BEAM, not OTP. sadly, Gleam's implementation of OTP is not at the same level as Elixir's or Erlang.

Gleam uses regular OTP, it doesn’t have a distinct OTP inspired framework. Source: I’m the author of Gleam.

I wonder why so many have got this wrong across this thread? Was it true once upon a time or something, or have people just misunderstood your docs or similar?

Re: I tried Gleam for Advent of Code

#99

Post by andy_ppp »

lpil wrote: post #59
agos wrote: post #37

Earlier quoted context omitted.

the Erlang vm is called BEAM, not OTP. sadly, Gleam's implementation of OTP is not at the same level as Elixir's or Erlang.

Gleam uses regular OTP, it doesn’t have a distinct OTP inspired framework. Source: I’m the author of Gleam.

"Big Elixir" must be paying people to misunderstand Gleam today eh ;-)

Re: I tried Gleam for Advent of Code

#100

Post by lawn »

miki123211 wrote: post #96
lpil wrote: post #57

Earlier quoted context omitted.

Hi, I’m the creator of Gleam! The comment you are replying to is correct, and you are incorrect. All OTP APIs are usable as normal within Gleam, the language is designed with it in mind, and there’s an additional set of Gleam specific additions to OTP (which you have linked there). Gleam does not have access to only a subset of OTP, and it does not have its own distinct OTP inspired OTP. It uses the OTP framework.

> Hi, I’m the creator of Gleam! What's the state of Gleam's JSON parsing / serialization capabilities right now? I find it to be a lovely little language, but having to essentially write every type three times (once for the type definition, once for the serializer, once for the deserializer) isn't something I'm looking forward to. A functional language that can run both on the backend (Beam) and frontend (JS) lets on…

This is also what really annoyed me when I tried out Gleam.

I'm waiting for something similar to serde in Rust, where you simply tag your type and it'll generate type-safe serialization and deserialization for you.

Gleam has some feature to generate the code for you via the LSP, but it's just not good enough IMHO.

Post reply on HN