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

111–120 of 223 posts

Re: I tried Gleam for Advent of Code

#111

Post by sarchertech »

merlincorey wrote: post #92
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 believe prompting an AI is more like delegation than abstraction especially considering the non-deterministic nature of the results.

It does further than non-determinism. LLM output is chaotic. 2 nearly identical prompts with a single minor difference can result in 2 radically different outputs.

Re: I tried Gleam for Advent of Code

#112

Post by kryptiskt »

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…

On the other hand, if you write a substantial amount of code in a niche languages, the LLMs will pick up your coding style as it's in a sizable chunk of the training corpus.

Re: I tried Gleam for Advent of Code

#113

Post by aaronblohowiak »

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…

This is why I use rust for everything practicable now. Llms make the tedious bits go away and I can just enjoy the fun bits.

Re: I tried Gleam for Advent of Code

#114

Post by sbuttgereit »

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.

Fair enough, but to be fair to my statements, the quotes I chose were largely from gleam-lang.org or the Gleam OTP library.

Take for example this section of the Gleam website FAQ section:

https://gleam.run/frequently-asked-questions/#how-does-gleam...

"Elixir has better support for the OTP actor framework. Gleam has its own version of OTP which is type safe, but has a smaller feature set."

At least on the surface, "but has a smaller feature set" suggests that there are features left of the table: which I think it would be fair to read as a subset of support.

If I look at this statement from the Gleam OTP Library `readme.md`:

"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. Other features are still in development, such as further process supervision strategies."

That quote leaves the impression that OTP is not fully supported and therefore only a subset is. It doesn't expound further to say unsupported OTP functionality is alternatively available by accessing the Erlang modules/functions directly or through other mechanisms.

In all of this I'll take your word for it over the website and readme files; these things are often not written directly by the principals and are often not kept as up-to-date as you'd probably like. Still even taking that at face value, I think it leaves some questions open. What is meant by supporting all of OTP? Where the documentation and library readme equivocates to full OTP support, are there trade-offs? Is "usable as normal" usable as normal for Erlang or as normal for Gleam? For example, are the parts left out of the library available via directly accessing the Erlang modules/functions, but only at the cost of abandoning the Gleam type safety guarantees for those of Erlang? How does this hold for Gleam's JavaScript compilation target?

As you know, Elixir also provides for much OTP functionality via direct access to the Erlang libraries. However, there I expect the distinction between Elixir support and the Erlang functionality to be substantially more seamless than with Gleam: Elixir integrates the Erlang concepts of typing (etc.) much more directly than does Gleam. If, however, we're really talking about full OTP support in Gleam while not losing the reasons you might choose Gleam over Elixir or Erlang, which I think is mostly going to be about the static typing... then yes, I'm very wrong. If not... I could see how strictly speaking I'm wrong, but perhaps not completely wrong in spirit.

Re: I tried Gleam for Advent of Code

#115

Post by lpil »

sbuttgereit wrote: post #114
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.

Fair enough, but to be fair to my statements, the quotes I chose were largely from gleam-lang.org or the Gleam OTP library. Take for example this section of the Gleam website FAQ section: https://gleam.run/frequently-asked-questions/#how-does-gleam... "Elixir has better support for the OTP actor framework. Gleam has its own version of OTP which is type safe, but has a smaller feature set." At least on the surface, "b…

Ah, that’s good feedback. I agree, that documentation is misleading. I’ll fix them ASAP.

> Elixir also provides for much OTP functionality via direct access to the Erlang libraries.

This is the norm in Gleam too! Gleam’s primary design constraint is interop with Erlang code, so using these libraries is straightforward and commonplace.

Re: I tried Gleam for Advent of Code

#116

Post by lpil »

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.

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

Re: I tried Gleam for Advent of Code

#117

Post by crystal_revenge »

miki123211 wrote: post #104
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…

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…

> Because LLMs make it that much faster to develop software

I feel as though "facts" such as this are presented to me all the time on HN, but in my every day job I encounter devs creating piles of slop that even the most die-hard AI enthusiasts in my office can't stand and have started to push against.

I know, I know "they just don't know how to use LLMs the right way!!!", but all of the better engineers I know, the ones capable of quickly assessing the output of an LLM, tend to use LLMs much more sparingly in their code. Meanwhile the ones that never really understood software that well in the first place are the ones building agent-based Rube Goldberg machines that ultimately slow everyone down

If we can continue living in the this AI hallucination for 5 more years, I think the only people capable of producing anything of use or value will be devs that continued to devote some of their free time to coding in languages like Gleam, and continued to maintain and sharpen their ability to understand and reason about code.

Re: I tried Gleam for Advent of Code

#118

Post by lpil »

miki123211 wrote: post #107
lpil wrote: post #101

Earlier quoted context omitted.

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.

Totally. This is where I would generate them.

Re: I tried Gleam for Advent of Code

#119

Post by zelphirkalt »

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 parallelism if I want to, pipelines, and also pattern matching), and, aside from syntax, conceptually perhaps less elegant than Erlang. On the other hand it has static typing.

I also tried OCaml this year, but there are issues in the ecosystem making a truly reproducible environment/setup, because opam doesn't produce proper lock files (only version numbers) and it seemed silly to not be able to even include another file, without reaching for dune, or having to specify every single file/module on command line for the OCaml compiler. So I was left unsatisfied, even though the language is elegant and I like its ML-ness. I wish there was a large ecosystem around SML, but oh well ...

Might be I should take another look at Erlang soon, or just finally get started with Haskell. Erlang using rebar3 should have proper lock files, has pattern matching, and if I remember correctly no such limitations for calling functions recursively. No longer sure how or whether Erlang did inner functions though.

Re: I tried Gleam for Advent of Code

#120

Post by premek »

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…

>You can generate those conversions, most people do.

Hi, what do people use to generate them, I found gserde (edit: and glerd-json)

Post reply on HN