wow, I didn't realize until this comment that I hadn't explicitly mentioned it anywhere in the video! I really like it too, thanks for pointing it out. I may mention it in a pinned comment.
Also at 4:48 the pipe operator can help you out: you can write let excited = nums |> list.map(fn(element) {element "!"}) But you still have to specify the function explicitly, there is no particular function attached to the type (like methods are) that's why `list.` is mostly required (importing map directly would not be very readable, how would you know it's map from list module and not something else?)
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.
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.
@@codetothemoon yeah I’m currently using elixir and rust as my primary stack. They work amazingly together. Gleam is cool but it’s young so I can’t just move everything over from Elixir yet. Don’t feel like writing bridges to use all my elixir packages with gleam lol
@@Khari99 I really want to love Elixir, but its dynamic typing makes it impossible. It's so hard to learn a language when you need to look up documentation online for everything. With Rust, I can hit SPACE + K to bring up a function's or type's documentation in my code editor and grasp what it does almost immediately. That's why I'm excited for Gleam. If it gets its own Phoenix, I'll use it for all my web back ends.
For a package maybe, but the devs have stated that they wont be adding native targets to the @external API, but you can still get it by binding an erlang FFI that runs a native-implemented function (in a language like rust) for almost no cost, just gotta write a lil glue.
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
@@codetothemoon yeah, but i would call Gleams piping as a more general approach of the same mechanism. Rust uses the first parameter of a function to declare on which instances a function can be called on (if i remember correctly, i have little rust experience). This is something that i personally really like in imperative languages. The default piping behaviour in Gleam is really similar but with different syntax and by using a different mechanism: partial function application. Gleams partial application also allows explicitly choosing the function argument to pipe into. So any argument could act as "the instance". example: fn repeat_text(text: String, amount: Int) -> String { ... } default piping behaviour: "foo" |> repeat_text(4) explicit partial application: 4 |> repeat_text("foo", _)
@@codetothemoon back to list.map(): specifying which map() function to use (map() of module list) is a huge improvement in functional languages because otherwise you would have to look up which map() is being used. It's not done by default in Haskell and it really is such a huge pain, especially in tutorials and documentation. calling functions on instances (methods) solve the same problem. But what if an instance has multiple map() functions? How do you specify which map() to use? dot-syntax is really really readable and i also really like rusts approach but i think gleams approach is the most general with (i think) no special cases.
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.
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.
it uses the beam under the hood so its very good for backends that have high availability and the app can load new code while its running very cool feature ngl
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.
@@MichaelFromOz I've never heard about a feature like that - but thinking about it, the params are on a different abstraction level inside or outside the function
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.
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.
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.
@@codetothemoon the author, Louis, describes it as "functional Go". but its deff an over-simplification. he just means that its a small, simple, opinionated, easy to learn functional language
The good thing is that you can explicitly declare your parameter types, there are plenty of examples in this video. And so far, I haven't found a library that isn't well enough documented on the types to use for everything.
@@Varpie Sure, but behavior changes depending on the implementation. For example, if it's gonna use iterators versus arrays, it would be nice to be clear and constrain that type to enforce arrays, if you want best performance. Otherwise, the compiler must infer type constraints from the implementation, and that might be looser than they expect, limiting API changes.
@@Christobanistan Gleam is a statically typed language that doesn't have polymorphism or interfaces, so the only way you can have a function that can be used for either iterators or arrays is with generics. In that case, the decision would be the caller's responsibility, which makes sense to me. Unless I'm missing something, in which case I'd like to have an example, because type inference still requires to have a type defined somewhere and the compiler will give a nice error if it doesn't fit.
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") ```
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"
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 think in some cases you are correct. for example in the "field update" scenario i covered, its certainly possible that under the hood the compiler recognizes that because the original value isn't used again, it can just be updated. Not sure if Gleam specifically does this, but I don't think there are any technical obstacles precluding it. BUT I think there are more complex scenarios where the compiler simply won't be able to "optimize via mutability" under the hood. I could be wrong about this.
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.
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.
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
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.
@@verified_tinker1818 good point, but what about just calling Elixir from Gleam? I mean it's no silver bullet, but is it useable? Or is it unwieldy (I imagine it might be similar to working with untyped actors in Scala, I did this like 8 yrs ago and it was horrible)
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 agree. the syntax is so similar to Rust that it's hard to avoid the comparison. Also, the fact that it can be used in lieu of JS for full stack web development also makes the Rust comparison relevant.
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)`
@@sunofabeach9424 That is incorrect -- given the function `find` for an iterable, an idiomatic Rust function would return `Option`, while an idiomatic Gleam function would return `Result(a, Nil)`. Gleam uses `Option` to denote _optional inputs_, while Rust uses `Option` to denote any nullable value.
@@sunofabeach9424 basically Result is an Option but with a generic type instead of the "None". So you can have Result where E is the error type, maybe just a String, maybe your custom Error type
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.
@@samuraijosh1595 The following compiles in Gleam: import gleam/io pub type Nat { S (t: Nat) O } pub fn main(){ io.debug(count(S(S(S(O))))) } pub fn count(n: Nat) { case n { S (t) -> 1 + count ( t) O -> 0 } }
I don't think Gleam will ever replace Rust. They are designed for completely different use cases. Gleam is designed around concurrency and simplicity. Rust is designed to be as fast and safe as possible. Gleam is so simple, it does not have anything like traits or interfaces. You would use functions or a type containing functions to pass around.
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.
@@codetothemoon High availability was the fundamental design goal of the vm. You get it almost for free by just using its language. There's a lot to unpack there but that's what I value most. This can be achieved elsewhere but it's way more complex and difficult to get right. I'd love to see a video where you explore some of that through gleam or elixir.
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.
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.
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?
I agree it seems like it caters more to the things you'd use Go for as opposed to Rust. But the syntax borrows (no pun intended) so much from Rust that it's hard to avoid the comparison. I think the main reason why you'd choose it over Go is if you prefer the pure functional approach and the "next level" type inference
@@perc-ai The BEAM is a double edges sword. For server, sure, it's nice. But if you want to write something to ship to the users, it's a big deal having them install a VM just to run your app.
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
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!
yeah i agree in a code review context where you might not necessarily have the inline help of an ide, i agree this is preferable! makes me wonder if we should strive for code review tools to have the same goodies that ides do
@@codetothemoon while better tooling is always a win, ordinary struct literals already require field names. so why shouldn’t functions get to have the *option* of requiring argument names? what even is a struct literal if not a funky looking function from which all instances of it originate anyway?
I've had unpleasant experiences with things like adding an optional boolean parameter to a function, while someone else, on a different branch, added a different optional boolean parameter to the same function and then after merging, some calls to the function accidentally specified a value for the wrong parameter. Labelled arguments could have prevented that.
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.
I didn't realize WhatsApp is using the beam ecosystem! thanks for pointing this out. Why do you think Rust has garnered the culture you mention while other ecosystems (like beam) have not?
@@codetothemoon Yeah Whatsapp was built on erlang, kinda wild. I think FB switched it to C++, probably to lower overheads, but maybe Rust was a better option for safety. I think that it's many things: 1. rust's promise is very cool. Memory safety + low level control. You might be a bit slower than C, but you can always go Unsafe Rust and get 99% there. 2. You get more modern tooling, specially when tooling around the low level langs isn't stellar. This lowers the bar to entry for a lot of people. There's probably a package for that. No make files. Etc. 4. You get memory safety, when memory safety is a mess. 5. The compiler tasing you again and again is also an incredible help. Verbose compilers help move you in the right direction. 6. The similarity in syntax to ALGOL style languages like C++ and Javascript. I tend to prefer simpler syntax, like Go, or C (though I wouldn't write C for something that can get hacked), but I can't deny that the momentum in Rust is just mindblowing. People are just productive in these languages. If there was a Go syntax style lang with a Rust style compiler I'd be very happy.
I have written Scala in a professional setting and I love a lot of things about it, but there some that I don’t. One of them being the JVM. But absolutely a great language for many domains!
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 can definitely see this being a viable stack, for all the reasons you mention! I personally have a preference for language isomorphism across the entire stack, partially because it opens up the door to write frontend and backend logic in the same project, which I value highly. Would personally be happy with all Gleam or all Rust. But that's just me.
interesting, it seems like there are quite a few folks who love this feature. in what particular scenario do you see yourself immediately reaching for this capability?
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.
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.
😎 Gleam is really interesting because it takes pretty much the opposite approach of Scala, despite some similarities. Scala is very maximalist, packing in as many bells and whistles as possible into the language. That creates a situation where there are many ways to achieve the same thing. In contrast, Gleam is about as minimalist as it gets. The case could be made that minimalism is a "missing feature" of Scala, depending on who you ask. That said, I have personally always had an affinity for Scala.
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.
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
"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.
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.
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 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
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.
maybe. I thought the syntax was interesting irrespective of any performance / concurrency / reliability narratives. I also don't yet have a good handle on BEAM yet, so that's also a factor. I think I understand the historical significance of it, but I am still trying to fully understand what it brings to the table today that you can't get in other language ecosystems.
@@codetothemoon it’s a true actor system, which means communication happens via message passing which is more generally useful than channels. It is distributed concurrency as well. And also live patching of a running system. It also provides a built in in-memory key value store, patterns for robust concurrency battle tested in high-availability telecom switches, and more.
I prefer Elixir .. it's important to say something about Erlang and Elixir when talk about Gleam because they all share the same genes and they all target Beam VM with all it's superpowers.
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.
@@codetothemoon I guess I've been the only serious user of scopes for one or two years besides the creator. It's the most powerful low level programming language with the best features of various programming languages (Rust, C, C++, Lua, Python, Lisp, ...). If it was a little more like Rust, I would probably use this language. It doesn't have a proper borrow checker yet (the algorithm works the same, but it doesn't support struct fields to have a lifetime). And there are no orphan rules. It's possible to define the same method for the same type in different libraries.
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!
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() } }
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).
I agree it does play on a different field. I think such a comparison is warranted for four reasons 1. The fact that Gleam compiles to JS means it may emerge as another viable alternative for full stack web development, as Rust has due to WASM 2. The Gleam syntax is heavily inspired by Rust 3. Those who are interested in Rust are often interested in bleeding edge languages, so assuming Rust as a point of reference when taking a first look at Gleam may be helpful 4. I make lots of Rust content, so subscribers are more likely to be familiar with Rust
@@codetothemoon Thank you for such a swift reply, and I apologize for my harsh tone. I'd also suggest to keep your eyes on June language, cocreated by Sophia Turner, who has had extensive participation in both the TypeScript and the Rust team (and is also the creator of Nushell)
If Gleam needs a VM to run, then how does Gleam VM compare to JVM? Does Gleam have something like Virtual Thread in Java? Then how does Gleam compare to Scala which, IMO, has very good language features?
Scala takes somewhat of an everything but the kitchen sink approach. It seems to have pretty much every functional and object oriented feature one could ever possibly want. Some may find this desirable, but it leads to being able to do the same thing 1000 different ways, so idiomatic approaches can become a little fluid. Re: Beam vs JVM, i don't know too much about this, but one of the Beam claims to fame is first class support for massive concurrency via the actor model for data sharing between tasks.
BEAM is amazing in its niche. Where the JVM is a crutch intended to make Java's abstraction possible, BEAM is an F1 car that can leave most competing technologies in the dust when it comes to easy scalability, reliability, and I/O performance, but is largely useless outside the racetrack.
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....
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.
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
Yes the BEAM ecosystem seems to have a really fantastic reputation! I'm currently trying to get a better handle on why that is - whether beam is still a good choice today for the same reasons it was in the past, or whether other ecosystems have since "filled in the gaps" with respect to the things beam is notable for
@@codetothemoon as far as im aware nothing like it has been created ever since. as an example, large parts of discords backend are written in erlang, which is comparatively pretty old compared to discord
In rust we can do like : let ..... = match str_var { m_var if m_var.starts_with("Assistant: ") => ....... , m_var if m_var.starts_with("User: ") => ........... , _ => ..... }
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.
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.
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.
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 didn't, maybe I should have! Tbh I still don't fully understand BEAM at the moment. I do plan to do a video on Phoenix, maybe I'll circle back to it there.
@@codetothemoon, but that's the point of all the BEAM languages. The only reason Erlang exist is beacause Ericson wanted failsafe concurrent systems so they created BEAM and language for it. The only reason Elixir exist is because someone wanted Erlang but readable. The only reason Gleam exist is because someone whanted Elixir but typed. I'm simplyfying here a lot, but I really wanna accent that -- Elixir and Gleam are easy ways to access BEAM power, and that's why we need them.
i started gleam looking at the documentation and i was amazed with the features until i try to do a simple task like creating an array and filling it and i realize that theres no for loop and im kinda force to learn the iterator package or do some weird recursion always creating new arrays and deleting the previous one to fill the new value and NO im good i just dropped its not for me
It's a pain to get started with, but once you get used to it, it's fine. I felt the same way when I started using Rust-I had to pore over the `Iterator` trait documentation and scratch my head whenever I tried to adapt a for-loop implementation, but now I use it by default (unless the code has side effects).
Can someone explain how it is possible to know the type of parameters at compile time, without declaring them? the only way i can imagine this working, is if it analyzes the function body.
@@paulsoukup6872 Thanks for answering. One scenario where I believe this could be helpful, is when you are not sure, what type something is, before writing the function. With the help of your editors lsp, you could generate the types for your parameters. Similar to how you would type the name of a package and import it automatically.
thanks, but fwiw I was genuinely curious about it. i had been thinking of semicolons as potentially being a remnant of an old approach to programming that was now of dubious value, but the number of people saying they prefer semicolons is making me question that
Really dislike the lack of methods. Even without mutability it is great to know what kind of methods are available for a struct. Try finding the correct function via auto-complete if you pass the struct as a parameter. A lot easier to do that with methods.
it has some benefits but man .. i hate methods so much .. why i have to replicate the same method for multiple types while i can use a single function for them all.. the developers abusing methods so hard..
@AbuAl7sn1 Kotlin has extension functions for that purpose. They are functions that take the class as first parameter but you can call them like methods. Great for discoverability!
One thing that isn't described in the video is the pipe |>, which allows to call the right hand function using the left hand as the first parameter, so for instance [1, 2] |> int.sum is the same as int.sum([1, 2]). So in theory, it should be possible to have a list of all the functions that use the type of the left hand as the first parameter, similarly to how your auto complete finds the methods (including extensions) fit.
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.
![Jack Harlow - Hello Miss Johnson [Official Music Video]](http://i.ytimg.com/vi/Q86_nlRoIGw/mqdefault.jpg)
Bro you can't just disrespect the pipe operator |> like this. It's literally the best feature of the language.
wow, I didn't realize until this comment that I hadn't explicitly mentioned it anywhere in the video! I really like it too, thanks for pointing it out. I may mention it in a pinned comment.
@@codetothemoon |> makes your point about methods kind of redundant though, as you just replace the . with a pipe, and now it reads subject verb
Also at 4:48 the pipe operator can help you out: you can write
let excited = nums |> list.map(fn(element) {element "!"})
But you still have to specify the function explicitly, there is no particular function attached to the type (like methods are) that's why `list.` is mostly required (importing map directly would not be very readable, how would you know it's map from list module and not something else?)
@@user-uf4lf2bp8t This was my thought exactly ^
Time to add 10 years of Gleam to my resume.
smart move! 🙃
I will add 11 years 😅
@@uidx-bobyou surely are an experienced hiring manager
You are hired .
Lots of recruiters ringing you tomorrow!
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.
Thank you for making this comment so I don’t have to.
agree 💯, i would love to dive in to such a comparison
I like semicolons because it defines where stuff ends.
You obviously don’t like them that much;
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.
ahh nice didn't know about this, thanks for pointing it out!
@@codetothemoon yeah I’m currently using elixir and rust as my primary stack. They work amazingly together. Gleam is cool but it’s young so I can’t just move everything over from Elixir yet. Don’t feel like writing bridges to use all my elixir packages with gleam lol
@@Khari99 I really want to love Elixir, but its dynamic typing makes it impossible. It's so hard to learn a language when you need to look up documentation online for everything. With Rust, I can hit SPACE + K to bring up a function's or type's documentation in my code editor and grasp what it does almost immediately.
That's why I'm excited for Gleam. If it gets its own Phoenix, I'll use it for all my web back ends.
For a package maybe, but the devs have stated that they wont be adding native targets to the @external API, but you can still get it by binding an erlang FFI that runs a native-implemented function (in a language like rust) for almost no cost, just gotta write a lil glue.
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
ahh yes thanks for pointing this out! though i'd still prefer thing.map(func). again, maybe i'm being pedantic though :)
@@codetothemoon nah we're all just C/Java brained 😂
@@codetothemoon yeah, but i would call Gleams piping as a more general approach of the same mechanism. Rust uses the first parameter of a function to declare on which instances a function can be called on (if i remember correctly, i have little rust experience). This is something that i personally really like in imperative languages.
The default piping behaviour in Gleam is really similar but with different syntax and by using a different mechanism: partial function application. Gleams partial application also allows explicitly choosing the function argument to pipe into. So any argument could act as "the instance".
example:
fn repeat_text(text: String, amount: Int) -> String { ... }
default piping behaviour:
"foo"
|> repeat_text(4)
explicit partial application:
4
|> repeat_text("foo", _)
@@codetothemoon back to list.map(): specifying which map() function to use (map() of module list) is a huge improvement in functional languages because otherwise you would have to look up which map() is being used. It's not done by default in Haskell and it really is such a huge pain, especially in tutorials and documentation.
calling functions on instances (methods) solve the same problem. But what if an instance has multiple map() functions? How do you specify which map() to use?
dot-syntax is really really readable and i also really like rusts approach but i think gleams approach is the most general with (i think) no special cases.
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.
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.
it uses the beam under the hood so its very good for backends that have high availability and the app can load new code while its running very cool feature ngl
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.
got it, thanks for elaborating on this! I am willing to believe that there are use cases where this feature makes a ton of sense.
Also, take note that this was cribbed from Swift, where it is used EXTENSIVELY.
@@AnthonyBullard It was pretty jarring when i first started writing swift, these days I'm not sure i can code without it.
@@MichaelFromOz I've never heard about a feature like that - but thinking about it, the params are on a different abstraction level inside or outside the function
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.
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.
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.
yeah, definitely a viable approach for those who prefer explicit types!
Gleam is like a functional version of Go.
hmmm sort of, but i think that might be an oversimplification
But not as fast as Go
@@codetothemoon the author, Louis, describes it as "functional Go". but its deff an over-simplification. he just means that its a small, simple, opinionated, easy to learn functional language
@@SnowDaemonGleam was originally supposed to have Haskell-like ML syntax but the author felt that it was not as popular lol.
I hate type inferrence in parameter lists. I want this to be explicit so I know what it's designed to take and do.
understandable - I suspect many folks agree with you!
The good thing is that you can explicitly declare your parameter types, there are plenty of examples in this video. And so far, I haven't found a library that isn't well enough documented on the types to use for everything.
@@Varpie Sure, but behavior changes depending on the implementation. For example, if it's gonna use iterators versus arrays, it would be nice to be clear and constrain that type to enforce arrays, if you want best performance.
Otherwise, the compiler must infer type constraints from the implementation, and that might be looser than they expect, limiting API changes.
@@Christobanistan Gleam is a statically typed language that doesn't have polymorphism or interfaces, so the only way you can have a function that can be used for either iterators or arrays is with generics. In that case, the decision would be the caller's responsibility, which makes sense to me. Unless I'm missing something, in which case I'd like to have an example, because type inference still requires to have a type defined somewhere and the compiler will give a nice error if it doesn't fit.
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")
```
whoa, actually this is the first example i've seen that has done it for me in terms of showing the value. I think I kind of get it now!
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"
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 think in some cases you are correct. for example in the "field update" scenario i covered, its certainly possible that under the hood the compiler recognizes that because the original value isn't used again, it can just be updated. Not sure if Gleam specifically does this, but I don't think there are any technical obstacles precluding it. BUT I think there are more complex scenarios where the compiler simply won't be able to "optimize via mutability" under the hood. I could be wrong about this.
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.
oh interesting I didn't realize this!
R user here, fun seeing the pipe operator in another language. Makes functional programming so much more intuitive for me to be honestly
I agree, the pipe operator is great. So sad i forgot to explicitly mention it in the video...
You can find the pipe operator in julia too.
@@guelakais1438 And F# and Elixir
that pipe syntax comes from Erlang IIRC, it's not from R nor Julia, and it makes sense that Gleam has it since it basically is an Elixir variation
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.
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
thanks I will try!
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.
re: pipe operator, me too. and i'm on the same page regarding your general sentiment of Gleam!
@@tuna5618 everyone wants a pipe operator but what I really want is true partial application
Currently having a blast writing Gleam. Very easy to learn language. And yeah - more gleam videos please.
Btw great video.
thank you, glad you liked it!
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.
Yeah, though AFAIK, Gleam's OTP library is still bare-bones compared to Elixir.
@@verified_tinker1818 good point, but what about just calling Elixir from Gleam? I mean it's no silver bullet, but is it useable? Or is it unwieldy (I imagine it might be similar to working with untyped actors in Scala, I did this like 8 yrs ago and it was horrible)
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
Like what I see far…Clean & Simple… à la F#. Will give it a shot. Thanks!
Yeah it's worth a look - if you can, let us know how it goes!
Please cover Lustre, and real-world use-cases for Erlang/Elixir interop!
thanks, maybe I will!
5:40 the Rust LSP (rust analyzer) has a shortcut to explicitly show inferred types. Maybe the Gleam LSP will have that too?
I don't think Gleam's aiming to replace Rust, but more "mainstream server languages" like go, python, java, js, etc
I agree. the syntax is so similar to Rust that it's hard to avoid the comparison. Also, the fact that it can be used in lieu of JS for full stack web development also makes the Rust comparison relevant.
Gleam is basically Rusty Elixir.
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)`
and what exactly is the difference?.. Options and Results are used in the same way in both Gleam and Rust
@@sunofabeach9424 That is incorrect -- given the function `find` for an iterable, an idiomatic Rust function would return `Option`, while an idiomatic Gleam function would return `Result(a, Nil)`.
Gleam uses `Option` to denote _optional inputs_, while Rust uses `Option` to denote any nullable value.
In the language tour, they state this:
tour.gleam.run/standard-library/option-module/
@@jly_dev ah so result is mostly semantic?
@@sunofabeach9424 basically Result is an Option but with a generic type instead of the "None". So you can have Result where E is the error type, maybe just a String, maybe your custom Error type
They made SCALA once again
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.
Gleam doesn't support recursive types does it?
@@samuraijosh1595
The following compiles in Gleam:
import gleam/io
pub type Nat {
S (t: Nat)
O
}
pub fn main(){
io.debug(count(S(S(S(O)))))
}
pub fn count(n: Nat) {
case n {
S (t) -> 1 + count ( t)
O -> 0
}
}
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 :)
thanks, glad you liked it! I won't be leaving the Rust ship anytime soon either, but i'll definitely be keeping my eye on Gleam
I don't think Gleam will ever replace Rust. They are designed for completely different use cases.
Gleam is designed around concurrency and simplicity.
Rust is designed to be as fast and safe as possible.
Gleam is so simple, it does not have anything like traits or interfaces. You would use functions or a type containing functions to pass around.
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.
what do you value most in the beam ecosystem that you feel like you can't get elsewhere?
@@codetothemoon High availability was the fundamental design goal of the vm. You get it almost for free by just using its language. There's a lot to unpack there but that's what I value most. This can be achieved elsewhere but it's way more complex and difficult to get right.
I'd love to see a video where you explore some of that through gleam or elixir.
gleam's syntax is actually Rust without semicolon
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.
Thanks for watching! so many more people that prefer semicolons than I thought there would be!
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.
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?
I agree it seems like it caters more to the things you'd use Go for as opposed to Rust. But the syntax borrows (no pun intended) so much from Rust that it's hard to avoid the comparison. I think the main reason why you'd choose it over Go is if you prefer the pure functional approach and the "next level" type inference
error handling is the biggest weakness of Go
it doesnt help me to avoid errors
Rust was not built for concurrency. Gleam will outshine rust and several other languages because of the BEAM
@@perc-ai The BEAM is a double edges sword. For server, sure, it's nice. But if you want to write something to ship to the users, it's a big deal having them install a VM just to run your app.
I'd say it competes with Elixir more than anything else.
Gleam is a statically typed functional language that runs on the BEAM. The concurrency model is what really matters.
good point! this video is more focused on the syntax, as beam concurrency seems to be well covered elsewhere
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
really nice video as always mate!
thanks so much 🙏
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!
yes to labelled arguments. `dismiss(view, false)` bad. `dismiss(view, animated = false)` good. wherever you’re viewing that code.
yeah i agree in a code review context where you might not necessarily have the inline help of an ide, i agree this is preferable! makes me wonder if we should strive for code review tools to have the same goodies that ides do
@@codetothemoon while better tooling is always a win, ordinary struct literals already require field names. so why shouldn’t functions get to have the *option* of requiring argument names? what even is a struct literal if not a funky looking function from which all instances of it originate anyway?
I've had unpleasant experiences with things like adding an optional boolean parameter to a function, while someone else, on a different branch, added a different optional boolean parameter to the same function and then after merging, some calls to the function accidentally specified a value for the wrong parameter. Labelled arguments could have prevented that.
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.
I didn't realize WhatsApp is using the beam ecosystem! thanks for pointing this out.
Why do you think Rust has garnered the culture you mention while other ecosystems (like beam) have not?
@@codetothemoon Yeah Whatsapp was built on erlang, kinda wild. I think FB switched it to C++, probably to lower overheads, but maybe Rust was a better option for safety.
I think that it's many things:
1. rust's promise is very cool. Memory safety + low level control. You might be a bit slower than C, but you can always go Unsafe Rust and get 99% there.
2. You get more modern tooling, specially when tooling around the low level langs isn't stellar. This lowers the bar to entry for a lot of people. There's probably a package for that. No make files. Etc.
4. You get memory safety, when memory safety is a mess.
5. The compiler tasing you again and again is also an incredible help. Verbose compilers help move you in the right direction.
6. The similarity in syntax to ALGOL style languages like C++ and Javascript.
I tend to prefer simpler syntax, like Go, or C (though I wouldn't write C for something that can get hacked), but I can't deny that the momentum in Rust is just mindblowing. People are just productive in these languages.
If there was a Go syntax style lang with a Rust style compiler I'd be very happy.
Tech RUclipsrs should sometimes try Scala; they will be amazed! ❤
I have written Scala in a professional setting and I love a lot of things about it, but there some that I don’t. One of them being the JVM. But absolutely a great language for many domains!
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 can definitely see this being a viable stack, for all the reasons you mention! I personally have a preference for language isomorphism across the entire stack, partially because it opens up the door to write frontend and backend logic in the same project, which I value highly. Would personally be happy with all Gleam or all Rust. But that's just me.
What about Elm? It's way, way more mature than Gleam and was made for the client side.
Love the internal names for the parameters. That's a great idea.
interesting, it seems like there are quite a few folks who love this feature. in what particular scenario do you see yourself immediately reaching for this capability?
@@codetothemoon I find this useful when I need to do some validations or transformations on the parameter before using it downstream in the function.
can you take a look at Roc? it looks very innovative but it is quite young
it does look really interesting, i've put it on my potential video idea list!
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.
Thanks, I have Roc on my "to check out" list!
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.
yeah i think explicit types are definitely warranted in some cases
You could also destructure strings in Erlang / Elixir. Even bit streams.
ahh thanks for pointing this out! destructuring is so nice
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 think gleam does it by detecting when an expression ends which is much easier in gleam because it mostly just has functions.
@@Ryuu-kun98 It's not easier. We'll eventually see a problem from it, even if we don't know that the problem was written in Gleam.
Oh what a great features!. They exists in Scala since... 2012 (?) :D
And in OCaml for like 15 years before that :D
@@780Chrisin Haskell for 30
😎 Gleam is really interesting because it takes pretty much the opposite approach of Scala, despite some similarities. Scala is very maximalist, packing in as many bells and whistles as possible into the language. That creates a situation where there are many ways to achieve the same thing. In contrast, Gleam is about as minimalist as it gets. The case could be made that minimalism is a "missing feature" of Scala, depending on who you ask. That said, I have personally always had an affinity for Scala.
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.
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
yeah since releasing the video I've seen a number of positive opinions of this feature, and I'm starting to come around
It's basically F# but with better tooling (at the time of writing).
thanks for pointing this out, I haven't actually tried F#!
"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.
true!
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.
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 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
how does it deal with stack management if there are no loops and you can only do recursion?
it has tail call optimisation
The compiler optimizes recursive iteration to normal while/for-like looping under the hood wherever possible. Just like Haskell.
I'd love to see a video on Lustre
Thanks for letting me know, I'd love to make one at some point!
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.
can it even be possible without stable Rust ABI?
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.
maybe. I thought the syntax was interesting irrespective of any performance / concurrency / reliability narratives. I also don't yet have a good handle on BEAM yet, so that's also a factor. I think I understand the historical significance of it, but I am still trying to fully understand what it brings to the table today that you can't get in other language ecosystems.
@@codetothemoon it’s a true actor system, which means communication happens via message passing which is more generally useful than channels. It is distributed concurrency as well. And also live patching of a running system.
It also provides a built in in-memory key value store, patterns for robust concurrency battle tested in high-availability telecom switches, and more.
I prefer Elixir .. it's important to say something about Erlang and Elixir when talk about Gleam because they all share the same genes and they all target Beam VM with all it's superpowers.
good point! yeah this video was primarily about the syntax, I'd love to do a deeper drive on BEAM in the future
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.
5:28 I've seen another language with static inferred typing for function signatures: Scopes
hadn't heard of Scopes - thanks for putting it on my radar!
@@codetothemoon I guess I've been the only serious user of scopes for one or two years besides the creator.
It's the most powerful low level programming language with the best features of various programming languages (Rust, C, C++, Lua, Python, Lisp, ...).
If it was a little more like Rust, I would probably use this language.
It doesn't have a proper borrow checker yet (the algorithm works the same, but it doesn't support struct fields to have a lifetime).
And there are no orphan rules. It's possible to define the same method for the same type in different libraries.
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!
Ever done a video on D?
Not yet, but it would be something I'd consider!
@@codetothemoon please do
You know I woke up this morning thinking, "Man... if only we had just one more programming language"
we also don't have nearly enough reactive javascript frameworks!
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()
}
}
Thanks. I hate it.
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).
I agree it does play on a different field. I think such a comparison is warranted for four reasons
1. The fact that Gleam compiles to JS means it may emerge as another viable alternative for full stack web development, as Rust has due to WASM
2. The Gleam syntax is heavily inspired by Rust
3. Those who are interested in Rust are often interested in bleeding edge languages, so assuming Rust as a point of reference when taking a first look at Gleam may be helpful
4. I make lots of Rust content, so subscribers are more likely to be familiar with Rust
@@codetothemoon Thank you for such a swift reply, and I apologize for my harsh tone. I'd also suggest to keep your eyes on June language, cocreated by Sophia Turner, who has had extensive participation in both the TypeScript and the Rust team (and is also the creator of Nushell)
If Gleam needs a VM to run, then how does Gleam VM compare to JVM? Does Gleam have something like Virtual Thread in Java?
Then how does Gleam compare to Scala which, IMO, has very good language features?
It uses the BEAM Virtual Machine, which is used by Erlang and Elixir
Scala takes somewhat of an everything but the kitchen sink approach. It seems to have pretty much every functional and object oriented feature one could ever possibly want. Some may find this desirable, but it leads to being able to do the same thing 1000 different ways, so idiomatic approaches can become a little fluid.
Re: Beam vs JVM, i don't know too much about this, but one of the Beam claims to fame is first class support for massive concurrency via the actor model for data sharing between tasks.
BEAM is amazing in its niche. Where the JVM is a crutch intended to make Java's abstraction possible, BEAM is an F1 car that can leave most competing technologies in the dust when it comes to easy scalability, reliability, and I/O performance, but is largely useless outside the racetrack.
@@verified_tinker1818 yes!
What's your name?
Ken, nice to meet you! What's your name? 👋
@@codetothemoon Desmond 👋
@@codetothemoon you make very good videos so I follow you on twitter
Edit: nice to meet you too
Can we get a macro for string pattern matching?
good question - this seems like it'd be possible. not sure if it exists already
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....
perfect analogy! 🏍️
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.
I can understand this perspective!
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
Yes the BEAM ecosystem seems to have a really fantastic reputation! I'm currently trying to get a better handle on why that is - whether beam is still a good choice today for the same reasons it was in the past, or whether other ecosystems have since "filled in the gaps" with respect to the things beam is notable for
@@codetothemoon as far as im aware nothing like it has been created ever since. as an example, large parts of discords backend are written in erlang, which is comparatively pretty old compared to discord
lol I am one of those guys that perfers semicolons
nice! I was surprised at how many of you there are!
In rust we can do like :
let ..... = match str_var {
m_var if m_var.starts_with("Assistant: ") => ....... ,
m_var if m_var.starts_with("User: ") => ........... ,
_ => .....
}
yeah, but it doesn't pattern match on strings, only matches on a condition
Luster yes please
nice, i have it on my video idea list!
The lack of types in function signatures is fine in private functions but inexcusable in public functions. IMHO
I think comparing Gleam to Rust, is like comparing apples to oranges.
I agree. It makes sense to compare them in some ways, and not in other ways 😎
gleams logo made me think it was another js framework
Understandable given that there are about 10 new ones per day!
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.
maybe you're right!
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.
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.
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.
man I need to stop getting these kinds of recommendations, bad youtube algorithm bad.
Gleam; the language for the lazy coder coming from Javascript that cannot be bothered learning Rust.
There - the video in one line.
Hah, that's one way to look at it!
it has GC and no loops, i feel clickbaited.
definitely can relate to the GC aversion. I personally like the absence of loops though :)
I love rust, but gleam looks like a better choice for web development.
maybe once the ecosystem matures a bit!
You can't just take away the VM. It handles the famous BEAM concurrency. And you didn't even talk about that here.
I didn't, maybe I should have! Tbh I still don't fully understand BEAM at the moment. I do plan to do a video on Phoenix, maybe I'll circle back to it there.
@@codetothemoon, but that's the point of all the BEAM languages. The only reason Erlang exist is beacause Ericson wanted failsafe concurrent systems so they created BEAM and language for it. The only reason Elixir exist is because someone wanted Erlang but readable. The only reason Gleam exist is because someone whanted Elixir but typed. I'm simplyfying here a lot, but I really wanna accent that -- Elixir and Gleam are easy ways to access BEAM power, and that's why we need them.
What abour elm @@РайанКупер-э4о
i started gleam looking at the documentation and i was amazed with the features until i try to do a simple task like creating an array and filling it and i realize that theres no for loop and im kinda force to learn the iterator package or do some weird recursion always creating new arrays and deleting the previous one to fill the new value and NO im good i just dropped its not for me
It's a pain to get started with, but once you get used to it, it's fine. I felt the same way when I started using Rust-I had to pore over the `Iterator` trait documentation and scratch my head whenever I tried to adapt a for-loop implementation, but now I use it by default (unless the code has side effects).
Haha imagine showing that little girls logo to a client. This is the language I’m using 😂
right before you inform them that their webapp needs a bit more css glitter 🪄
imagine showing a logo to a client...
were programmers bro, not marketing agents. focus on what important here 🤣
@@SnowDaemon haha that’s disconnection from reality. We are all marketers baby 😄
Can someone explain how it is possible to know the type of parameters at compile time, without declaring them? the only way i can imagine this working, is if it analyzes the function body.
It does. It look as what functions / operators those parameters are used with and knows from that.
@@paulsoukup6872 Thanks for answering. One scenario where I believe this could be helpful, is when you are not sure, what type something is, before writing the function. With the help of your editors lsp, you could generate the types for your parameters. Similar to how you would type the name of a package and import it automatically.
It uses the Hindley Milner type system, which in essence builds an AST and recursively infers the types based on where they are in the code.
Everyone is talking about Gleam but no one gives my boy Unison any love...
hadn't heard of it, looks kind of like Haskell!
Good interaction baiting on the semicolons! Well done! :)
thanks, but fwiw I was genuinely curious about it. i had been thinking of semicolons as potentially being a remnant of an old approach to programming that was now of dubious value, but the number of people saying they prefer semicolons is making me question that
10:05 maybe in couple of decades from now
maybe!
Really dislike the lack of methods. Even without mutability it is great to know what kind of methods are available for a struct. Try finding the correct function via auto-complete if you pass the struct as a parameter. A lot easier to do that with methods.
yeah, I haven't really solidified my opinion but I think i'm with you on this one!
it has some benefits but man .. i hate methods so much ..
why i have to replicate the same method for multiple types while i can use a single function for them all..
the developers abusing methods so hard..
@AbuAl7sn1 Kotlin has extension functions for that purpose. They are functions that take the class as first parameter but you can call them like methods. Great for discoverability!
One thing that isn't described in the video is the pipe |>, which allows to call the right hand function using the left hand as the first parameter, so for instance [1, 2] |> int.sum is the same as int.sum([1, 2]). So in theory, it should be possible to have a list of all the functions that use the type of the left hand as the first parameter, similarly to how your auto complete finds the methods (including extensions) fit.
Not at all. That's what modules are for. To group related functions and types, you put them in the same module.
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.
hah! I find this position relatable. I was a Java fanboy for so long....