[HN Gopher] I tried Gleam for Advent of Code
___________________________________________________________________
I tried Gleam for Advent of Code
Author : tymscar
Score : 329 points
Date : 2025-12-13 17:00 UTC (1 days 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.
| dnautics wrote:
| 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.
| 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
| aryonoco wrote:
| 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.
| 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.
| perrygeo wrote:
| The Gleam language, yes all of it, fits in a context window
| (https://tour.gleam.run/everything/)
|
| I have similar concerns to you - how well a language works with
| LLMs is indeed an issue we have to consider. But why do you
| assume that it's the volume of training data that drives this
| advantage? Another assumption, equally if not more valid IMO,
| is that languages which have fewer, well-defined, simpler
| constructs are easier for LLMs to generate.
|
| Languages with sprawling complexity, where edge cases dominate
| dev time, all but require PBs of training data to be feasible.
|
| Languages that are simple (objectively), with a solid
| unwavering mental model, can match LLMs strengths - and
| completely leap-frog the competition in accurate code gen.
| lanthissa wrote:
| the flip side of that, right now ai coding agents try to
| generate code, not software.
|
| it seems semi intuitive to me that a typesafe, functional
| programming language with referential transparency would be
| ideal if you could decompose a program to small components and
| code those.
|
| once you have a referentially transparent function with
| input/out tests you can spin on that forever until its solved
| and then be sure that it works.
| 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?
| array_key_first wrote:
| I think he means maybe AI can get around languages
| lacking features - like how codegen was used for a long
| time.
|
| Codegen is more and more rare these days, because
| languages have so many tools to help you write less code
| - like generics. LLMs could, theoretically, help you
| crank out similar repetitive implementations of things.
| ljlolel wrote:
| https://en.wikipedia.org/wiki/Worse_is_better
| 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.
| lawn wrote:
| Yes, my point is that it's not a good experience.
| lpil wrote:
| I would be very interested in hearing about your
| experience writing Gleam and the problems you have!
|
| We regularly collect feedback and haven't got problems
| reported here, so your feedback saying otherwise would be
| a useful data point.
| lawn wrote:
| I might try to collect my thoughts somewhere when I get
| some time over.
|
| Thank you for Gleam btw, I do really like the rest of the
| language.
| sshine wrote:
| > _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.
| 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.
| premek wrote:
| >You can generate those conversions, most people do.
|
| Hi, what do people use to generate them, I found gserde
| (edit: and glerd-json)
| okkdev wrote:
| The language server code action :)
| lpil wrote:
| There's several options, depending on what you want. The
| most commonly used option is the language server.
| premek wrote:
| Oh nice, didn't know about it. (I have migrated from vim
| to neovim and half of it doesn't work for me yet)
|
| I wonder why this is preferred over codegen (during
| build), possibly using some kind of annotations?
| lpil wrote:
| We've not had any proposals for a design like that. We
| are open to proposals though! I wrote a blog post
| detailing the process here: https://lpil.uk/blog/how-to-
| add-metaprogramming-to-gleam/
| worthless-trash wrote:
| Also. The lisp cam now generate serialisers and
| deserializers for some types iirc.
| 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.
| gr4vityWall wrote:
| Thanks for the clarification. I've read about Gleam here
| and there, and played with it a bit, and thought there
| was no way to directly access OTP through the Erlang
| libraries.
|
| This can be just my lack of familiarity with the
| ecosystem though.
|
| Gleam looks lovely and IMO is the most readable language
| that runs on the BEAM VM. Good job!
| lpil wrote:
| Thank you!
| 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 ;-)
| constructive wrote:
| who cares, just dont shove political opinions into a
| software project that developers. we are devs not jobless
| sjw's running around the road with some useless sign board
| lpil wrote:
| Free software was started as a political movement by
| Stallman et al. Why would we stop now?
| Capricorn2481 wrote:
| > who cares, just dont shove political opinions into a
| software project that developers. we are devs not jobless
| sjw's running around the road with some useless sign
| board
|
| Here we are, having a technical discussion and here you
| are, shoving politics into it.
| agos wrote:
| hey, thanks for the clarification. I was under the
| impression that Gleam had a few shortcomings re: OTP, like
| missing APIs or the need to fall back to Erlang. Many
| people I know who work regularly with Elixir hold similar
| opinions - do you have any idea what happened there? Is
| there a lack of publicity for this support? Is it a
| documentation problem?
| 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.
| Verdex wrote:
| This last week:
|
| * One developer tried to refactor a bunch of graph ql
| with an LLM and ended up checking in a bunch of
| completely broken code. Thankfully there were api tests.
|
| * One developer has an LLM making his PRs. He slurped up
| my unfinished branch, PRed it, and merged (!) it. One can
| only guess that the approved was also using an LLM. When
| I asked him why he did it, he was completely baffled and
| assured me he would never. Source control tells a
| different story.
|
| * And I forgot to turn off LLM auto complete after
| setting up my new machine. The LLM wouldn't stop
| hallucinating non-existent constructors for non-existent
| classes. Bog standard intellisense did in seconds what I
| needed after turning off LLM auto complete.
|
| LLMs sometimes save me some time. But overall I'm sitting
| at a pretty big amount of time wasted by them that the
| savings have not yet offset.
| brabel wrote:
| > One developer tried to refactor a bunch of graph ql
| with an LLM and ended up checking in a bunch of
| completely broken code. Thankfully there were api tests.
|
| So the LLM was not told how to run the tests? Without
| that they cannot know if what they did works, and they
| are a bit like humans, they try something and then they
| need to check if that does the right thing. Without a
| test cycle you definitely don't get a lot out of LLMs.
| Capricorn2481 wrote:
| You guys always find a way to say "you can be an LLM
| maximalist too, you just skipped a step."
|
| The bigger story here is not that they forgot to tell the
| LLM to run tests, it's that agentic use has been so
| normalized and overhyped that an entire PR was attempted
| without any QA. Even if you're personally against this,
| this is how most people talk about agents online.
|
| You don't always have the privilege of working on a
| project with tests, and rarely are they so thorough that
| they catch everything. Blindly trusting LLM output
| without QA or Review shouldn't be normalized.
| blitz_skull wrote:
| Who is normalizing merging ANYTHING, LLM-generated or
| human-generated, without QA or review?
|
| You should be reviewing everything that touches your
| codebase regardless of source.
| Capricorn2481 wrote:
| A LOT of people, if you're paying attention. Why do you
| think that happened at their company?
|
| It's not hard to find comments from people vibe coding
| apps without understanding the code, even apps handling
| sensitive data. And it's not hard to find comments saying
| agents can run by themselves.
|
| I mean people are arguing AGI is already here. What do
| you mean who is normalizing this?
| st3fan wrote:
| The first two cases indicate that you have some gaps in
| your change management process. Strict requirements for
| pulls and ci/cd checks.
| Syzygies wrote:
| Using AI to write good code faster is hard work.
|
| I once toured a dairy farm that had been a pioneer test
| site for Lasix. Like all good hippies, everyone I knew
| shunned additives. This farmer claimed that Lasix wasn't
| a cheat because it only worked on really healthy cows.
| Best practices, and then add Lasix.
|
| I nearly dropped out of Harvard's mathematics PhD
| program. Sticking around and finishing a thesis was the
| hardest thing I've ever done. It didn't take smarts. It
| took being the kind of person who doesn't die on a
| mountain.
|
| There's a legendary Philadelphia cook who does pop-up
| meals, and keeps talking about the restaurant he plans to
| open. Professional chefs roll their eyes; being a good
| cook is a small part of the enterprise of engineering a
| successful restaurant.
|
| (These are three stool legs. Neurodivergents have an
| advantage using AI. A stool is more stable when its legs
| are further apart. AI is an association engine. Humans
| find my sense of analogy tedious, but spreading out
| analogies defines more accurate planes in AI's
| association space. One doesn't simply "tell AI what to
| do".)
|
| Learning how to use AI effectively was the hardest thing
| I've done recently, many brutal months of experiment,
| test projects with a dozen languages. One maintains
| several levels of planning, as if a corporate CTO. One
| tears apart all code in many iterations of code review.
| Just as a genius manager makes best use of flawed human
| talent, one learns to make best use of flawed AI talent.
|
| My guess is that programmers who write bad code with AI
| were already writing bad code before AI.
|
| Best practices, and then add AI.
| blitz_skull wrote:
| I wish I could just ship 99% AI generated code and never
| have to check anything.
|
| Where is everyone working where they can just ship broken
| code all the time?
|
| I use LLMs for hours, every single day, yes sometimes
| they output trash. That's why the bottleneck is checking
| the solutions and iterating on them.
|
| All the best engineers I know, the ones managing 3-4
| client projects at once, are using LLMs nonstop and
| outputting 3-4x their normal output. That doesn't mean
| LLMs are one-shotting their problems.
| citizenpaul wrote:
| I agree with everything you wrote.
|
| You are overlooking a blind spot, that is increasingly
| becoming a weakness for devs. You assume that businesses
| care that their software actually works. It sounds crazy
| from the dev side but they really don't. As long as cash
| keeps hitting accounts the people in charge MBAs do not
| care how it gets there and the program to find that out
| only requires one simple unmistakable algo Money In -
| money out.
|
| evidence
|
| Spreadsheets. These DSL lite tools are almost universally
| known to be generally wrong and full of bugs. Yet, the
| world literally runs on them.
|
| Lowest bidder outsourcing. Its well known that various
| low cost outsourcing produces non functional or failed
| projects or projects that limp along for years with
| nonstop bug stomping. Yet business is booming.
|
| This only works in a very rich empire that is in the
| collapse/looting phase. Which we are in and will not
| change. See: History.
| croes wrote:
| I bet LLMs create their version of Jevons paradox.
|
| More trial and error because trial is cheap, in the end
| less typing but hardly faster end results
| treyd wrote:
| I don't think this is actually true. LLMs have an
| impressive amount of ability to do knowledge-transfer
| between domains, it only makes sense that that would also
| apply to programming languages, since the basic underlying
| concepts (functions, data structures, etc.) exist nearly
| everywhere.
|
| If this does appear to become a problem, is it not hard to
| apply the same RLHF infrastructure that's used to get LLMs
| effective at writing syntactically-correct code that
| accomplishes sets of goals in existing programming
| languages to new ones.
| troupo wrote:
| > LLMs have an impressive amount of ability to do
| knowledge-transfer between domains, it only makes sense
| that that would also apply to programming languages,
| since the basic underlying concepts (functions, data
| structures, etc.) exist nearly everywhere.
|
| That would make sense if LLMs _understood_ the domains
| and the concepts. They don 't. They need a lot of
| training data to "map" the "knowledge transfer".
|
| Personal anecdote: Claude stopped writing Java-like
| Elixir only some time around summer this year (Elixir is
| 13 years old), and is still incapable of writing "modern
| HEEX" which changed some of the templaring syntax in
| Phoenix almost two years ago.
| CraigJPerry wrote:
| > but LLMs can only learn languages that programmers write
| a sufficient amount of code in
|
| i wrote my own language, LLMs have been able to work with
| it at a good level for over a year. I don't do anything
| special to enable that - just front load some key examples
| of the syntax before giving the task. I don't need to
| explain concepts like iteration.
|
| Also llm's can work with languages with unconventional
| paradigms - kdb comes up fairly often in my world (array
| language but also written right to left).
| Xmd5a wrote:
| LLMs still struggle with lisp parens though
| ferfumarma wrote:
| You raise such an interesting point!
|
| But consider: as LLMs get better and approach AGI you won't
| need a corpus: only a specification.
|
| In this way, AI may enable _more_ languages, not less.
| zerotolerance wrote:
| Pure anecdote. Over the last year I've taken the opportunity
| to compare app development in Swift (+ SwiftUI and SwiftData)
| for iOS with React Native via Expo. I used Cursor with both
| OpenAI and Anthropic models. The difference was stark. With
| Swift the pace of development was painfully slow with
| confused outputs and frequent hallucinations. With React and
| Expo the AI was able to generate from the first few short
| prompts what it took me a month to produce with Swift. AI in
| development is all about force multipliers, speed of
| delivery, and driving down cost per product iteration. IMO
| There is absolutely no reason to choose languages,
| frameworks, or ecosystems with weaker open corpuses.
| innocentoldguy wrote:
| I don't mean to minimize the huge effort by the Gleam team;
| however, Elixir cannot become Gleam without breaking OTP/BEAM
| in the same ways Gleam does. As it stands now, Elixir is the
| superior language between the two, if using the full Erlang VM
| is your goal.
| worthless-trash wrote:
| I use many of the otp functions in gleam on thr regular, what
| functionality cant i call?
|
| Gleam can call any erlang function, and can somewhat handle
| the idc types. [ im sure it has another name ].
|
| Did i miss something that gleam fails on, because this is one
| of my concerns.
| market_hacker wrote:
| i just implemented a project in elixir with LLM support and
| would never have considered that before. (i had never used
| elixir before) - So who knows maybe it will help adoption?
| troupo wrote:
| > what I wish Elixir would become (re:typing).
|
| Elixir is slowly rolling out set-theoretic typing:
| https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...
| tasuki wrote:
| I dunno, my unfounded guess is that gradual type systems are
| super complex and very hard to get right.
|
| Why use something complex and half working, when you can have
| the real thing?
| troupo wrote:
| They are working towards "the real thing", whatever your
| definition of real is.
|
| BTW in the 90s people tried to come up with a type system
| for Erlang, and failed:
|
| --- start quote ---
|
| Phil Wadler[1] and Simon Marlow [2] worked on a type system
| for over a year and the results were published in [3]. The
| results of the project were somewhat disappointing. To
| start with, only a subset of the language was type-
| checkable, the major omission being the lack of process
| types and of type checking inter-process mes-sages.
| Although their type system was never put into production,
| it did result in a notation for types which is still in use
| today for informally annotating types.
|
| Several other projects to type check Erlang also failed to
| produce results that could be put into production. It was
| not until the advent of the Dialyzer [4] that realistic
| type analysis of Erlang programs became possible.
|
| https://lfe.io/papers/%5B2007%5D%20Armstrong%20-%20HOPL%20I
| I...
|
| --- end quote ---
|
| [1] Yes, that Philip Wadler,
| https://en.wikipedia.org/wiki/Philip_Wadler
|
| [2] Yes, that Simon Marlow,
| https://en.wikipedia.org/wiki/Simon_Marlow
|
| [3] _A practical subtyping system for Erlang_
| https://dl.acm.org/doi/10.1145/258948.258962
|
| [4] https://www.erlang.org/doc/apps/dialyzer/dialyzer.html
| devalexwells wrote:
| I've also been wanting to make Gleam my primary language (am
| generally a Typescript dev), and I have not had any issue with
| using it with LLMs (caveat, I'm obviously still new with it, so
| might just be ignorant).
|
| In fact, I'd say most of the Gleam code that has been generated
| has been surprisingly reliable and easy to reason about. I
| suspect this has to do with the static typing, incredible
| language tooling, and small surface area of the language.
|
| I literally just copy the docs from
| https://tour.gleam.run/everything/ into a local MD file and let
| it run. Packages are also well documented, and Claude has had
| no issue looping with tests/type checking.
|
| In the past month I've built the following, all primarily with
| Claude writing the Gleam parts:
|
| - A websocket-first analytics/feature flag platform (Gleam as
| the backend): https://github.com/devdumpling/beacon
|
| - A realtime holiday celebration app for my team where Gleam
| manages presence, cursor state, emojis, and guestbook writes
| (still rough): https://github.com/devdumpling/snowglobe
|
| - A private autobattler game backend built for the web
|
| While it's obviously not as well-trodden as building in
| typescript or Go or Rust, I've been really happy with the
| results as someone not super familiar with the BEAM/Erlang.
|
| EDIT: Sorry I don't have demos up for these yet. Wasn't really
| ready to share them but felt relevant to this thread.
| constructive wrote:
| gleam would never take off because of shoving political
| ideologies onto developers. if you're into software then keep
| politics out of your code. i would pick elixir any day over
| gleam just for this reason.
| nodra wrote:
| I don't know anything about gleam. I couldn't find anything
| as "shoving political ideologies" on their code of conduct
| https://github.com/gleam-
| lang/gleam/blob/main/CODE_OF_CONDUC...
|
| Examples?
| 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
| scuff3d wrote:
| 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.
| tasuki wrote:
| > And I can't believe there's still people defending
| Elm's lack of development
|
| Why? (I'm one such person defending Elm's lack of
| development)
| scuff3d wrote:
| From the outside the project honestly does look kind of
| dead, what's your take on the development and community?
| aryonoco wrote:
| 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.
| scuff3d wrote:
| The Roc programing language is being developed because
| Richard Feldman wanted an Elm like experience in more
| places then just the front end.
| tasuki wrote:
| > the lack of compiler releases
|
| I'm a backend dev mostly and use Elm for all my frontend
| needs. Yes there are some things compiler-side that could be
| improved, but basically it's fine.
|
| I appreciate not having to keep up with new releases!
| 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
| thelastgallon wrote:
| This Lustre? https://www.lustre.org/
|
| Seems to be a filesystem, how would it replace a database?
| Shadow20 wrote:
| This one is likely what they were referring to:
| https://github.com/lustre-labs/lustre
| okkdev wrote:
| No, this one https://hexdocs.pm/lustre/index.html
| dminor wrote:
| I looked at lustre for a recent project and it seems very nice.
| But the ecosystem is pretty small yet (I could find no examples
| of auth, for one), so I ended up going with liveview.
|
| I'm hoping it succeeds and gets bigger because I really like
| its ergonomics.
| 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');
| Phelinofist wrote:
| I use NoScript and only got them after enabling JS for
| the blog page
| jphoward wrote:
| 'Ruined' is a bit strong, isn't it?
| 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.
| stuartaxelowen wrote:
| Does that mean pass every needed function as a parameter?
| Or just don't write generic functionality?
| lpil wrote:
| Yes, one would use higher order functions, as is common
| in Erlang, Elixir, OCaml, Elm, etc.
| shirogane86x wrote:
| At least half of those languages (Elixir and OCaml) have
| some sort of mechanism for ad hoc polymorphism (elixir
| has behaviors and protocols, OCaml has higher order
| modules) so I feel like the comparison doesn't work that
| well personally
| lpil wrote:
| OCaml's modules are not implicitly instantiated, so they
| provide the same DX and APIs as you would get in Gleam.
|
| Elixir does have protocols, but they are extremely
| limited compared to type classes, traits, etc, and
| they're uncommonly used compared to writing concrete
| code.
| 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.
| array_key_first wrote:
| It's not a "hack" because many language DO NOT let you
| store functions with state. Gleam does, I write PHP, and
| that does as well.
|
| PHP has interfaces and whatnot, but a lot of the time I do
| polymorphism by just having a class that has Closure
| members. When you can arbitrarily pass around functions
| like that, it's basically equivalent to an interface or
| abstract class, with a bit more flexibility.
| 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?
| zelphirkalt wrote:
| Guards also eliminate checking for whether a pattern
| matching is comprehensive. Or do I remember wrong and the
| language does not check it at all?
| 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.
| Hasnep wrote:
| This sounds like the kind of situation where the LSP could
| suggest the simpler code, I'll see if there's an issue for it
| already and suggest it if not.
| pdimitar wrote:
| Elixir has one opinionated formatter -- Quokka -- that will
| rewrite the code above properly. It can also reuse linting
| rules as rewrite policies. Love using it.
| 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.
| sprkv5 wrote:
| If you like ML-ness try ReScript v12. It occupies a nice
| middle-ground between OCaml and Gleam.
| tasuki wrote:
| Heh, similar thoughts! The main difference that I only used
| Scheme for SICP, and I've used a bit of Haskell.
|
| I like Haskell in theory, but: just to get a hello world takes
| a lot of CPU and disk space. The standard library is full of
| exceptions (you can use a different prelude, that opens a whole
| different can of worms). The ergonomics of converting between
| the thousand different string types are awful.
|
| So, you being basically me, I have some recommendations:
|
| Idris (2): good stdlib, has dependent types. A beautiful
| language. The compiler is self-hosted and bootstrapped by lisp
| - very elegant! The ecosystem is basically nonexistent though.
|
| PureScript: also improves on Haskell in many ways. But, it's
| more of a frontend language, and though you can do backend,
| you're stuck with JavaScript runtime. Oh well.
| tome wrote:
| > The standard library is full of exceptions
|
| By the way, the number of partial functions is base that
| throw compiler warnings is increasing, for example:
|
| https://hackage.haskell.org/package/base-4.21.0.0/docs/Prelu.
| ..
|
| I hope it will increase further.
| theThree wrote:
| I don't know if I'm the only one experiencing this: It's too hard
| to find the download link from their website.
| zelphirkalt wrote:
| I think most people will use package managers to install it, or
| will use docker images to run code in.
| tasuki wrote:
| > You can do [first, ..rest] and you can do [first, second].
|
| > But you cannot do [first, ..middle, last].
|
| I don't think you're supposed to do that! It's probably
| expensive!
| socalgal2 wrote:
| The `echo` part seemed interesting but it made me think,
| debuggers need this as a built in feature. If I have
| array .slice(0, 10) .filter(s =>
| s[0].toLowerCase() < 'm') // a<->l .map(s =>
| s.toUpperCase());
|
| It seems like it should be a common feature to be able to view
| between each array operation in a debugger without having to
| augment the code with `echo`
|
| The out of bounds handling didn't seem all that good to me. Sure
| you can filter out undefined. You could also just make a function
| that returns an empty array if out of bounds, or array of 1
| element if not. // JS function
| getElemFromGrid(grid, x, y) { return (x < 0 || x >=
| grid.width || y < 0 || y >= grid.height)
| ? [] : [grid.elems[y][x]] }
| ... neighbors = [
| ...getElemFromGrid(grid, x + 1, y + 0),
| ...getElemFromGrid(grid, x + 1, y + 1),
| ...getElemFromGrid(grid, x + 0, y + 1),
| ...getElemFromGrid(grid, x - 1, y + 1),
| ...getElemFromGrid(grid, x - 1, y + 0),
| ...getElemFromGrid(grid, x - 1, y - 1),
| ...getElemFromGrid(grid, x + 0, y - 1),
| ...getElemFromGrid(grid, x + 1, y - 1), ]
|
| I also find grids made of 2 dimensional array to be code small.
| An array of arrays is NOT A GRID as there is nothing enforcing
| the inner arrays to be the same length as each other. Also, in
| efficienct code it would be better to provide a 1 dimensional
| array and bounds. Now, out of bounds checks based on accessing
| outside the array won't work. You need to check actual bounds.
| Again giving preference using a helper
| lysecret wrote:
| When I was debugging through f# code they definitely had that.
| nick4 wrote:
| Something I really hope Gleam figures out is a way to streamline
| the Elm architecture. We see the Elm architecture mostly in web
| apps, but I think that model is a really good idea for a lot of
| applications!
|
| But I think two things really hold it back:
|
| * it's verbose.
|
| * they compose awkwardly.
|
| Neither of these are showstoppers, but I think fixing these
| problems--maybe with something like syntax-level support--could
| really lead to a beautiful programming language.
| phplovesong wrote:
| Gleam should add Go as an target. That would have a huge
| potentital, as the Go runtime is second to none, and its
| ecosystem is enormous.
___________________________________________________________________
(page generated 2025-12-14 20:00 UTC)