The Star Language that will outshine Rust? Gleam 

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

Time to add 10 years of Gleam to my resume.

I like semicolons because it defines where stuff ends.

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

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.

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

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.

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.

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.

Gleam is like a functional version of Go.

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.

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

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.

Gleam used to have a record type but moved to the single custom type to make the language surface area. I really liked the record types but I can also aprecate the Golang style simplicity overall.

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?

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

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.

Look into “use” - you can use it to emulate ? In Rust, early returns, defer in Go and Zig, and lots of other cool things.

I hate type inferrence in parameter lists. I want this to be explicit so I know what it's designed to take and do.

I love, love, love labeled arguments. It makes for code that reads almost like natural language. ``` pub fn replace(inside string, each pattern, with replacement) { go(string, pattern, replacement) } replace(each: ",", with: " ", inside: "A,B,C") ```

One difference between Gleam/Rust is the use of Option - Rust uses it for any nilable value - Gleam wants you to use Option for things like optional function params, and use Result for function returns. Eg: `list.find` will return `Result(a, Nil)`

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.

I just dabbled in Gleam, and it's like a mini vacation from rust or js. From top down, you can teach this to kids, without diving deep. Step by step, learn more, very Pascal-ish in nature, except functional piping. I was very happy to scope it out. It deserves good book on deep concepts. I had to dig into the library and examples. It does look made for wasm, so I need to try that.

It might not be as straight forward but in Rust you can pattern match a string like so: fn process_message(input: &str) -> String { match input.split_whitespace().collect::().as_slice() { ["Assistant:", other @ ..] => other.join(" ").to_string(), _ => "other cases".to_string() } }

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.

Gleam is awesome and you should definitely do a video about Lustre if you haven't already. Also the creator of Lustre just got interviewed on Developer Voices

5:40 the Rust LSP (rust analyzer) has a shortcut to explicitly show inferred types. Maybe the Gleam LSP will have that too?

The name parameter stuff is actually more than something an IDE could do. The goal is that if you need to modify/add/swap arguments of a function, it is simpler to maintain in the rest of the codebase. When you have two parameters, its easy, but when you have 8 parameters to a function, 4 of them have the same type and you need to remove the 5th one, the process is error prone and/or confusing. Sometimes, being explicit about parameters can be a good thing. It also allows people who like different things to live in the same codebase. Think of the myFunction(src, dest) vs myFunction(dest, src), both of these ways are valid and maybe you prefer writing one way and your coworker another, with name arguments, each one can do his thing in a non ambiguous way

I don't think Gleam competes with Rust, more with Go. But I don't see why not just use Go instead. Perhaps if you like to leverage the nice actor tools of Erlang?

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.

6:45 and for functions with a lot of params with default values it lets you specify the ones further back in the order without enumerating each param that comes before

yes to labelled arguments. `dismiss(view, false)` bad. `dismiss(view, animated = false)` good. wherever you’re viewing that code.

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"

One reason I like semicolons is because they can be autoformatted. I can write something like console.log(a);console.log(b) and the formatter will automatically move them to newlines. Something like Gleam will call it a syntax error.

You know I woke up this morning thinking, "Man... if only we had just one more programming language"

Love the internal names for the parameters. That's a great idea.

You could also destructure strings in Erlang / Elixir. Even bit streams.

Thanks so much for this video! I prefer semi-colons myself, even after dealing with languages that didn't require it earlier in my programming career (VBA). There's something so comfortable about explicitly defining where stuff ends.

If you want something like gleam without GC, you can have a look at Roc, though it's at rather early stage and the syntax is more Haskell like.

They made SCALA once again

I wish rust had the pipe operator, gleam is such a fun and interesting language despite a handful of things I have mixed feelings about.

Please cover Lustre, and real-world use-cases for Erlang/Elixir interop!

"Can't do that in Rust." Rust has macros, so if it's really desirable, you will be able to do so with a library. It won't need to be a language feature.

Really nice comparison, thanks for making it! I don't see the need to learn Gleam any time soon, Rust has everything I could ask for :)

It's basically F# but with better tooling (at the time of writing).

really nice video as always mate!

I think that an ideal webapp would be one built with a Rust backend and a Gleam frontend. The Rust backend allows you to do crazy stuff with it's complex type system and is also more performant than Gleam by design. The Gleam frontend is ideal because since it compiles to JS, you don't need to interface with WASM to interact with the DOM, and that brings a lot of benefits. Another benefit of Gleam on the frontend is simply being able to create frontends in a language that isn't JS 😅

I use Elixir a lot, more for the BEAM than the language. BEAM is incredible. What's interesting is that you can interop rust code with the BEAM and if you're using gleam that might make things quite interesting from a dev point of view since the syntax is similar (or more confusing) not sure.

5:02 your objection here is solved by the pipe operator |>. Also it's worth pointing out that ocaml handles generic types the same way. And that Gleam runs on the BEAM. So garbage collection isn't as obstructive. I would have though that Rust was for low level stuff, competing with C/C++, while Gleam was for stuff like highly concurrent services, competing with high level languages.

5:28 I've seen another language with static inferred typing for function signatures: Scopes

Gleam should add first-class support for integrating Rust modules into the codebase. With that, it'll cover a larger range of use cases. GC works differently in BEAM, each process has its own garbage collector, so there's no global GC pause. Since Gleam runs on BEAM, you also get all the goodness that comes with it, such as its amazing concurrency and fault tolerance model, message passing between isolated processes, and being distributed right out of the box. You can open a shell to your running program. It was basically designed to never stop, even for updates, it supports hot code reloading.

I don't know if I like Gleam... Doesn't matter anyway, because I am making my own compiled language already. Remember kids, lexers are a pain in the ass to make well.

Semicolons (like C or Rust) or periods (like Erlang or Prolog) are a good thing. Determining when a statement ends must happen, and letting a compiler or interpreter do it insted of having explicit control of it feels wrong, and I have seen it lead to terrible surprises.

I posted smth dumb about there being inferred types in nim and go but realized you meant inferred types in function params. Yeah I've not seen many langs with such features. Personally idm it, but when I did Haskell for my fp class I put the types for the function anyway to aid readability.

I'd love to see a video on Lustre

it has GC and no loops, i feel clickbaited.

i hope we start see the ++ and -- operator to get droped, it is a thing we added for char[] as we don't have strings in C back in the day, but now they are used by people who know understand what ++i and i++ do, and it add bugs to code

Very nice video as usual. The pattern-matching stuff that is dannnng good comes from Prolog. As Gleam sits on top of the BEAM that is written in Erlang, Erlang is heavily inspired by Prolog. It's a bit sad to not talk a bit about Erlang in the intro. WhatsApp was written in Erlang, serving 3 billion people with only 50 engineers. That's the power of the BEAM. The fact that you do not "attach" methods to structs is that basically modules are buckets for functions. Usually aggregated by a context, like a math module for all the functions related to math. We apply a function on data, so data is passed as an argument to functions. Gleam contrary to Haskell is not a pure FP language. It's full of side effects, that's because you have to embrace it. That's what Erlang did. However, we still try to have a "same input, same output" behavior. Anyway, that's nice to have a video from you speaking a bit about something running on the BEAM. Thanks!

The lack of types in function signatures is fine in private functions but inexcusable in public functions. IMHO

beam ecosystem kinda dope. getting scalability for chat apps, with low overheads, seems like a good benefit. like whatsapp running millions of chats on 1 server tower. that video is kinda wild. rust has awesome momentum thanks to the proselytizing cult. never underestimate proselytizing cults.

Yeah I used to dislike semicolons just like you. But then I’ve had my fair share of confusing errors where the compiler couldn’t infer where a line ends, and now I prefer mandatory semicolons. They give more freedom and precision at a tiny price.

can you take a look at Roc? it looks very innovative but it is quite young

I believe the gleam compiler is written in Rust .. and gleam transpiles to erlang. A language which powers most of the telecom domains and a language that boasted 99.9999 uptime

I don't understand the comparison to Rust. Gleam seems to play on a different field, especially being a GC language. And there are sooo many proven languages there, that I don't know why we should do it again, when ergonomic non-gc memory safety is on the horizon (I'm saying that because Rust leaves some things to be desired, and might or might not solve them before another language solves them).

One thing I wanna bring up based on your video. You mentioned languages not necessarily having certain things matter (like named arguments) because of IDEs. The problem is a lot of other tooling like code review tools mostly don't have the same support for displaying that extra information so making it available directly in the code has value. As for type annotations being required for function signatures, for me it depends on how obvious it is, along with how cumbersome. For example if a function should work on all numeric types, having to do complex type annotation to indicate it manually versus letting the compiler do it for me... unless it is causing other issues I dunno if I wanna deal with it lol.

I think comparing Gleam to Rust, is like comparing apples to oranges.

I think not touching on the BEAM and the Erlang/OTP runtime and ecosystem that come with it really misses the point of the language.

6:00 it’s nice not having to be explicit about types…. It’s like programming to an interface, where we don’t care much about the implementation, just that we get the transformation or effect we want. We get the same effect with implicit typing, except we don’t care much about other aspects of the code too. It’s actually easier to refactor code with implicit types because we are already less constrained, so there is less to get in our way.

Oh what a great features!. They exists in Scala since... 2012 (?) :D

gleams logo made me think it was another js framework

Actually the aliasing in function params is pretty interesting. I often had a situation on a function where 'a, b' would be enough, but I wanted to express it a bit more detailed. The only downside is that (in some cases) it bloats the function (IMO). So I think this is a huge win

Ok, so yet another comparison of a motorcycle versus a sun cream. One is more red but the other one comes with a selection of scents. Both can be applied to one's balls. I can't decide which one i like more....

It's probably unfit for CLI because Beam takes like half a second to launch. CLI might be the only use case where the most important factor is first-pass performance, and Beam languages are even worse at this than Java.

the inferred param types and inferred generics sounds like a pain to review. In rust a majority of the time you can tell what a function does just by looking at its signature.

Remember me Elixir

the last "opinion" at the end doesn't make sense and is a misunderstanding of ownership semantics, they are not incompatible with a garbage collector. It's not either or. In rust you're forced to "naively" reference count, or resort to more esoteric strategies to manage heap allocations with non-obvious lifetimes (which is the point of a garbage collector), if you could just stack allocate everything and track DAG lifetimes with ownership life would be simpler, but this doesn't apply to all algorithms or data structures. Hence that linkedlist in gleam is "simple" to write, but in rust requires you to read a book.

i'm unsure why is gleam always compared to rust. gleam's a functional garbage collected language at its core, what common does it have with rust? wouldn't it better to compare it with elixir/ocaml/clojure/other functional languages?

if you lived in a world with mostly semi colon your gonna prefer semi colons.. to me it cause more problems as much as loops. thats why i like sql over mongodb style of querying.

Gleam is a subset of Erlang that is mappable to JS. This is a selling point... for some. On garbage collection being a problem, I think you're mixing the terms. Remember that variables are immutable? The BEAM garbage collection is closer to Rust's borrow checker then garbage collectors in the likes of Java, C# and Go. There is no performance hit and hiccups like in those. In fact under heavy load the BEAM engine is better then Rust at concurrency. Erlang is the OG concurrency language after all.

also theres a really big difference between STATIC typing and STRONG typing. And its the main selling point of Rust for me!

Gleam; the language for the lazy coder coming from Javascript that cannot be bothered learning Rust. There - the video in one line.

lol I am one of those guys that perfers semicolons

Yes, I actually prefer semicolons. And my first language didn't have any, so it's not a bias from that. It can avoid some issues and imho is better than escaping newlines like in Python. Regarding mutability & efficiency, there are languages which do not support mutability in the code but will make values mutable during compilation for optimizations, the best of both worlds basically. Not sure if Gleam can do that, though.

Unfortunately, I don't like gleam's type system at all. I often use self-implemented structs and enums in my programmes and am always very disappointed when I don't find them in a programming language.

7:00 I would go one step further. I think there should only be structs in a language. And some are callable. So you can create an argument list and store it somewhere before actually calling it.

Not a chance..it is not in the same category as rust..this is for web dev..

Amazing video, nice comparison! Personally I have no strong opinions on types for function signature. I have used R and Python that are dynamicly typed, Nim that is strongly typed ans Julia that is "optionaly" typed. But the generic type idea looks a lot like Julia generic type. Except in Julia, type declaration a used for multiple dispatch (nice feature for code reusability). Anyway gleam looks cool and is worth tesing. I will still use Nim for now. Thank you for the video!

Eventually everyone will discover Lisp and realize they got it right in the 50s

I love rust, but gleam looks like a better choice for web development.

No loops aren't the biggest turnoff

Everyone is talking about Gleam but no one gives my boy Unison any love...

how does it deal with stack management if there are no loops and you can only do recursion?

WHAT ARE YOU TALKING ABOUT????? "C++ will outshine Erlang". FUCK NO, IT"S TWO DIFFERENT CATEGORIES!

Like to also mention that Gleam is written in Rust. I like it. I think it will potentially eat into erlang and elixer. I'm waiting for the day people stop writing f*%king Java and JS. Both those languages need to die.

isnt a VM Language more of a competitor to Java/C# . Why are we comparing it to a Memory Controlling, compiled Language? By the By i put Semicolons in TS/JS. I like semicolons :D

either it's the camera or your eyes are really close together

I prefer semicolons because they are more explicit - Its easier to tell developer intention when things are explicit. In languages where they are optional, I've found it can be confusing to determine where a multiline statement (think method chaining) is supposed to end sometimes. My autistic brain finds that having an explicit character act as an expression-ending operator avoids any ambiguity as to when a statement ends, reducing cognitive load when reading code.

Haha imagine showing that little girls logo to a client. This is the language I’m using 😂

Gleam is written in Rust :D

My opinion there are too many new languages coming out all at once. Pick one and stick with it, otherwise you'll never be able to create the app you want, having to restart every time there's a new language that comes out. We don't need perfect, we need good enough, and good enough we have.