Gleam, Coming from Erlang
76 comments
·February 25, 2025smj-edison
paradox460
I believe inoreader has this feature as well, they call it magic sort
facundo_olano
you should try the reader then https://github.com/facundoolano/feedi
barrenko
If anyone know of similar feeds like the OP's, kindly paste them.
lanthissa
I really like gleam, the vibes are 'right' for me in that its got a strong type system and a functional style. Coming from scala land, that feels natural.
I think the author hit on a core challenge gleam will have to face, outside of dx. its main niche would be highly scalable type safe server apps, pretty similar to what scala is/was originally imagined as.
Its very hard to occupy that niche when by definition the projects you look to take on are large enough for languages to be heavily scrutinized. Your CTO wont really care if you choose rust, node, or go for some internal tooling. They will absolutely care about what is being used for core distributed services, and that just makes adoption hard.
cle
Maybe, but there are also a lot of companies being started right now (compared to the 2010s). Scala and Go were significantly boosted by being used at small companies that got huge (Spark and Docker respectively).
h14h
I feel like Gleam's ability to compile to BEAM and JS is underutilized.
With how many people in the React/Typescript ecosystem are super excited about full stack type safety, this feature of Gleam feels like it's flying under the radar.
The pieces are there to have an unparraled DX for building everyday web apps, but the pieces haven't been assembled in a way that "clicks" for most people. At least, not that I've seen.
hinkley
I thought when I moved from Springboot + JavaScript to NodeJS I would enjoy the lack of context switching.
What I didn’t know about myself is that I hate JavaScript a little bit more than I hate Java and for different reasons. So I was volunteering for stories in one when I was feeling frustrated with the other. Now it’s just more JavaScript unless I work on CLI, CI/CD pipelines, or telemetry bugs, which are still almost half JavaScript. I cannot get away from it enough and every time I do that takes someone else’s opportunity to do the same.
I worry that all Gleam all the time would arrive at the same conclusion.
skydhash
IMO, JavaScript is fine for scripting. Same with Python, Lua, and others. Great for glue code or a small feature, when the bulk of the system is written is in a saner language with proper libraries.
hinkley
Any time you drag a language out of its sweet spot is gonna be a bad time.
Javascript is out of its sweet spot quite a bit, which is how we end up with typescript.
However statically strongly typed code is out of its sweet spot where prototyping and to an extent refactoring are concerned. And mercifully we now have progressively typed languages trying to fill that space.
greener_grass
This already exists with F#, OCaml, Scala, Haskell... it doesn't seem to be a big draw.
h14h
Somehow didn't know this --I can't help but wonder why.
The effort to make JS work on the server has been much more successful than any attempt to make server languages work on the client. Nothing jumps out to me as an obvious technical reason this is the case -- maybe it's moreso an imbalance in effort & attention?
ameliaquining
DOM APIs are only available in JavaScript, so doing things in the browser in a non-JavaScript language requires FFI—and it's a general truism of programming that FFI tends to be a pain point. Languages that target client-side web development try to compensate for this by offering language-native DOM abstractions of higher or lower quality, but usually you end up having to do something that these abstractions didn't anticipate, and/or incorporate a third-party library from npm, which forces you back into FFI. On the server it's much rarer for some critical piece of functionality to be available only in one language, because the server environment itself is language-agnostic.
mamcx
> Somehow didn't know this --I can't help but wonder why.
JS being the monolithic tyrant that other tyrants see with envy doesn't help.
In the server and elsewhere you have several major langs with big enough sub-cultures and a stablished ethos of sharing, even if that mean the second biggest tyrant of C.
JS developers overshadow any other tribe, so that mean that population could have much less exposure to polyglot alternatives.
And then all that libraries, that are made to make sad any FFI you can trow at it.
hombre_fatal
Server application development is just much different than UI/client development.
It's easy to make JS work on the server like it's easy to make anything viable on the server: it's just one machine running your code, and the runtime only has to interoperate with a well known interface (the OS) that barely changes. And then consider that a web server's interface to the "user" is over a single, abstract port.
In a browser application, you have to interface with JS to drive the UI building blocks (DOM and company). And the web API is async. And you have to build an interactive UI. And abstractions on top of all this are extremely leaky because they are hard to simply paper over and pretend they don't exist like you can on the server.
Often when I see a JS replacement on the browser, it seems to offer very little over JS beyond "hey look, it's not JS" which just isn't enough to justify the penalty.
Finally, the hard part of UI development is stuff like state management and deciding when things should rerender. Switching to a different language alone doesn't give you that. Figuring out a solution in JS, like MobX + React for example, probably does more for you than trying to make a whole new language work.
hamandcheese
Choosing not to use JS on the frontend is much riskier than choosing to use JS on the backend, IMO.
AzzieElbab
It is counterintuitive, but this feature did not do much for the Scala ecosystem. I wrote some toy projects but have not seen any in the real world.
lanthissa
some of the largest scala codebases under active development make heavy use of this feature.
hocuspocus
Sure but but the argument here is that Scala.js failed to grow the ecosystem. It doesn't convince people who aren't already.
innocentoldguy
I'm sure Gleam fits a niche—maybe something similar to Elm?—but I can't justify using it over Elixir because I'm not willing to trade things like
1. Full access to the BEAM.
2. Full access to OTP behaviours and other features.
3. Lisp-style macros.
4. Late-bound function calls.
5. Dynamic message passing.
6. Native supervision trees.
7. Internationalization.
for static types. Doing so feels like trading my car's engine for a suction cup phone holder.
(EDIT: Fixed formatting.)
juped
Elixir is all in on being an OTP language, and is a friend, not competitor, to Erlang (go ahead, call one from the other freely, the only friction is that module name atoms look a little weird in the other language).
Gleam is not entirely foreign but it sets itself further apart; it's all in on cloning Rust.
(Elixir's set-theoretic type system is _not_ a constructor-soup ML deal, by the way. The people who talk about "static type systems" now are people who caught the ML bug and think "is like ML" equals "types", and they will not find it satisfying, just like they don't find existing Dialyzer types satisfying. So that's the niche for Gleam.)
cardanome
Yeah, especially as Elixir is gradually gaining gradual typing support so you will get some level of static type safety anyway.
oDot
I run Gleam in production to great success[0][1]. It is a joy to use. Give it a try!
[1] https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...
zwnow
I dont know if its a brave issue or a mobile browser issue, but for me your login and signup buttons are cut in half
braebo
It’s a CSS issue, just needs `whitespace: nowrap;`
scns
Same on Firefox on mobile.
chuckledog
Compelling video!
AlphaWeaver
> OTP in Gleam is what took me the most effort to figure out. The hexdocs cover the basics but that wasn’t enough for me to get the concepts right, especially where they differed from their Erlang counterparts.
This was the biggest thing I noticed as well- core OTP concepts like gen_servers and supervision trees aren't covered in the language tour, the docs, or even the "Gleam for Erlang Users" page... it makes sense that it's missing if it's pre-1.0, but I was very confused when I didn't find anything about it at all.
asplake
Ooh, nice - Learn OTP with Gleam [1] – I was looking for something like that when I first looked at Gleam some time back
Edit: My (forgotten) comment when this was posted 10 months ago [2]: "So pleased to see this. Had fun playing with the language but at the time learning OTP seemed a big ask"
evnp
Nice read, appreciate the balanced analysis. I love how `use` seems to have become the defacto keyword for "weird stuff happens here," we have Gleam's `use` now, `use` v `import` in Elixir... `useEffect` hijinx elsewhere...
krashidov
There's also using in typescript (maybe soon in javascript).
https://www.totaltypescript.com/typescript-5-2-new-keyword-u...
Not sure I'm a fan of it tbh
evnp
Interesting, thanks for highlighting. It does seem like a good set of patterns for the language to cater to. Agree the syntax feels a bit unintuitive at first glance (as opposed to something like `with` context managers in Python, though lack of async probably makes things simpler there).
cardanome
Honestly with Elixir starting to implement gradual typing and having an mature ecosystem and amazing backend framework, it is probably the better horse to bet on for bigger projects on the OTP.
Not to say say that Gleam doesn't had has it's place, it is a very interesting language, just that Elixir is already a good and battle-proven language.
pmontra
Elixir has been in that place not too many years ago, on the verge of being mainstream. I'm not very sure that it's not still there now but I paid my bills with it for a while and I was generally happy with the language except for the handle this handle that verbosity. I liked the Ruby like syntax but I always said to the other devs in the team that an equivalent language with curly braces would be more successful because it would make many more developers feel at home. Gleam is a { } language and won't scare away anyone coming from C, C++, Java, JavaScript, TypeScript, Rust, Go, etc.
ljm
It makes me sad that some engineers would legitimately consider a lack of curly braces to be a criticism of a language or a reason not to use it, especially when you look at the absolute atrocities that can be committed with the syntax of many C-style languages.
Looking at you C++.
trenchgun
>As far as a “Rust without memory management and with better concurrency” goes, I knew going in that Gleam could only be part of the answer.
OCaml?
VWWHFSfQ
> The thing is: Rust comes with all the systems programming overhead, which in my opinion is not a good bargain if you are not, you know, programming systems. Alas, I’m too old to pick up my own garbage.
I struggled with this as well when I first started programming Rust. Until I got some great advice on the rust-users forum one day: just clone.
You don't have to struggle with the borrow checker, lifetimes, or anything else if you don't want to. Just clone everything. It's usually all your Pythons, Gos, and anything else with a GC is doing anyway. Clippy will tell you the easy places you can fix it. And when you get better and more confident, then you'll spot it yourself too.
So just clone, who cares. The RAII is going to clean up after you no matter what.
amedvednikov
> It's usually all your Pythons, Gos, and anything else with a GC is doing anyway.
GC langs don't do clones (copying), that's the point of the GC.
dxxvi
I agree. I think he meant Rc/Arc.
null
Not relevant to the discussion on language choice, but I love this part:
> The single remarkable feature of my reader is that I don’t sort posts chronologically but by “reverse frequency”. If I follow a news site that publishes twice an hour and an essayist that publishes every two months, I want the essayist at the top of my feed if they published yesterday, even if there are 30 more recent news posts.
I love the idea of seeing the less frequent posters at the top!