The Star Language that will outshine Rust? Gleam

A look at the Gleam programming language, through the lens of a Rust developer.

[Dr-Zed]

Bro you can't just disrespect the pipe operator |> like this. It's literally the best feature of the language.

[ximon-x]

Time to add 10 years of Gleam to my resume.

[oglothenerd]

I like semicolons because it defines where stuff ends.

[naomieowdev]

4:50 ish, when using `list.map(thing, func)`, this can also be written as `thing |> list.map(func)` - this is called the pipe operator and it passes the thing before the pipe into the first argument of the method following it. You can also specify what argument it will get passed to with `func |> list.map(thing, _)` but of course it makes less sense here with list.map

[ivantodorov]

Currently having a blast writing Gleam. Very easy to learn language. And yeah - more gleam videos please.

Btw great video.

[Khari]

Elixir has an FFI package called Rustler that allows you to use Rust directly inside of Elixir. Gleam should have the same capability soon too so that you can use Rust for anything that is performance critical.

[saphirakai]

labels being separate than internal names is actually a huge win for readability in my opinion! there's many examples in the stdlib alone that showcase how it can be useful to refer to an argument differently externally vs internally.

generally speaking, it allows you to pick an internal name that represents *how* your function is using it to perform its job (predicate, condition, filter, i've also seen `needle` and `haystack` for searching), but externally it might read nicer to say `filter(x, by: y)` (filtering x by y) rather than `filter(x, predicate: y)` (filtering x with predicate y).

for a simple function like `filter` that's not too bad, but picture a more complex function that takes more arguments and uses them in a more complex way; it might require more knowledge of how the function works internally to make sense, and be much less smooth to read in a natural way.

[LukeFrisken]

I think it's worth comparing Gleam to Async Rust specifically in terms of reliability, performance (throughput and latency) and developer experience. Yes you pay a penalty for garbage collections but the BEAM brings a lot of reliability guarantees in terms of fair task scheduling to the table that you don't get with Rust, only Golang comes close. Function coloring is another big issue worth bringing into the comparison. I've been comparing Gleam, Rust, Go and Java (with virtual threads) for a new project recently. Personally I enjoyed Gleam the most, but the ecosystem isn't mature yet for what I need, so decided to use Go. Async Rust has a bunch of footguns, and it doesn't mix well with lifetimes when doing anything beyond the basics, it's easy to end up with insane compile errors, such as futures which are not Send due to some tiny thing deep down in your call stack and the errors mesages don't tell you where it is.

[Varpie]

Great video! A few things to add:
- Types are optional in function signatures, but the compiler still ensures type safety. If you want your code to specify every type explicitly, you can definitely do that, and it is usually encouraged because the compiler will provide very helpful and clear error messages (one more thing it takes from Cargo). This is very similar to Haskell, and just like Haskell it is very rare to see libraries without explicit types, since they are also a good documentation. I think the advantage of having implicit types before shipping the product is that it makes prototyping very easy, since you don't have to update all the references when you want to change a type. It would be nice to have an option to consider public functions without explicit types as warnings, though.
- The pipe operator |> wasn't covered, but it allows to chain operations like you would be able to do in Rust or something like Linq in C#. It take the left hand as the first parameter of the right hand, which I thing makes up very well for the fact that the language doesn't have methods. In your example, list.map is using the map function from the list module from the standard library, but you could have used a qualified import so you don't have to specify that map is from the list module, and it would look like nums |> map(fn(element) { element <> "!" })
- The use keyword, that is quite unique and powerful, wasn't covered either. It is syntactic sugar that allows to unwrap callback functions, and can be used to implement things like defer and other advanced features.

Overall, I think Gleam is a very interesting language, and definitely not vaporware: it has reached v1 so we will likely not see breaking changes soon, and with its access to the Erlang and JS ecosystems, it can be used for a lot of things. It is a high level language though, so it won't replace Rust's capabilities as a system language.

[alexgregory]

I'm just guessing here, but isn't immutability usually an abstraction of the language syntax. It is great for us to reason about our code + testability, but under the hood, it will likely optimise these to avoid unnecessary operations when compiled/runtime?

[Mcsqw]

The thing that really impressed me with Gleam is that the most succinct, "Gleamy" solution seems to also be the most readable - I am still mildly traumatised by my first year undergraduate C programming teacher who used to write every single program on a single line, brackets and all - so although Gleam currently isn't quite suitable for my current use cases, I'm definitely keeping an eye on it.

[trendtube]

Gleam is like a functional version of Go.

[kurokami]

R user here, fun seeing the pipe operator in another language. Makes functional programming so much more intuitive for me to be honestly

[metropolis]

5:58 if the types can be infered by the compiler, then they can be infered by a linter and just added to your code automatically. That should be the play here.

[soanvig]

The thing with immutability is more complex. Just because the compiler doesn't allow mutability doesn't mean the compiled code doesn't mutate anything to improve performance. In fact, FP devs came up with multiple patterns solving immutability problem: most notably persistent data structures.

[costinel]

I don't think Gleam's aiming to replace Rust, but more "mainstream server languages" like go, python, java, js, etc

[CrapE_DM]

I've been hoping to one day find a language that has internal names for parameters. It's useful for those times where the grammar for the caller makes you use a simple word like "to" as a parameter name, but you want something more descriptive within the function. For example, a range function is called with "from" and "to", but it's much easier to understand the internal code if they're labelled "start' and "end"

[jakubbartczuk]

Interesting take to compare Gleam to Rust.
It helps to know that Gleam runs on BEAM, which is like JVM for Erlang - lots of the weird parts you mentioned are obvious for someone who knows Erlang/Elixir. Also basing a language on BEAM means that it will have way easier adoption, like Clojure or Scala which didn't have to work from scratch. Last but not least BEAM has actor-based concurrency model which is OP in many practical cases.

[Heater-v..]

Hey, you only talked about syntax. Surely the whole point of Gleam is that. it runs on the Erlang Abstract Machine and hence makes distributing ones application over thousands of real computers in a fault tolerant way very much easier than in a language like Rust. A killer feature if you are wanting to crate a huge distributed system.

[sinan-morcel]

7:51 this feature is supposed to be how you define Algebraic Data Types. In this case, Thing is a type that has 3 constructors. The power of Algebraic Data Types is when they are recursive, unlocking a very elegant style of functional programming.