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

101–110 of 223 posts

Re: I tried Gleam for Advent of Code

#101

Post by lpil »

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…

You can generate those conversions, most people do.

But also, you shouldn’t think of it as writing the same type twice! If you couple your external API and your internal data model you are greatly restricting your domain modelling cability. Even in languages where JSON serialisation works with reflection I would recommend having a distinct definition for the internal and external structure so you can have the optimal structure for each context, dodging the “lowest common decimator” problem.

Re: I tried Gleam for Advent of Code

#102

Post by lpil »

tazjin wrote: post #75
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.

(I know Erlang well, but haven't used Gleam) The library the parent links to says this: > Not all Erlang/OTP functionality is included in this library. Some is not possible to represent in a type safe way, so it is not included. Does this mean in practice that you can use all parts of OTP, but you might lose type checking for the parts the library doesn't cover?

No, it means that one specific package only offers bindings to certain parts. It’s the documentation for one library, not the language.

Re: I tried Gleam for Advent of Code

#103

Post by pjm331 »

agos wrote: post #38
victorbjorklund wrote: post #17

Earlier quoted context omitted.

I feel that was more true 1-2 years ago. These days I find Claude Code write almost as good (or as bad depending on your perspective) Elixir code as JavaScript code and there must be less Elixir code in the training data.

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

Re: I tried Gleam for Advent of Code

#104

Post by miki123211 »

Uehreka wrote: post #55
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 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…

There's a flywheel where programmers choose languages that LLMs already understand, but LLMs can only learn languages that programmers write a sufficient amount of code in.

Because LLMs make it that much faster to develop software, any potential advantage you may get from adopting a very niche language is overshadowed by the fact that you can't use it with an LLM. This makes it that much harder for your new language to gain traction. If your new language doesn't gain enough traction, it'll never end up in LLM datasets, so programmers are never going to pick it up.

Re: I tried Gleam for Advent of Code

#105

Post by lpil »

lawn wrote: post #100
miki123211 wrote: post #96

Earlier quoted context omitted.

> 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.

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.

Re: I tried Gleam for Advent of Code

#106

Post by lpil »

girvo wrote: post #98
lpil wrote: post #59

Earlier quoted context omitted.

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?

OTP is a very complex subject and quite unusual in its scope, and it’s not even overly clear what it even is. Even in Erlang and Elixir it’s commonly confused, so I think it’s understandable that Gleam has the same problem further still with its more distinct programming style.

Re: I tried Gleam for Advent of Code

#107

Post by miki123211 »

lpil wrote: post #101
miki123211 wrote: post #96

Earlier quoted context omitted.

> 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…

You can generate those conversions, most people do. But also, you shouldn’t think of it as writing the same type twice! If you couple your external API and your internal data model you are greatly restricting your domain modelling cability. Even in languages where JSON serialisation works with reflection I would recommend having a distinct definition for the internal and external structure so you can have the optimal…

I understand your point, and I agree with it in most contexts! However, for the specific use case where one assumes that the client and server are running the exact same code (and the client auto-refreshes if this isn't the case), and where serialization is only used for synchronizing between the two, decoupling the state from it's representation on the wire doesn't really make sense.

Re: I tried Gleam for Advent of Code

#108

Post by kevindamm »

abound wrote: post #93
schrodinger wrote: post #81

Earlier quoted context omitted.

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 ca…

I think that LLMs will be complemented best with a declarative language, as inserting new conditions/effects in them can be done without modifying much (if any!) of the existing code. Especially if the declarative language is a logic and/or constraint-based language.

We're still in early days with LLMs! I don't think we're anywhere near the global optimum yet.

Re: I tried Gleam for Advent of Code

#109

Post by lawn »

lpil wrote: post #105
lawn wrote: post #100

Earlier quoted context omitted.

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.

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.

Re: I tried Gleam for Advent of Code

#110

Post by lpil »

ngruhn wrote: post #66
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…

I can live with these negatives. What irritates me the most is the lack of if/else or guards or some kind of dedicated case-distinction on booleans. Pattern matching is great but for booleans it can be kinda verbose. E.g. case x ... False -> case x > 10 { True -> ... False -> case x ... False -> ... } } }

In Gleam we would typically write this code with `use`, which doesn’t introduce nesting.
Post reply on HN