> 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.
Assuming you have the parsers for Builtin, Referenced, and Constrained, you're golden. (Haskell PCs look very similar, possibly even exactly the same minus different parenthesis for operator precedence reasons.
Compare Parsy for Python, particularly the verbosity (this parses SELECT statements in SQL):
select = seq(
_select=SELECT + space,
columns=column_expr.sep_by(padding + string(",") + padding, min=1),
_from=space + FROM + space,
table=table,
where=(space >> WHERE >> space >> comparison).optional(),
_end=padding + string(";"),
).combine_dict(Select)
The same thing in a FP-style language would be something like
The general notion of a “combinator” comes from functional programming, so parser combinators are native to FP. They can definitely be done in imperative languages also, but in my experience (C# specifically) are much more clunky. A dynamically typed language like Python might be suitable, because the interpreter is lenient, but I’m dubious about C++.
One thing you will definitely need in any language to produce a concise parser is the ability to define custom operators, like >>. and .>>. These are the “combinators”.
The way you would implement them in Python or C++ is using their functional facilities. Or you'd write a library that emulated them.
The key feature is first class functions, so you can have combinators like "or()", "and()", "repeat()", "optional()", etc, which take a function pointer as a parameter, as well as the input character stream; and returns the matched characters from the input stream, as well as the rest of the stream. When all combinators have this function signature, you can compose them easily, and writing the parser is becomes a matter of transcribing the ebnf grammar.
All Turing-complete languages are technically equivalent in capability, but that doesn't mean the same task will cost the same effort in each language.
The closer a task is to the limit of your ability to handle complexity, the more you will benefit from tools that simplify the task.
The choice of programming language unfortunately what tools are possible to implement ergonomically (in terms of both implementation and interface).
Id say mostly because of recursion is usually better for tree like ds, and builtin tco and exhaustive pattern matching. This is why ocaml is usually the goto for building a new languge prototype.
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.
Glad you say you're coming around on the BEAM. It really is a fantastic virtual machine. Of course if you look at my comment history you'll see I'm a big fan of it and tend to push it, but that's only because it has actually made my job (and hobby) of engineering easier.
There's something elegant about how everything lives inside a process, and communication between those processes is crazy simple, you just `send(pid, value)` and boom you can not only talk across large codebases, but you can talk across _networked clusters of BEAM VMs_ with little setup.
At my current job, we're using it on embedded Linux for IoT devices, and it's really amazing to section off the code into processes that, if something like an i2c sensor or component glitches out, just let the process crash, and have it be restarted automatically by a Supervisor into a fresh well known state.
Definitely give it a look, it's nothing like the JVM ;)
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.
BEAM's concurrency model makes it the ideal runtime for web servers IMO. Similarly, the ubiquity of JS in the browser makes it an excellent runtime to target as well.
I agree though that it would be amazing to compile Gleam code into universal native binaries. Would make it a fatalistic general-purpose language.
AFAIK it's entirely possible -- just more of a resourcing concern given the small team.
As others have pointed out. The BEAM is one of the most efficient VMs out there. It isnt FASTER than C or C++ but it is insanely efficient. Stuff like a simple hello world fits in small bytes in memory. The resilience of the BEAM is impeccable. Discord reaps the benefits and uses Rust when it needs to. I love backend systems and my ideal backend always winds up being similar to what BEAM provides OOTB.
My only reason for not using it is nobody pays me to use it, they pay me to write basic CRUD apps in .NET
I thought the whole point of Gleam is having a statically typed lang running in the BEAM VM? If you want something similar outside of it you probably want Scala, Rust, OCaml, etc.
I've found the JVM really gets in your way whenever you want to do something interesting with Scala. Rust is fantastic, but a lot of what I want to do can afford the overhead of a GC so that I can avoid lifetimes, borrows, etc...
I've not written any OCaml, but I've heard tell of its reputation of being hard to pick up.
I find Swift to be a nice, less Rust-y Rust. It uses automatic memory management by refcounting (I would call it a GC’d language but people start flame wars about it). Alas ecosystem is small and oddly shaped.
Like with Rust you can write very imperative code full of mutation and thingies with tons of methods, or you can write very functional code passing around immutable struct values types. It also has decent async story, and newly got “actors” and is heading towards optional rust like borrow checking.
I really _want_ to like Swift, but the development experience was so abysmal that it turned me off the language entirely.
I have been entertaining the thought of writing an LLVM frontend for Gleam, though. (I don't know what I'm doing, I don't know if this is doable, etc.)
I’ve been thinking about Fil-C as a compile target for high level language implementations that want decent performance with LLVM optimizations. You get GC for “free”, source compatibility with a large fraction of existing C/C++ libraries, and lots of control over memory layout and allocation. You’d still have to build the green threads / process runtime though. Maybe go would be an easier pathway since you get their green threads and GC for free.
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.
I like Python, but it's dynamically typed and slow-ish. I like Scala, but I've bumped into the pointy edges of the JVM (e.g.: type erasure) too many times. Rust is great but for most use-cases I am happy compromising with a GC than having to worry about liftimes and ownership and borrows, etc..
Gleam seems like a happy in-between for me, but not knowing much about BEAM and with my negative experiences with the JVM, I had concerns about the overhead.
I don't really have any experience with the JVM other than playing with Clojure. I don't have much to add to the other answers. Two things of note:
- BEAM trades slow CPU in favour of fast IO, so it's not great for number crunching.
- While it can be great for CLI utilities, the VM (although very lightweight) does have a noticeable startup time. It's under a second but it's not a good fit for something you would want to run often, ie, if you were building something like git.
As mentioned in other comments, its super power is its concurrency model. I've essentially forgotten what a mutex or semaphore or whatthaveyou is :)
As someone who isn’t a programmer, but enjoys dabbling, and has been curious about functional languages, this was a really helpful (and fun!) read!
Tutorials written by beginners are so valuable, because once you’re more experienced with a given subject, it’s hard to remember what it was like to be a beginner. It can feel vulnerable to write them because you have to expose your ignorance, but it’s such a great thing to do.
It really is a neat language. Sort of like the smaller more elegant language that has been waiting to break out of Haskell, but combined with Erlang. Definitely not the "standard" programming language but very very nice.
The core language is pretty small too. Any moderately experienced programmer can probably burn through the language tour and be ready for a few simple AoC problems in an afternoon or so. This is due to the language designer having a very strict dedication to keeping the language as simple as possible. (Much to the chagrin of my muscle memory, as I keep expecting pattern matching on function arguments to work but it doesn't)
> [...] 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.
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.
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?
I'm currently working on a prototype that does exactly this (in our case, the Gleam is essentially a typed calculation module wrapped in Elixir's great libraries for network and database interactions but its all net-new application instead of an existing Elixir codebase). Its not yet perfect, but I've been eagerly following along with this PR: https://github.com/elixir-lang/elixir/pull/14262#issuecommen...
Seems like (one of) the next Elixir releases will include the support you're looking for in mix.
This is going to be very good for Gleam IMO. Having a super-easy on-ramp for using Gleam in Elixir projects will let people experiment with implementing eg more complex business logic in Gleam, and allow gradual adoption. Naturally, this is not the focus of the Gleam project itself, but for me, using Gleam for the core of a project while having access to the amazing Elixir ecosystem is a dream come true. I've been using mix_gleam but it's not perfect and since I started using Gleam pre 1.0, and it's a low-velocity project, updating became too complicated and I actually ended up moving everything to Elixir recently.
I thought so too, although treating everything as data and functions is really nice [1].
Regarding the BEAM and why Gleam has a separate library for actors: [2]
> "One notable difference between Elixir and Gleam is that Elixir gets to just re-use the OTP code as-is (with some Elixir wrappers on top for convenience). Gleam concluded that the OTP is built expecting dynamic types, and that for best results in Gleam they'd need to re-implement the key primitives. That's why the example shown is an "Actor" not a GenServer - it serves the same purpose, and might even fit in a Supervision tree, but isn't actually a GenServer."
There's a brief snippet mentioning this in the Gleam OTP readme as well: [3]
> "Actors do not yet support all OTP system messages, so some of the OTP debugging APIs may not be fully functional."
I was tricked into trying Gleam earlier this summer, and really liked it! I anticipate that I will at least use it for all future web projects (one example: https://github.com/FIGBERT/bdab) due to my serious JavaScript allergy.
Gleam Decoders are something I haven’t fully wrapped my head around, but are supposedly very powerful and do exactly what this article is focused on (parsing input data into Gleam types) in a more(?) idiomatic way.
I moved to Gleam with all of my projects and am not going back. The language is fantastic but really the most impactful are the coding paradigms that it enables, especially the actor model and especially on the front end (The Elm Architecture)
https://nestful.app used to be TS + Vue but it's almost entirely Gleam now, with Lustre used for state management and only the views being Vue templates. Those will also be migrated away for a fully Lustre solution.
I tried with Gleam, I really wanted to like it. I really like Louis Pilfold and I like his goals for the language. But something about it just didn't click for me. It's a good language, but at the end of the day I just didn't enjoy writing it.
It might be something the author talked about, but I think the language might be too small. It's one of the things I dislike about Rust too. I prefer a more batteries included approach because I can't stand having to pull in a bunch of small dependencies.
My point was about the need to rely on external libraries. I'm not a fan of that approach. I don't care for it in Rust or JavaScript, and I get a similar vibe from Gleam.
I’d prefer a GC language with exhaustive matching on discriminated union types. Maybe “go + typescript type system + higher kinded types”. Swift is in the ballpark and would be a lot more appealing with the go tooling.
Ocaml? It garbage collected, primarily functional but with options for an imperative style when necessary. Of course its std isn't very good. I think Jane Street has done a lot improve things, but the whole ecosystem is still kind of a mess.
I just can’t with the OCaml header files. Like what the hell all the types are inferred but you’re gonna make me write a header file for each module???
Im on the same boat and this is coming from someone who loves the beam thanks to elixir, I think the marketing of the lang threw me of a bit. But I might give it a try this week, as im feeling a bit burnt out with elixir
earlier this week I was thinking why aren't there more languages around the actor model and completely forgot gleam exists
Gleam is cool. I absolutely love that it's statically typed (dynamic typing is one of the things that pushes me away from Elixir), and the core of the language is very well designed. I just hate how small it is. I shouldn't need to bring in an external dependency for friggin file i/o.
And I know the common argument is that's it due to the fact you can target either the BEAM or a web browser, but those arguments don't fly. The default target is the BEAM, the standard library can support that and use external packages for the browser.
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.
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 entire Gleam language tour (https://tour.gleam.run/everything/) is comprehensive. It contains examples of every language feature and prints to less than 70 pages - easily fits into the context window of any recent LLM.
> 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:
Parser combinators are very slow in languages without a sufficiently optimising compiler, I wouldn't recommend them here.
In Gleam pattern matching and the "splitter" package is the go-to for text parsing.
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.
Yes, I'm writing a parser in Unison (in the Haskell family) for ASN.1 at the moment. It's so clean to write parsers with parser combinators.
For example Asn1Type can be of form Builtin, Referenced, or Constrained. So a sum type.
Assuming you have the parsers for Builtin, Referenced, and Constrained, you're golden. (Haskell PCs look very similar, possibly even exactly the same minus different parenthesis for operator precedence reasons.Compare Parsy for Python, particularly the verbosity (this parses SELECT statements in SQL):
).combine_dict(Select)The same thing in a FP-style language would be something like
which would feed into something likeThe general notion of a “combinator” comes from functional programming, so parser combinators are native to FP. They can definitely be done in imperative languages also, but in my experience (C# specifically) are much more clunky. A dynamically typed language like Python might be suitable, because the interpreter is lenient, but I’m dubious about C++.
One thing you will definitely need in any language to produce a concise parser is the ability to define custom operators, like >>. and .>>. These are the “combinators”.
The way you would implement them in Python or C++ is using their functional facilities. Or you'd write a library that emulated them.
The key feature is first class functions, so you can have combinators like "or()", "and()", "repeat()", "optional()", etc, which take a function pointer as a parameter, as well as the input character stream; and returns the matched characters from the input stream, as well as the rest of the stream. When all combinators have this function signature, you can compose them easily, and writing the parser is becomes a matter of transcribing the ebnf grammar.
All Turing-complete languages are technically equivalent in capability, but that doesn't mean the same task will cost the same effort in each language.
The closer a task is to the limit of your ability to handle complexity, the more you will benefit from tools that simplify the task.
The choice of programming language unfortunately what tools are possible to implement ergonomically (in terms of both implementation and interface).
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.
Id say mostly because of recursion is usually better for tree like ds, and builtin tco and exhaustive pattern matching. This is why ocaml is usually the goto for building a new languge prototype.
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.
Glad you say you're coming around on the BEAM. It really is a fantastic virtual machine. Of course if you look at my comment history you'll see I'm a big fan of it and tend to push it, but that's only because it has actually made my job (and hobby) of engineering easier.
There's something elegant about how everything lives inside a process, and communication between those processes is crazy simple, you just `send(pid, value)` and boom you can not only talk across large codebases, but you can talk across _networked clusters of BEAM VMs_ with little setup.
At my current job, we're using it on embedded Linux for IoT devices, and it's really amazing to section off the code into processes that, if something like an i2c sensor or component glitches out, just let the process crash, and have it be restarted automatically by a Supervisor into a fresh well known state.
Definitely give it a look, it's nothing like the JVM ;)
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.
Having done quite a bit of erlang, I think the gleam stdlib learned quite a bit from erlang and elixir and hasn't fallen into some of the same traps.
This allows things like the pipe operator |> to be a little saner.
BEAM's concurrency model makes it the ideal runtime for web servers IMO. Similarly, the ubiquity of JS in the browser makes it an excellent runtime to target as well.
I agree though that it would be amazing to compile Gleam code into universal native binaries. Would make it a fatalistic general-purpose language.
AFAIK it's entirely possible -- just more of a resourcing concern given the small team.
As others have pointed out. The BEAM is one of the most efficient VMs out there. It isnt FASTER than C or C++ but it is insanely efficient. Stuff like a simple hello world fits in small bytes in memory. The resilience of the BEAM is impeccable. Discord reaps the benefits and uses Rust when it needs to. I love backend systems and my ideal backend always winds up being similar to what BEAM provides OOTB.
My only reason for not using it is nobody pays me to use it, they pay me to write basic CRUD apps in .NET
I thought the whole point of Gleam is having a statically typed lang running in the BEAM VM? If you want something similar outside of it you probably want Scala, Rust, OCaml, etc.
I've found the JVM really gets in your way whenever you want to do something interesting with Scala. Rust is fantastic, but a lot of what I want to do can afford the overhead of a GC so that I can avoid lifetimes, borrows, etc...
I've not written any OCaml, but I've heard tell of its reputation of being hard to pick up.
I find Swift to be a nice, less Rust-y Rust. It uses automatic memory management by refcounting (I would call it a GC’d language but people start flame wars about it). Alas ecosystem is small and oddly shaped.
Like with Rust you can write very imperative code full of mutation and thingies with tons of methods, or you can write very functional code passing around immutable struct values types. It also has decent async story, and newly got “actors” and is heading towards optional rust like borrow checking.
I really _want_ to like Swift, but the development experience was so abysmal that it turned me off the language entirely.
I have been entertaining the thought of writing an LLVM frontend for Gleam, though. (I don't know what I'm doing, I don't know if this is doable, etc.)
I’ve been thinking about Fil-C as a compile target for high level language implementations that want decent performance with LLVM optimizations. You get GC for “free”, source compatibility with a large fraction of existing C/C++ libraries, and lots of control over memory layout and allocation. You’d still have to build the green threads / process runtime though. Maybe go would be an easier pathway since you get their green threads and GC for free.
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.
You can try Moonbit. It's extraordinarily well designed and compiles to highly optimized JS, WASM or even native
To add to all these other answers, what would you hope to get out of it without BEAM? Just the syntax?
I like Python, but it's dynamically typed and slow-ish. I like Scala, but I've bumped into the pointy edges of the JVM (e.g.: type erasure) too many times. Rust is great but for most use-cases I am happy compromising with a GC than having to worry about liftimes and ownership and borrows, etc..
Gleam seems like a happy in-between for me, but not knowing much about BEAM and with my negative experiences with the JVM, I had concerns about the overhead.
I don't really have any experience with the JVM other than playing with Clojure. I don't have much to add to the other answers. Two things of note:
- BEAM trades slow CPU in favour of fast IO, so it's not great for number crunching. - While it can be great for CLI utilities, the VM (although very lightweight) does have a noticeable startup time. It's under a second but it's not a good fit for something you would want to run often, ie, if you were building something like git.
As mentioned in other comments, its super power is its concurrency model. I've essentially forgotten what a mutex or semaphore or whatthaveyou is :)
As someone who isn’t a programmer, but enjoys dabbling, and has been curious about functional languages, this was a really helpful (and fun!) read!
Tutorials written by beginners are so valuable, because once you’re more experienced with a given subject, it’s hard to remember what it was like to be a beginner. It can feel vulnerable to write them because you have to expose your ignorance, but it’s such a great thing to do.
It really is a neat language. Sort of like the smaller more elegant language that has been waiting to break out of Haskell, but combined with Erlang. Definitely not the "standard" programming language but very very nice.
The core language is pretty small too. Any moderately experienced programmer can probably burn through the language tour and be ready for a few simple AoC problems in an afternoon or so. This is due to the language designer having a very strict dedication to keeping the language as simple as possible. (Much to the chagrin of my muscle memory, as I keep expecting pattern matching on function arguments to work but it doesn't)
> [...] 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.
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.
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?
I'm currently working on a prototype that does exactly this (in our case, the Gleam is essentially a typed calculation module wrapped in Elixir's great libraries for network and database interactions but its all net-new application instead of an existing Elixir codebase). Its not yet perfect, but I've been eagerly following along with this PR: https://github.com/elixir-lang/elixir/pull/14262#issuecommen...
Seems like (one of) the next Elixir releases will include the support you're looking for in mix.
This is going to be very good for Gleam IMO. Having a super-easy on-ramp for using Gleam in Elixir projects will let people experiment with implementing eg more complex business logic in Gleam, and allow gradual adoption. Naturally, this is not the focus of the Gleam project itself, but for me, using Gleam for the core of a project while having access to the amazing Elixir ecosystem is a dream come true. I've been using mix_gleam but it's not perfect and since I started using Gleam pre 1.0, and it's a low-velocity project, updating became too complicated and I actually ended up moving everything to Elixir recently.
I've kind of gotten a
Scala : Gleam :: JavaScript : Lua
vibe from it.
It also most reminded me of Scala.
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.
I thought so too, although treating everything as data and functions is really nice [1].
Regarding the BEAM and why Gleam has a separate library for actors: [2]
> "One notable difference between Elixir and Gleam is that Elixir gets to just re-use the OTP code as-is (with some Elixir wrappers on top for convenience). Gleam concluded that the OTP is built expecting dynamic types, and that for best results in Gleam they'd need to re-implement the key primitives. That's why the example shown is an "Actor" not a GenServer - it serves the same purpose, and might even fit in a Supervision tree, but isn't actually a GenServer."
There's a brief snippet mentioning this in the Gleam OTP readme as well: [3]
> "Actors do not yet support all OTP system messages, so some of the OTP debugging APIs may not be fully functional."
[1] https://mckayla.blog/posts/all-you-need-is-data-and-function...
[2] https://news.ycombinator.com/item?id=40645489
[3] https://github.com/gleam-lang/otp#limitations-and-known-issu...
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
I was tricked into trying Gleam earlier this summer, and really liked it! I anticipate that I will at least use it for all future web projects (one example: https://github.com/FIGBERT/bdab) due to my serious JavaScript allergy.
I will note something that might be of use for the work in this particular article: https://hexdocs.pm/gleam_stdlib/gleam/dynamic/decode.html
Gleam Decoders are something I haven’t fully wrapped my head around, but are supposedly very powerful and do exactly what this article is focused on (parsing input data into Gleam types) in a more(?) idiomatic way.
There was a great talk on Gleam at the Carolina Code Conference in 2024.
https://youtu.be/vyEWc0-kbkw?si=3o-KasK4H2n-0_KD
I moved to Gleam with all of my projects and am not going back. The language is fantastic but really the most impactful are the coding paradigms that it enables, especially the actor model and especially on the front end (The Elm Architecture)
So do you build stuff using Wisp and Lustre?
I would love to look at some example applications!
Yes.
https://nestful.app used to be TS + Vue but it's almost entirely Gleam now, with Lustre used for state management and only the views being Vue templates. Those will also be migrated away for a fully Lustre solution.
Blog posts:
https://blog.nestful.app/s/the-tech-behind-nestful
This was a great read! One thing that def makes Gleams error handling _look_ nicer, is utilizing `result.try` with the `use` keyword.
thanks for posting this --- very interesting to read the "first impressions of FP" side of it
to be honest, I felt like shouting "please try raku" (https://raku.org) after about 4 paragraphs!
why? well raku Grammars are built in parsers...
I tried with Gleam, I really wanted to like it. I really like Louis Pilfold and I like his goals for the language. But something about it just didn't click for me. It's a good language, but at the end of the day I just didn't enjoy writing it.
It might be something the author talked about, but I think the language might be too small. It's one of the things I dislike about Rust too. I prefer a more batteries included approach because I can't stand having to pull in a bunch of small dependencies.
Rust is a HUGE language with a small stdlib. Gleam is a small language with a small stdlib.
Yes, thank you for pointing that out...
My point was about the need to rely on external libraries. I'm not a fan of that approach. I don't care for it in Rust or JavaScript, and I get a similar vibe from Gleam.
Agree. My dream:
Go stdlib and tooling
+
A good programming language
Odin?
Not the GP but while Odin has a syntax similar to Go, it has manual memory management instead of a GC, that's a pretty big difference.
Obviously, but it's an extremely well design language with a batteries included approach to the standard library.
I’d prefer a GC language with exhaustive matching on discriminated union types. Maybe “go + typescript type system + higher kinded types”. Swift is in the ballpark and would be a lot more appealing with the go tooling.
But fill in the blank with your preference :)
Ocaml? It garbage collected, primarily functional but with options for an imperative style when necessary. Of course its std isn't very good. I think Jane Street has done a lot improve things, but the whole ecosystem is still kind of a mess.
I just can’t with the OCaml header files. Like what the hell all the types are inferred but you’re gonna make me write a header file for each module???
Im on the same boat and this is coming from someone who loves the beam thanks to elixir, I think the marketing of the lang threw me of a bit. But I might give it a try this week, as im feeling a bit burnt out with elixir
earlier this week I was thinking why aren't there more languages around the actor model and completely forgot gleam exists
Gleam is cool. I absolutely love that it's statically typed (dynamic typing is one of the things that pushes me away from Elixir), and the core of the language is very well designed. I just hate how small it is. I shouldn't need to bring in an external dependency for friggin file i/o.
And I know the common argument is that's it due to the fact you can target either the BEAM or a web browser, but those arguments don't fly. The default target is the BEAM, the standard library can support that and use external packages for the browser.
[dead]
[dead]
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.
>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.
https://en.wikipedia.org/wiki/Malbolge
I suggest https://en.wikipedia.org/wiki/Whitespace_%28programming_lang..., which consists purely of white space, which isn't tokenized by LLMs. The code is very easy on the eye.
You better start writing your own compilers then
This, however, has always been true and is not just an issue of AI.
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.
Not even 9 years, I'm thinking 30-40 years.
Never underestimate the ability of the software industry to shit in its own mouth.
See you in 9 months then to check back.
Anthropic's CEO said 6 months, 6 months ago. https://futurism.com/six-months-anthropic-coding
> 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.
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.
The entire Gleam language tour (https://tour.gleam.run/everything/) is comprehensive. It contains examples of every language feature and prints to less than 70 pages - easily fits into the context window of any recent LLM.
You should learn Gleam then.