Some highlights from this release are listed here[1].
The best part of Gleam in my opinion is the language's design. It's just so elegant to read and write. Take this example code snippet from the release notes:
It's a trivial code snippet, but I'm finding this kind of "first class" pattern matching produces very readable, elegant-looking, well organized code.
There was a discussion the other day about the pipe operator being added to PHP 8.x. Gleam was my first language which included a pipe operator. Now, having used it a bit, I feel every language should have something like it.
Interesting. I was just about to write the opposite. I tried Gleam to solve last year's Advent of Code, and it felt like a weird mix between Rust and Elixir. You can't write code as elegantly as you'd do in Elixir, which was somewhat disappointing. I switched back to Elixir after a couple of days. I think the biggest advantage of Gleam is static type system.
Depending when this was, it was likely pre-1.x days? Things moved very quickly there for a while - it's worth checking back in again.
Gleam seems to have a lot of obvious influences from Rust, and the creator is a rust dev.
While the Gleam ecosystem is vastly less mature than Elixir's or Rust's (because it's literally younger), the language itself, I've found, is vastly more pleasant to read/write. YMMV of course.
> Gleam seems to have a lot of obvious influences from Rust, and the creator is a rust dev.
Hi! That's me!
Gleam the language doesn't have any Rust influence really. It's a happy accident that some of the syntax ended up looking the same, but that's likely due to both being inspired by similar languages such as OCaml and the C family. Most the syntax and the semantics predate Gleam's compiler being rewritten in Rust.
The build tool is a rip-off of Cargo for sure though.
more like both gleam and rust have a strong ML influence (gleam might actually consider itself an ML? not sure about that, but it's definitely a descendant)
I prefer Elixir's syntax over Gleam's, but my main issue with Gleam is architectural. Specifically, Gleam had to bastardize BEAM and OTP to implement static typing. To me, static typing vs. dynamic typing is like having a shelf with a doily vs. one without a doily (the shelf works fine either way), so messing up a solid Actor Model implementation, for instance, for the sake of static typing seems like the wrong thing to do.
It has been a while since I looked at Gleam. Some things may have changed. However, the last time I used Gleam, I was forced to switch back to Elixir because Gleam:
• Lacks support for named processes.
• Has limited actor abstractions.
• Doesn't support OTP system messages.
• Has implemented supervisors in a way that can lead to improper shutdowns, data loss, and deviations from the expected BEAM behavior.
• Doesn't support pattern matching directly in function definitions. Instead, it requires you to use case statements.
• Doesn't support global mutable variables because it has no way to track variable types and state changes when BEAM modifies these variables, which is one of the hallmark features of BEAM.
• Doesn't support hot code reloading.
All of these features, which are readily available in Erlang and Elixir, are far more important to me than static typing. I've used statically typed languages like C, C++, C#, and Java, and dynamically typed languages like Python, Ruby, and Elixir throughout my 30+ years career. I've never once lamented not having static types, nor have I ever jumped for joy when I do. For me, static vs. dynamic typing is largely irrelevant and doesn't affect my work one way or the other.
I'm curious to know what the parent meant, as well. My understanding, which is incomplete admittedly, is that Gleam's type system lives in Gleam and isn't carried over into the produced Erlang/BEAM code, since BEAM has no concept of types, etc.
Gleam also has an OTP implementation[1] available, which includes Actors and the like. My understanding is that every BEAM language must implement OTP themselves, so there's nothing unusual here.
I'm so envious of this. In TypeScript I use ts-pattern and Effect Schema, and while they make this logic way nicer, it's insanely verbose and doesn't offer any of the niceties of being first class.
I have not used it at all, but Gleam does have a javascript target in it's compiler/build-tool. So in theory, you can write Gleam (strongly typed, etc) and produce js.
I've exclusively used the BEAM/Erlang target so far - but the js community within Gleam seems quite interesting.
I've been considering trying this, but my team already struggles to properly adopt TypeScript so I'm fairly sure introducing Gleam would cause a few people to throw me out a window.
Gleam is so much smaller and easier than typescript and the type system works harder for what it is. TS gets you because it is similar to javascript in some ways that make it easier to start the transition. But a complete js -> ts transition is about as big a deal as it would be from js to any other language, except you can use the same external libraries.
No, it doesn't have strong if err != nil { return err; } vibes.
Pattern matching on Ok/Error is one of the best known error handling, while go error handling is one of the worst. They are about as far from each other as possible.
That's what Gleam's use expressions[1] are for (the last example is exactly this case). Most languages with the same heritage as Gleam have grown a similar syntactical feature, such as OCaml's binding operators or F#'s computation expressions. Although I appreciate how simple Gleam's is while having similar power.
This is a trivial snippet. Often you will transform/map your error into another type (or deal with it in some way), so it's not so much `if err != nil { return err; }` vibes like you're thinking here.
The beauty here is being compelled to handle both the happy and sad paths. You cannot just pretend the sad path doesn't exist.
It's not just about wrapping. use-expressions, result.try and result.map eliminate the boilerplate of checking for errors entirely: https://erikarow.land/notes/using-use-gleam
I come from js/ts as well and I find snake case much more readable than camel after using it in other languages for a bit. There are even js/ts projects that use snake case despite the camel case convention, for readability
I come from a background where everything is camelCase. Naturally I wrote my JSON this way as well, among other things.
Switching to snake_case was challenging at first - I kept writing things in camelCase. Now, I've become pretty fond of snake_case and have a tough time going back into environments that require camelCase - funny thing, that is.
Thankfully Gleam's build tool/language server has a fairly strongly opinionated formatter built in, so it will let you know pretty quickly and help you fix it.
One thing I disliked is black, the Python formatter, with its utterly naive rules, that treat all code the same. It required me to workaround in many places, like always using a trailing comma for any list or tuple, to keep the items on separate lines, instead of black fumbling around and putting them on the same line. It was utterly annoying. This made me very vary of "opinionated" (read: inflexible unconfigurable pieces of software) formatters. Hopefully Gleam's formatter isn't as stupid as black is.
The best part of Gleam in my opinion is the language's design. It's just so elegant to read and write. Take this example code snippet from the release notes:
It's a trivial code snippet, but I'm finding this kind of "first class" pattern matching produces very readable, elegant-looking, well organized code.There was a discussion the other day about the pipe operator being added to PHP 8.x. Gleam was my first language which included a pipe operator. Now, having used it a bit, I feel every language should have something like it.
The pipe skips so much boilerplate and clearly communicates intent. Absolutely love it.[1] https://gleam.run/news/no-more-dependency-management-headach...