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

121–130 of 223 posts

Re: I tried Gleam for Advent of Code

#121

Post by aryonoco »

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.

Not many people use elm directly but it has influenced the design of so many frameworks and libraries.

Right now I’m toying with the idea of building a GNOME application in rust, and the framework I’m using is relm4 which provides elm like abstractions over gtk-rs.

Previously I’ve built web applications with F# and elmish, which again provides elm like abstractions for building F# applications.

Re: I tried Gleam for Advent of Code

#123

Post by dnautics »

manquer wrote: post #54
dnautics wrote: post #47

Earlier quoted context omitted.

i think it's pretty clear that some of "the things you expect to make an LLM good at a language" (like strong typing) are not actually the case. other things like "don't indirect your code by jumping to something unexpected" might be more important.

If anything llms would be poorer in codegen for static languages because they are more verbose - More tokens to generate and use limited context windows parsing code. The advantage rather for llms in strongly typed languages is that compilers can catch errors early and give the model early automated feedback so you don’t have to. With weakly typed (and typically interpreted) languages they will need to run the code w…

not necessarily. if your refactoring loop requires too many cycles you'll fall off the attention context window.

also, some nonstatic languages have a habit of having least surprise in their codebases -- it's often possible to effectively guess the types flowing through at the callsite. zero refactoring feedback necessary is better than even one.

Re: I tried Gleam for Advent of Code

#124

Post by scuff3d »

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…

I get the sentiment. He feels like everything he wants is there so it doesn't need much more development. But it still feels off.

Re: I tried Gleam for Advent of Code

#126

Post by scuff3d »

aryonoco wrote: post #121
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.

Not many people use elm directly but it has influenced the design of so many frameworks and libraries. Right now I’m toying with the idea of building a GNOME application in rust, and the framework I’m using is relm4 which provides elm like abstractions over gtk-rs. Previously I’ve built web applications with F# and elmish, which again provides elm like abstractions for building F# applications.

The Roc programing language is being developed because Richard Feldman wanted an Elm like experience in more places then just the front end.

Re: I tried Gleam for Advent of Code

#127

Post by aryonoco »

pjm331 wrote: post #103
agos wrote: post #38

Earlier quoted context omitted.

in my daily experience Claude Code writes better Elixir code than JS (React). Surely this has to do with the quality of the training material

Can’t confirm or deny comparison with JS but I can second that it write decent elixir The only problem I’ve ever had was on maybe 3 total occasions it’s added a return statement, I assume because of the syntax similarity with ruby

I’ve found Claude (at least until Opus 4) would routinely fail at writing a bash script. For example it would end an if block with }. Or get completely lost with environment variables and subshells.

But those are exactly the same mistakes most humans make when writing bash scripts, which makes them inherently flaky.

Ask it to write code in a language with types, a “logical” syntax where there are no tricky gotchas, with strict types, and a compiler which enforces those rules, and while LLMs struggle to begin with, they eventually produce code which is nearly clean and bug free. Works much better if there is an existing codebase where they can observe and learn from existing patterns.

On the other hand asking them to write JavaScript and Python, sure they fly, but they confidently implement code full of hidden bugs.

The whole “amount of training data” is completely overblown. I’ve seen code do well even with my own made up DSL. If the rules are logical and you explain the rules to it and show it existing patterns, the can mostly do alright. Conversely there is so much bad JavaScript and Python code in their training data that I struggle to get them to produce code in my style in these languages.

Re: I tried Gleam for Advent of Code

#128

Post by thelastgallon »

rapind wrote: post #41
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.

I recently used Gleam + Lustre for a small app that I normally would have built with Elm + PostgREST. It went very well, and I'm now planning to use it for a larger rewrite (of a rails app).

This Lustre? https://www.lustre.org/

Seems to be a filesystem, how would it replace a database?

Re: I tried Gleam for Advent of Code

#129

Post by sshine »

lawn wrote: post #109
lpil wrote: post #105

Earlier quoted context omitted.

Multiple of such tools exist and have done for years. Serde isn’t a Rust-core project, and similarly the Gleam alternatives are not Gleam-core.

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.

> Rust has macros that make serde very convenient, which Gleam doesn't have.

To be fair, Rust's proc macros are only locally optimal:

While they're great to use, they're only okay to program.

Your proc-macro needs to live in another crate, and writing proc macros is difficult.

Compare this to dependently typed languages og Zig's comptime: It should be easier to make derive(Serialize, Deserialize) as compile-time features inside the host language.

When Gleam doesn't have Rust's derivation, it leaves for a future where this is solved even better.

Re: I tried Gleam for Advent of Code

#130

Post by Phelinofist »

bmacho wrote: post #53
seritools wrote: post #39

Earlier quoted context omitted.

For a quick fix: `font-variant-ligatures: none;` on body or similar.

For users: paste the following in console document.body.style.setProperty('font-variant-ligatures','none','important');

I use NoScript and only got them after enabling JS for the blog page
Post reply on HN