> I’ve also heard that functional languages lend themselves especially well to parsing tasks, and I’ve never understood why, so it’s a good opportunity to learn.
This is mainly due to a technique called "parser combinators", which can be expressed very cleanly in functional languages. The idea is to start with a standard set of primitive general-purpose parsers and combine them into more complex parsers that are specific to the task at hand. If you have an interest in either functional programming or parsing in general, parser combinators are good to have in your toolkit.
It looks like Gleam has at least two parser combinator packages that you might be able to use:
• party (https://hexdocs.pm/party/)
• parser_gleam (https://hexdocs.pm/parser_gleam/)
Don’t know about difficult, but at least less elegant. Lazy evaluation, type inference, abstractions like Functor/Applicative/Alternative/Monad make them so incredibly natural to work with in a language like Haskell. Sure, they exist in other languages (made a few myself) but it’s not the same.
Gleam has long kinda seemed like my idea programming language. My only real hang-up is maybe an irrational one, but I don't love that it needs either a VM (BEAM) to run, or for it to be compiled to an interpreted language (javascript). I really wish it could target LLVM or something so it could be compiled down to native.
Maybe someone can sell me on BEAM though.
EDIT: The comments below are indeed beginning to sell me on BEAM, I'm realizing my reluctance might come from some negative experiences I've had dealing with the JVM.
The BEAM is very lightweight and necessary within Erlang to enforce one of its greatest tradeoffs:
- No universal garbage collector, every process (aka green thread) has its own heap that is reclaimed when it dies.
- No process can takeover the CPU. If you run a hugely intensive task in one process, everything else, millions of other processes potentially, will continue responding normally and consistently. The hugely intensive task will just take longer.
There’s more that applies to some advanced use cases, but these are the 2 core elements that are awesome.
The BEAM is an amazing piece of technology. It’s built to scale massive concurrent systems and has great developer ergonomics. I’ve used it with Elixir and it’s really a breath of fresh air as far as running a webserver goes. Much more flexible and simpler to manage than a python or nodejs runtime, and also capable of scaling up with far fewer resources than you would think. Highly recommend giving it a go!
I have never seriously used a BEAM language (Elixir/Erlang/Gleam), but for me, it’s the opposite: the most attractive part of Gleam is that it runs on BEAM :)
My reservations at this point are mostly around maturity of the language, the stdlib, and the library ecosystem; although I haven’t been following progress too closely.
You need the BEAM because operating systems we have available do not have the properties of the BEAM.
OS processes are far to heavy and slow to start, and the scheduler doesn’t work the way erlang needs it to. The BEAM solves those issues amongst others.
Also you need the BEAM for hot swapping code at runtime without taking the system offline.
> [...] It’s an Elixir-like language that supports static typing.
Maybe just me, but when I tried Gleam it really came off much more like Rust. In fact, other than running on the BEAM (and having some OTP libs in the works), it doesn't really _feel_ like Elixir at all to me, but that is definitely an opinion.
How good is the interop story with Elixir/Erlang currently? Can I include a few gleam modules in my Elixir application and let mix take care of compiling and linking everything properly?
They probably just mean "BEAM language that isn't Erlang."
All BEAM languages always bring something new to the table aside from just syntax (for Gleam it's static type, for Elixir it's macros and, well, mix!) but none of them try and abstract away the core tenants of the BEAM being functional working with modules and processes. So ya, in that sense you could say it's like Elixir.
Gleam has caught my eye for the past year or so, and I'd totally learn it if I didn't believe firmly that we won't be coding by hand within the next 9 months. It'll all be done by LLMs so syntax and ergonomics won't mean too much. At least as soon as LLMs learn to stop being turbo-slop generators.
9 months? I mean... 9 years maybe. There's absolutely no way we won't be coding by hand in 9 months, unless the only thing you do is landing pages and CRUD forms.
Doe LLMs write valid Gleam programs? Trying with ChatGPT three years ago, it did not. Workarounds, like "here is the syntax as a system prompt", put into the prompt I would not consider understanding, as Gleam idioms and patterns will certainly not all fit.
The only languages Im interested in are future proof AI resistant languages. Since LLMs need alot of training (because they cant read language ASTs and write code correctly), a language that either isnt possible to express using fonts and character sets on the Internet, can only live in a private cloud, and is known to only verified practitioners runs on everything, and yet cant be decompiled.
You can launch a nuclear war in 5 lines of Visual Basic. I want a language AI doesnt know and cannot ever know.
Thats ok. We have done enough language research to build another powerhouse language that is AI resistant that practitioners can use. Its uptake is only relevant to those that wish to exclude LLMs from the picture to resist the agents. When LLM agents are everywhere secret societies will become the norm.
We may even have the expertise to actually transpile every single program into a unique programming language so that if the source were available LLM bots would not recognize it in any volume enough to learn from it.
> I’ve also heard that functional languages lend themselves especially well to parsing tasks, and I’ve never understood why, so it’s a good opportunity to learn.
This is mainly due to a technique called "parser combinators", which can be expressed very cleanly in functional languages. The idea is to start with a standard set of primitive general-purpose parsers and combine them into more complex parsers that are specific to the task at hand. If you have an interest in either functional programming or parsing in general, parser combinators are good to have in your toolkit.
It looks like Gleam has at least two parser combinator packages that you might be able to use:
I don't think parser combinators are any more difficult in imperative languages like Python than functional ones? I found a few for Python and C++.
Don’t know about difficult, but at least less elegant. Lazy evaluation, type inference, abstractions like Functor/Applicative/Alternative/Monad make them so incredibly natural to work with in a language like Haskell. Sure, they exist in other languages (made a few myself) but it’s not the same.
Or thanks to algebraic data types and pattern matching? Even in a modest recursive descent parser, these can be really nice to use.
Sure, although those are great FP features for all kinds of programming, not just parsing.
My biggest problem with gleam is the lack of any kind of ad-hoc polymorphism (interface, trait, typeclass, protocol, etc.).
It also seems weird to make a language for BEAM that depends on a separate library for actors and concurrency.
Gleam has long kinda seemed like my idea programming language. My only real hang-up is maybe an irrational one, but I don't love that it needs either a VM (BEAM) to run, or for it to be compiled to an interpreted language (javascript). I really wish it could target LLVM or something so it could be compiled down to native.
Maybe someone can sell me on BEAM though.
EDIT: The comments below are indeed beginning to sell me on BEAM, I'm realizing my reluctance might come from some negative experiences I've had dealing with the JVM.
The BEAM is very lightweight and necessary within Erlang to enforce one of its greatest tradeoffs:
- No universal garbage collector, every process (aka green thread) has its own heap that is reclaimed when it dies.
- No process can takeover the CPU. If you run a hugely intensive task in one process, everything else, millions of other processes potentially, will continue responding normally and consistently. The hugely intensive task will just take longer.
There’s more that applies to some advanced use cases, but these are the 2 core elements that are awesome.
The BEAM is an amazing piece of technology. It’s built to scale massive concurrent systems and has great developer ergonomics. I’ve used it with Elixir and it’s really a breath of fresh air as far as running a webserver goes. Much more flexible and simpler to manage than a python or nodejs runtime, and also capable of scaling up with far fewer resources than you would think. Highly recommend giving it a go!
I have never seriously used a BEAM language (Elixir/Erlang/Gleam), but for me, it’s the opposite: the most attractive part of Gleam is that it runs on BEAM :)
My reservations at this point are mostly around maturity of the language, the stdlib, and the library ecosystem; although I haven’t been following progress too closely.
You need the BEAM because operating systems we have available do not have the properties of the BEAM.
OS processes are far to heavy and slow to start, and the scheduler doesn’t work the way erlang needs it to. The BEAM solves those issues amongst others.
Also you need the BEAM for hot swapping code at runtime without taking the system offline.
> [...] It’s an Elixir-like language that supports static typing.
Maybe just me, but when I tried Gleam it really came off much more like Rust. In fact, other than running on the BEAM (and having some OTP libs in the works), it doesn't really _feel_ like Elixir at all to me, but that is definitely an opinion.
How good is the interop story with Elixir/Erlang currently? Can I include a few gleam modules in my Elixir application and let mix take care of compiling and linking everything properly?
They probably just mean "BEAM language that isn't Erlang."
All BEAM languages always bring something new to the table aside from just syntax (for Gleam it's static type, for Elixir it's macros and, well, mix!) but none of them try and abstract away the core tenants of the BEAM being functional working with modules and processes. So ya, in that sense you could say it's like Elixir.
I've kind of gotten a
Scala : Gleam :: JavaScript : Lua
vibe from it.
It also most reminded me of Scala.
There was a great talk on Gleam at the Carolina Code Conference in 2024.
https://youtu.be/vyEWc0-kbkw?si=3o-KasK4H2n-0_KD
This was a great read! One thing that def makes Gleams error handling _look_ nicer, is utilizing `result.try` with the `use` keyword.
I'm glad I'm not the only one who hoarded all their AIM log data. Whenever I want to cringe I can pull up a random file
Gleam has caught my eye for the past year or so, and I'd totally learn it if I didn't believe firmly that we won't be coding by hand within the next 9 months. It'll all be done by LLMs so syntax and ergonomics won't mean too much. At least as soon as LLMs learn to stop being turbo-slop generators.
9 months? I mean... 9 years maybe. There's absolutely no way we won't be coding by hand in 9 months, unless the only thing you do is landing pages and CRUD forms.
See you in 9 months then to check back.
Doe LLMs write valid Gleam programs? Trying with ChatGPT three years ago, it did not. Workarounds, like "here is the syntax as a system prompt", put into the prompt I would not consider understanding, as Gleam idioms and patterns will certainly not all fit.
GP is crazy, but if you are basing your view of what LLMs can do based on ChatGPT 3 years ago, that is just as much out of touch.
You should learn Gleam then.
> if I didn't believe firmly that we won't be coding by hand within the next 9 months.
LLM-assisted coding is awesome, but it feels like a self-driving style problem.
It's going to take 20 years to get there.
The only languages Im interested in are future proof AI resistant languages. Since LLMs need alot of training (because they cant read language ASTs and write code correctly), a language that either isnt possible to express using fonts and character sets on the Internet, can only live in a private cloud, and is known to only verified practitioners runs on everything, and yet cant be decompiled.
You can launch a nuclear war in 5 lines of Visual Basic. I want a language AI doesnt know and cannot ever know.
https://en.wikipedia.org/wiki/Malbolge
You better start writing your own compilers then
>and cannot ever know
It might be resistant to human uptake in that case, too? Brett Victor I suppose has some interesting human-first or human-only physical computers.
Thats ok. We have done enough language research to build another powerhouse language that is AI resistant that practitioners can use. Its uptake is only relevant to those that wish to exclude LLMs from the picture to resist the agents. When LLM agents are everywhere secret societies will become the norm.
We may even have the expertise to actually transpile every single program into a unique programming language so that if the source were available LLM bots would not recognize it in any volume enough to learn from it.