[HN Gopher] I tried Gleam for Advent of Code
___________________________________________________________________
I tried Gleam for Advent of Code
Author : tymscar
Score : 200 points
Date : 2025-12-13 17:00 UTC (5 hours ago)
(HTM) web link (blog.tymscar.com)
(TXT) w3m dump (blog.tymscar.com)
| marliechiller wrote:
| 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 with.
| Hammershaft wrote:
| This was one of my bigger worries for LLM coding: we might
| develop path dependence on the largest tools and languages.
| c-hendricks wrote:
| I hope this isn't the future of "new" languages. Hopefully
| newer AI tools can actually learn a language and they won't be
| the limiting factor.
| positron26 wrote:
| This is the answer. We need online learning for our own code
| bases and macros.
| whimsicalism wrote:
| it's easy enough for them as soon as they have an RL
| environment for the language
| bbatha wrote:
| I'm more interested in what happens when a language is
| designed specifically for llms? When doing vibe coding a lot
| of code is a lot more verbose than I'd do normally. Do we
| drop down the abstraction level because llms are just so good
| a churning out boilerplate?
| epolanski wrote:
| Llms are already good at churning boilerplate, so the next
| step really is making them good as so they develop taste
| and architectural consistency imho.
| dugmartin wrote:
| I think as ai tools actually learn languages that functional
| languages will win out as they are much easier to reason
| about.
| kace91 wrote:
| If you just see language as a tool, unless you're self employed
| or working in open source, wouldn't the lack of job market
| demand for it be the first blocker?
| macintux wrote:
| If you're fortunate, you can find companies with a passion
| for good code who use lesser-known languages. Picking Erlang,
| or Haskell, or OCaml generally filters out candidates who
| don't share your interest in seeing what can be done outside
| the mainstream.
| epolanski wrote:
| It's funny you mention Haskell, because it's one of those
| languages many love but can't find jobs in it even if they
| halved their salaries.
| armchairhacker wrote:
| Gleam isn't a very unique language. The loss from generalizing
| may be less than the improved ergonomics, if not now then as
| LLMs improve.
| mikepurvis wrote:
| I don't know Gleam at all so I can't comment on that
| specifically, but I think everyone has the experience of a
| coworker who writes C++ as if it's C or Python as if its Java
| or whatever else.
|
| A language doesn't have to be unique to still have a
| particular taste associated with its patterns and idioms, and
| it would unfortunate if LLM influence had the effect of
| suppressing the ability for that new style to develop.
| ModernMech wrote:
| Yes, because LLMs don't change the fact that different
| programming languages have different expressive capabilities.
| It's easier to say some things in some languages over others.
| That doesn't change if it's an LLM writing the code; LLMs have
| finite context windows and limited attention. If you can
| express an algorithm in 3000 loc in one language but 30 loc in
| another, the more expressive language is still preferred, even
| if the LLM can spit out the 3000 lines in 1s. The reason being
| if the resulting codebase is 10 - 100x larger than it needs to
| be, that has real costs that are not mitigated by LLMs or
| agents. All things being equal, you'd still prefer the right
| tool for the job, which does not imply we should use Python for
| everything because it dominates the training set, it means we
| should make sure LLMs have capabilities to write other
| programming languages equally well before we rely on them too
| much.
| victorbjorklund wrote:
| 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.
| stanmancan wrote:
| There's certainly a lot more JS code out there to train on,
| but the quality of the Elixir code is likely overall much
| better.
| jszymborski wrote:
| I personally find it much more painful to generate valid Rust
| code that compiles and does what I want than e.g. valid
| python code that runs and does what I want.
| dnautics wrote:
| 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.
| manquer wrote:
| 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 which maybe quite slow to
| do so or not realistic.
|
| Simply put agentic coding loops prefer stronger static
| analysis capabilities.
| agos wrote:
| 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
| pjm331 wrote:
| 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
| jedbrooke wrote:
| where do you think the corpus of training data comes from?
| dragonwriter wrote:
| Its pretty much the same thing as in every previous age, where
| not having a community of experience and the supporting
| materials they produce has been a disadvantage to early
| adopters of a new language, so the people that used it first
| were people with a particular need that it seemed to address
| that offset that for them, or that had a particular interest in
| being in the vanguard.
|
| And those people are the people that develop the body of
| material that later people (and now LLMs) learn from.
| timeon wrote:
| Seems like you are not target audience for these new languages
| and that is OK. But I guess there are still many people that
| want to try new things (on their own even).
| thefaux wrote:
| In the medium to long term, if LLMs are unable to easily learn
| new languages and remap the knowledge they gained from training
| on different languages, then they will have failed in their
| mission of becoming a general intelligence.
| dnautics wrote:
| claude is really good at elixir. IME, It's really really good
| with a few "unofficial" tweaks to the language/frameworks, but
| this could be my bias. the LLM cutoff was a fear of mine, but i
| think it's actually the opposite. we know that as few as 250
| documents can "poison" an LLM, i suspect that (for now) a small
| language with very higg quality examples can "poison" LLMs for
| the better.
| christophilus wrote:
| I recently built something in Hare (a very niche new language),
| and Claude Code was helpful. No where near as good as it is
| with TypeScript. But it was good enough that I don't LLMs being
| in the top 5 reasons a language would fail to get adopted.
| epolanski wrote:
| Of course there is, especially if you believe that LLMs further
| improve on reasoning.
| isodev wrote:
| 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.
| kryptiskt wrote:
| 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.
| bbkane wrote:
| I keep running into Gleam posts and podcasts and videos. I think
| it could be an especially attractive alternative to JS for UI
| with the Lustre library. Haven't tried it yet, my backlog is ever
| growing...
| threethirtytwo wrote:
| 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 think much of the same will occur.
|
| There's simply too much repeated code without generics. I tried
| writing a parser combinator in gleam and it wasn't pretty.
| kace91 wrote:
| Perhaps this is a silly question but how do you do functional
| with no generics? Arent they pretty much required for
| map/reduce/filter?
| threethirtytwo wrote:
| Sorry my comment was wrong. It's been a while when I messed
| with gleam and I remember it was missing a critical thing but
| I misremembered what it was.
|
| Gleam doesn't support interfaces. Not generics. You are
| completely right.
| chongli wrote:
| There are multiple levels of possible generics at play here:
| the container type and the element type. You can have a
| map/reduce/filter that operate on any element type (generic
| elements) while still being specialized to linked lists. On
| the other hand, you might prefer a generic map that can
| operate on any container type and any element type, so that
| you can use the same map method and the same function to map
| over arrays of numbers, sets of numbers, lists of numbers,
| trees of numbers, or even functions of numbers!
|
| Haskell allows both sorts of generics. In Haskell parlance
| they call this _higher-kinded polymorphism_ and the generic
| version of map they call fmap (as a method of the class
| Functor).
| lpil wrote:
| Gleam does have generics.
| nerdponx wrote:
| Most Scheme implementations don't have generics, and you have
| to deal with a different map function for every data
| structure.
|
| Gauche has a generic sequence interface which is great, and
| it's one of the reasons as a Python user I like Gauche as my
| "daily driver" Scheme.
| NathanaelRea wrote:
| I saw your other comment that you meant interface. But an
| example of a language that went without a feature people
| thought the language desperately needed was Go with generics.
| They only added them more than ten years later, when they
| figured out the best way to implement them.
|
| It might be the same with gleam, with first version in 2019 and
| 1.0 in 2024. The language authors might think they are either
| uneeded and lead to anti patterns, or are waiting to see the
| best way to implement them.
| akkad33 wrote:
| 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
| riffraff wrote:
| 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<T> it) { it.fold(...) } # an
| interface sum_all_numbers(a_list) # a list implements
| iterable
|
| Gleam wants you to write fun
| sum_all_numbers(Iterator<T> 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...
| nonethewiser wrote:
| Go touted it's lack of features as simplicity. And it is: on
| the language writing side. Go is an incomplete language
| masquerading as a simple one.
| ljlolel wrote:
| That's the worse is better philosophy which maybe doesn't
| matter as much anymore especially with AI
| NuclearPM wrote:
| What do you mean?
| lpil wrote:
| Gleam has always had generics! There's no Gleam version without
| them
| bnchrch wrote:
| 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 Gleam has slid just under the closing door
| and LLMs will get up to speed on it fast.
| sbuttgereit wrote:
| > 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.com/gleam-lang/otp
|
| Importantly: "Gleam has its own version of OTP which is type
| safe, but has a smaller feature set. [vs. Elixir, another BEAM
| language with OTP support]"
| lpil wrote:
| 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.
| tazjin wrote:
| (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?
| lpil wrote:
| No, it means that one specific package only offers
| bindings to certain parts. It's the documentation for one
| library, not the language.
| miki123211 wrote:
| > 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.
| lawn wrote:
| 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.
| lpil wrote:
| 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.
| lawn wrote:
| 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.
| lpil wrote:
| In Gleam code generators are most commonly used, similar
| to in C#, Go, or Elm.
| lpil wrote:
| 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.
| miki123211 wrote:
| 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.
| lpil wrote:
| Totally. This is where I would generate them.
| sbuttgereit wrote:
| 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.
| lpil wrote:
| 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.
| agos wrote:
| 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.
| lpil wrote:
| Gleam uses regular OTP, it doesn't have a distinct OTP
| inspired framework. Source: I'm the author of Gleam.
| girvo wrote:
| 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?
| lpil wrote:
| 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.
| andy_ppp wrote:
| "Big Elixir" must be paying people to misunderstand Gleam
| today eh ;-)
| Uehreka wrote:
| > 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 so different.
| schrodinger wrote:
| 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!
| pxc wrote:
| > It'd be like inventing a new assembly language when
| everyone is writing code in higher level languages that
| compile to assembly.
|
| Isn't that what WASM is? Or more or less what is going on
| when people devise a new intermediate representation for a
| new virtual machine? Creating new assembly languages is a
| useful thing that people continue to do!
| rapind wrote:
| We may end up using AI to create simplified bespoke subset
| languages that fit our preferences. Like a DSL of sorts but
| with better performance characteristics than a traditional
| DSL and a small enough surface area.
| merlincorey wrote:
| I believe prompting an AI is more like delegation than
| abstraction especially considering the non-deterministic
| nature of the results.
| sarchertech wrote:
| 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.
| abound wrote:
| 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?
| kevindamm wrote:
| 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.
| aaronblohowiak wrote:
| 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.
| miki123211 wrote:
| 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.
| crystal_revenge wrote:
| > 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.
| scuff3d wrote:
| 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.
| tempest_ wrote:
| 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.
| styluss wrote:
| Which conflicts? Gleam seems to be released often?
| OtomotO wrote:
| The elm drama
| rapind wrote:
| > all the conflict with the creator
|
| Just so no one misunderstands this. The creator (Evan) didn't
| get into, or start, any drama himself that I ever noticed.
| I'd argue he's a very chill and nice dude.
|
| I've been on the edges of the community for probably a decade
| now (lurker), and all of the drama came from other people who
| simply didn't like the BDFL and slow releases strategy.
| scuff3d wrote:
| 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.
| culi wrote:
| 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
| rapind wrote:
| 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).
| epolanski wrote:
| Anecdotically I recently got into Ruby, via Sinatra, and
| enjoy the experience.
|
| What are you lacking in ruby and rails, besides the types?
| scuff3d wrote:
| I've considered playing around with it. Every now and then I
| tell myself I'm gonna learn front end dev, but as soon as I
| start looking at it (FE in general not Lustre specifically) I
| get depressed and give up lol
| croisillon wrote:
| fortunately the blog title police stepped in as soon as possible
| https://news.ycombinator.com/item?id=45426996
| periodjet wrote:
| Ruined by ligatures. Use them in your own private coding time,
| not when trying to communicate with others. It obfuscates rather
| than clarifies.
| tymscar wrote:
| I actually agree. I don't even use them in my private code. I
| will look into removing them from my blog!
| seritools wrote:
| For a quick fix: `font-variant-ligatures: none;` on body or
| similar.
| toastal wrote:
| I have this as !important in a global userStyle for code,
| pre, kbd, samp elements.
| bmacho wrote:
| For users: paste the following in console
| document.body.style.setProperty('font-variant-
| ligatures','none','important');
| mono442 wrote:
| I've looked at Gleam before but it didn't seem to have any
| mechanism for dynamic dispatch like interfaces or type classes.
| Did it change in the meantime?
| stuartaxelowen wrote:
| The answer I've seen is "just pass structs of functions
| around", which is just one step more explicit than the implicit
| version we're all use to, but honestly I kinda like it to free
| ourselves of all the ceremony around generics.
| lpil wrote:
| It's discouraged to pass around structs of functions to
| replicate type classes in Gleam. Instead the preference is to
| not type class style patterns in your projects, favouring a
| concrete style instead.
| lpil wrote:
| Gleam has first class functions, so it has dynamic dispatch.
|
| Both of type classes and interfaces desugar to high order
| functions, so anything you write with them can be written with
| first class functions, though with a less concise API.
| the_duke wrote:
| What you are saying is: no, it doesn't.
|
| Of course dynamic dispatch can be implemented in almost every
| language. The Linux kernel uses dynamic dispatch with C!
|
| But that's a hack, not a language feature.
| lpil wrote:
| I think you might mean "ad hoc polymorphism" rather than
| "dynamic dispatch". Gleam, C, Erlang, etc have the latter,
| not so much the former.
| WJW wrote:
| 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 patterns that work well in other languages fall flat
| in Gleam.
|
| - The language server is _incredibly_ good. It autoformats,
| autocompletes even with functions from not-yet-imported-but-
| known-to-the-compiler packages, shows hints with regarding to
| code style and can autofix many of these, autofills missing
| patterns in pattern matches, automatically imports new packages
| when you start using them and much much more. It has definitely
| redefined my view of what an LSP can do for a language.
|
| - The language is generally a joy to work with. The core team has
| put a lot of effort into devex and it shows. The pipe operator is
| nice as always, the type system is no haskell but is expressive
| enough, and in general it has a lot of well-thought out
| interactions that you only notice after using it for a while.
|
| Negative:
|
| - The autoformatter can be a bit overly aggressive in rewriting
| (for example) a single line function call with many arguments to
| a function call with each argument on a different line. I get
| that not using "too much" horizontal space is important, but
| using up all my vertical space instead is not always better.
|
| - The language (on purpose) focuses a lot on simplicity over
| terseness, but sometimes it gets a little bit much. Having to
| type `list.map` instead of `map` or `dict.Dict` instead `Dict` a
| hundred times does add up over the course of a few weeks, and
| does not really add a lot of extra readability. OTOH, I have also
| seen people who really really like this part of Gleam so YMMV.
|
| - Sometimes the libraries are a bit lacking. There are no matrix
| libraries as far as I could find. One memoisation library had a
| mid-AoC update to fix it after the v1.0 release had broken it but
| nobody noticed for months. The maintainer did push out a fix
| within a day of realizing it was broken though. The ones that
| exist and are maintained are great though.
| vips7L wrote:
| > Having to type `list.map` instead of `map` or `dict.Dict`
| instead `Dict` a hundred times does add up over the course of a
| few weeks, and does not really add a lot of extra readability.
|
| I did it in F# this year and this was my feeling as well. All
| of the List.map and Seq.filter would have just been better to
| be called off of the actual list or Seq. Not having the
| functions attached to the objects really hurts discoverability
| too.
| ngruhn wrote:
| 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
| < 0 { True -> ... False -> case x
| > 10 { True -> ... False ->
| case x <= 10 { True -> ...
| False -> ... } } }
| WJW wrote:
| There are (some) guards available though? You could rewrite
| your example as: case x { n if x
| < 0 -> ... n if x > 10 -> ... n if x <=
| 10 -> ... }
|
| Guards are a bit limited in that they cannot contain function
| calls, but that's a problem of the BEAM and not something
| Gleam could control.
| tymscar wrote:
| You most likely asked an AI for this. They always think
| there is an `if` keyword in case statements in Gleam. There
| isn't one, sadly.
|
| EDIT: I am wrong. Apparently there are, but it's a bit of a
| strange thing where they can only be used as clauses in
| `if` statements, and without doing any calculations.
| WJW wrote:
| There is though?
|
| https://tour.gleam.run/flow-control/guards/
| ngruhn wrote:
| Ah right, I remember now.
|
| > Guards are a bit limited in that they cannot contain
| function calls,
|
| I feel like that's not a small sacrifice.
|
| > but that's a problem of the BEAM and not something Gleam
| could control.
|
| Could Gleam desugar to a case expression like I wrote
| above?
| lpil wrote:
| In Gleam we would typically write this code with `use`, which
| doesn't introduce nesting.
| tymscar wrote:
| I was also pretty surprised about the performance. It's not C,
| but it's so much faster than I'd guessed.
|
| I do agree the language server is great. And it works in
| basically any IDE, which is another huge bonus.
|
| With regards to having to type `list.map`, you actually don't
| need to! You can do this: import
| gleam/list.{range, map} import gleam/int pub
| fn main() { range(0,10) |> map(int.to_string) |> echo
| }
|
| Some libraries just aren't there, and I do wonder how hard it
| would be to port C libraries over. Something I want to play
| with!
| mjmas wrote:
| double space before each line for code formatting
| tymscar wrote:
| Thank you! TIL
| IshKebab wrote:
| 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.
| titanomachy wrote:
| I don't know gleam, but surely
| list.map(fn(line) { line |> calculate_instruction })
|
| Could be written list.map(calculate_instruction)
| ?
| WJW wrote:
| That is correct.
| tymscar wrote:
| 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.
| jsmo wrote:
| Nice, thanks for the write-up! Any pros/cons that jump out to you
| for someone whose been trying to pick up Elixir on the side?
| tymscar wrote:
| Thank you! I have not played around with Elixir just yet,
| sadly, so I can't help there, I'm afraid.
| zelphirkalt wrote:
| 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 .< and so on. What I liked were of course
| pipes and pattern matching.
|
| 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.
___________________________________________________________________
(page generated 2025-12-13 23:00 UTC)