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/)In Gleam pattern matching and the "splitter" package is the go-to for text parsing.
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).
For example Asn1Type can be of form Builtin, Referenced, or Constrained. So a sum type.
parseType = Builtin <$> parseBuiltin <|> (Referenced <$> parseReferenced) <|> (Constrained <$> parseConstrained)
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(";"),The same thing in a FP-style language would be something like
eq "SELECT" *>
Select
<*> (sepBy columnExpr (eq ",")) <* (eq "FROM")
<*> parseTable
<*> optional (eq "WHERE") <* eq ";"
type Select = { cols: [ColumnExpr], table: Table, where: Optional Where}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 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.
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.
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.
- 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.
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 ;)
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.
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.
My only reason for not using it is nobody pays me to use it, they pay me to write basic CRUD apps in .NET
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've not written any OCaml, but I've heard tell of its reputation of being hard to pick up.
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 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.)
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.
- 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 :)
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)
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.
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.
Seems like (one of) the next Elixir releases will include the support you're looking for in mix.
Scala : Gleam :: JavaScript : Lua
vibe from it.
It also seems weird to make a language for BEAM that depends on a separate library for actors and concurrency.
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 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.
I would love to look at some example applications!
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: