I Tried Gleam for Advent of Code, and I Get the Hype
85 points by Tymscar
85 points by Tymscar
I have loved writing gleam so far except for their militant stance on keeping stdlib tiny and letting the community provide it all. if you want to see how that works out long term look at node/npm
letting the community provide it all.
Not quite! It's that we maintain multiple packages rather than one single large one.
It's entirely possible I've missed something, but when I looked for answers to my questions in the forums/github, these were the reasons provided. Where is the official standard library function for, say, file IO? Http serving?
For file system IO specifically there's not a core team maintained one as a community member published one very early in Gleam's history, back when the core language was still being implemented and before the core team had started working on the ecosystem.
Despite not being the official maintainers of that package the core team has made numerous contributions to it and will continue to do so. Should there ever become a problem with that one we will take ownership or fork it, depending on what is more appropriate.
Most of the packages people get off npm are not things which could be in a standard library of any reasonable size. Look at the dependency trees of some random projects and see for yourself.
There's some exceptions like CLI argument parsers or glob expansion (which are incidentally now included in node, but people understandably haven't migrated off old dependencies). I'm not saying that a bigger standard library wouldn't reduce the amount of stuff people pull from npm. But it would be a factor of 2 for the whole tree at most, not an order of magnitude.
in your examples, I see prisma has is-function, and long as transitive dependencies. Remember, it's not just your direct dependencies you depend on, your project depends on the full graph of everything your dependencies and their dependencies need, recursively, and that is a better place to look if you want to see what I'm talking about.
Furthermore, what is the consequence if everyone providers their own "is-function"? You end up with 10 "is function" dependencies because each of your dependencies picked a different favorite version.
The 2nd and 3rd order consequences of tiny stdlib are super observable as pain points that the JS community has to suffer everyday.
Prisma does not depend on is-function, transitively or otherwise, possibly because this is something which is trivially accomplished using built-in syntax (not even a standard library method).
I maintain that even with a fairly expansive standard library these graphs would not look very different. It's true that there are a couple things which could be removed, but it's really not a very large fraction of anyone's transitive dependencies. You can just look at those graphs and confirm this for yourself. Or pick your own favorite project for comparison.
People like to assert this. It's true that JS has a fairly small standard library. This is something I personally have spent a lot of time working on improving. But it does not follow that this is the reason people's dependency trees are large. These facts are not really related. I know it seems intuitively like they should be, but if you look at the full dependency trees of actual projects, they're mostly not things which could be in a standard library.
Furthermore, what is the consequence if everyone providers their own "is-function"? You end up with 10 "is function" dependencies because each of your dependencies picked a different favorite version.
But they don't. Again, you can just actually look at the full dependency trees of real projects. Duplicate functionality in transitive dependencies is not a meaningful fraction of the tree.
Prisma does not depend on is-function
You're right, it was is-property. I shouldn't have dashed off my message in such haste. Prisma->mysql2->generate-function->is-property is the chain of dependency according to the graph you posted.
This is a legacy of choices made decades+ ago, but it is a real legacy and it definitely has effects like this down the line. Left-pad didn't happen in a vacuum, it followed on because of a gap in the stdlib that addressed real needs of many, many libraries and applications.
This is something I personally have spent a lot of time working on improving.
I really, really appreciate this. Thank you!! As an application developer, I choose languages based on the degree to which I don't have to maintain code that isn't directly relevant to the value of the application I'm building, and having a robust stdlib is a large part of how that happens.
I feel that. As a network engineer, the lack of TCP support has been rather disappointing.
There is a TCP package maintained by the creator of Gleam (me)
I wonder why we don't have a 'boost' for node.js, and I guess gleam. 'Boost' as in, single large library containing the missing 'batteries' for stdlib.
Because JS demands the smallest bundles possible (they are sent over the wire) and tree shaking is a) relatively new and b) hard to get right. We have had large libraries like lodash, underscore, etc. but the community has special technical requirements.
In this way, JS for the browser is closer to embedded dev than it is to python.
https://bower.sh/my-love-letter-to-front-end-web-development
I think this is sort of okay actually. Rust lacks a similar feature but that is okay in my opinion.
Sure, Rust is not gleam, but its STD is more on the sparse spectrum too: No RNG, no HTTP, …
I think it may have something to do with the language targeting both the Erlang VM and "JS". For example as said in the article there is no library for doing file IO. A library like simplifile decided to uses node:fs when targeting JS (but why not for example Deno.readFile?)
For "non pure" libraries it's a difficult decision what best to use on each backend and there may not even be a right answer (like with the readFile example)
Still they could at least provide an "idiomatic" interface for a default stdlib for all platforms.
That package uses node:fs because it is available on Node, Deno, and Bun, while Deno's file APIs are only available on Deno.
Still they could at least provide an "idiomatic" interface for a default stdlib for all platforms.
This is impossible due to the function colouring problem, which is unsolvable.
I'm out of the loop but I kinda hate Node's standard library. What's the current consensus there?
Do you have experience with Elixir? If so, I'm curious what benefits of using Gleam over Elixir popped up over the 12 days. Glancing through the Github link at the bottom, I only see a few syntactical differences (I've never used or even read Gleam code before).
Having written a lot of Elixir and a bit of Gleam, the primary difference is the static type checking and type inference, and the ability to target JS.
Gleam does not map 1:1 to Erlang/Elixir because it also compiles to JS. For one, send/receive and atoms are not core language features but they are implemented as libraries, and some OTP things are not implemented yet because it's not clear how they would map to a fully typed language.
You should probably think of it more as a very simple Rust instead.
The OTP part is wrong/dated AFAIK. All OTP API are usable via Gleam (through the Erlang port) what is partial is the Gleam Specific additions to OTP in this library: https://github.com/gleam-lang/otp.
From the README:
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.
From the author:
No, it means that one specific package only offers bindings to certain parts. It’s the documentation for one library, not the language.
He didn't explain there what this means, but I looked into it a bit and it seems that there is another library you need to install, which then provides access to all the Erlang features as library functions: https://github.com/gleam-lang/erlang
This gives you sending, receiving and so on as functions. I didn't understand why the repo gleam-lang/erlang is considered part of the language, but gleam-lang/otp isn't. But maybe there's another way to access these features as just syntax, which I missed.
Gleam looks interesting, but so does eqWAlizer (Facebook's type checker for Erlang), need to find some time to play with both.
If it’s a very simple rust, would it be technically possible to implement a third, natively compiled backend? (Suppose I want static compilation and execution speed faster than Go, ie faster than JS or Erlang for compute heavy work).
There are a few people working on Gleam-to-C backends, but it'd be hard to beat the BEAM backend in practice. It's actually surprisingly performant.
Never tried Elixir, but it looks like good fun. It's nice that you can use Elixir packages in Gleam too!
Funny, I also tried Gleam for AoC, and I don't get the hype at all. I have the same small annoying things as with Elixir and 90% is fine (or great, depending on your baseline level of hype).
To what others wrote, the only 2 non-"core" packages I needed in my few solutions was argv and file_streams, so the lack of input (the I in IO) also left me a little confused. file_streams seems to be using Erlang's io package via FFI (which is a perfectly valid choice, I just would have also expected that in the stdlib)
I guess my main problem, nitpicky as it sounds, was the lack of something like ? in Rust, so I could mercilessly ignore the Result() type check in doing something like this when I knew there were 2+ items in both levels:
let b = [[1,2],[3,4]]
let a = list.first(list.first(b))
and it became an unwieldy:
let assert Ok(a1) = list.first(b)
let assert Ok(a) = list.first(a1)
It's not a problem in proper code[tm] but it's a problem in AoC where you mostly want to golf a 10line function into 4 lines if you can because you don't do error handling anyway.
But maybe I missed some stuff.
Also if this sounded overly negative: No, not at all. I'm not enthusiastic, but I am interested. I might continue digging deeper, it was a mostly pleasant experience, just not mindblowingly fun (like when I started doing Rust)
I do the same thing (pick a different language every year) and I used Gleam back in 2023. I really liked it but definitely felt some of the rough edges of using a pre-1.0 language (or maybe just a language without wide adoption... when I got stuck I got really stuck). I would have loved to have echo back then!