The Star Language that will outshine Rust? Gleam
ฝัง
- เผยแพร่เมื่อ 26 มิ.ย. 2024
- A look at the Gleam programming language, through the lens of a Rust developer.
Keyboard: Glove80 - www.moergo.com/collections/gl...
Camera: Canon EOS R5 amzn.to/3CCrxzl
Monitor: Dell U4914DW 49in amzn.to/3MJV1jx
SSD for Video Editing: VectoTech Rapid 8TB amzn.to/3hXz9TM
Microphone 1: Rode NT1-A amzn.to/3vWM4gL
Microphone 2: Seinheiser 416 amzn.to/3Fkti60
Microphone Interface: Focusrite Clarett+ 2Pre amzn.to/3J5dy7S
Tripod: JOBY GorillaPod 5K amzn.to/3JaPxMA
Mouse: Razer DeathAdder amzn.to/3J9fYCf
Computer: 2021 Macbook Pro amzn.to/3J7FXtW
Lens 1: Canon RF50mm F 1.2L USM amzn.to/3qeJrX6
Lens 2: Canon RF24mm F1.8 Macro is STM Lens amzn.to/3UUs1bB
Caffeine: High Brew Cold Brew Coffee amzn.to/3hXyx0q
More Caffeine: Monster Energy Juice, Pipeline Punch amzn.to/3Czmfox
Building A Second Brain book: amzn.to/3cIShWf - วิทยาศาสตร์และเทคโนโลยี
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?)
Time to add 10 years of Gleam to my resume.
smart move! 🙃
I will add 11 years 😅
I’ll write up a job description that has minimum of 11 years of Gleam.
@@uidx-bobyou surely are an experienced hiring manager
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
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.
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!
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...
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
really nice video as always mate!
thanks so much 🙏
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.
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!
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.
Look into “use” - you can use it to emulate ? In Rust, early returns, defer in Go and Zig, and lots of other cool things.
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.
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.
Gleam is like a functional version of Go.
hmmm sort of, but i think that might be an oversimplification
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 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.
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.
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.
Gotta love me my semi-colons, I much prefer them to whitespace based stuff.
nice, so many more of you than I thought there would be!
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
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)
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)
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 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
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'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.
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!
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?
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.
Can we get a macro for string pattern matching?
good question - this seems like it'd be possible. not sure if it exists already
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!
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
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! 🏍️
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!
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
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
"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!
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!
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!
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 🪄
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.
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).
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 😎
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!
You guys are focusing more on tools than the actual problems
guilty as charged!
10:05 maybe in couple of decades from now
maybe!
Luster yes please
nice, i have it on my video idea list!
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.
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
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.
You lost me on “it runs on a virtual machine”!
yeah, probably not a popular thing for fans of Rust 🙃
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 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.
In pride activism that is.
maybe, not sure though hah
Not a chance..it is not in the same category as rust..this is for web dev..
i agree that it's not in the same category as Rust, but I'd dispute that it is limited to web dev
Interesting. Also, I prefer semicolons, since you asked.
thanks, there are way more of you than I thought there would be!
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: ") => ........... ,
_ => .....
}
yeah, but it doesn't pattern match on strings, only matches on a condition
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....
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!
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.
3:12 Not too-ple, but tu-ple (like: couple). An american bad habit to automatically make the first vowel long.
odin, odin, odin
i've only given it a cursory glance, but i haven't quite been able to figure out what niche it fits in. maybe i just need to look into it a bit deeper
Loved the video. Really excited about Gleam but I am tired of Rust people being Rust people. The ending statement just seemed unnecessary and just shows incredible bias. I love Rust, but not in the same way you Rust people do. It's a whole another level.
thank you! yes, the ending statement is based on my personal tastes. what would your ideal language be? is it something that already exists?
Gleam React anyone?
Is it really better in practice than Typescript?
yeah it's hard to say - with what I know right now, and without taking into account the maturity of the frontend packages in the Gleam/Erlang ecosystem relative to JS, I think I'd prefer Gleam. But that's just me.
Rust is not a highly concurrent language that’s why big tech companies use elixir cause of the BEAM. Gleam is on the way to replace other applications where concurrency is an issue.
this is something I keep hearing and have been trying to get to the bottom of. what does the beam ecosystem give you that you can't get with Rust / tokio?
@@codetothemoon The BEAM is an ingenious architecture based on the Erlang VM. It "opts out" of the OS and only runs as a single process on the machine. The BEAM creates a thread per core, a scheduler per thread and a run queue per scheduler all within the Erlang run time. It is effectively its own mini OS. The Erlang lang was made for concurrent systems, its really hard to find any other language that can boast this. It has built-in support for process supervision and recovery, distributed computing, async message passing, fault-tolerant mechanisms etc.
it is theoretically possible to build the same thing in Rust, but you are going against decades of optimizations it would be a MASSIVE undertaking.
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)
which faster when build a backend server?
i think rust wins by a large margin. I haven't thoroughly looked into it, but based on a cursory glance at benchmarks I don't think Gleam has seen a substantial amount of investment in low level optimization yet
@@codetothemoon thank you so much, so i will continue with learning rust, and don't let gleam make learning rust slower
@@codetothemoon It depends on whether you're bound by the CPU or by I/O. I don't know if there are any good benchmarks that compare BEAM's and Rust's performance, but I wouldn't be surprised if BEAM outperforms Rust when it comes to concurrency.
Of course, for CPU-bound tasks, Rust dominates.
MY GOD!!! 😍❤️❤️❤️❤️
I like it too!
You should really take a look at Nim
i've taken a brief look before, and was really impressed with what I saw. I've been wanting to do a deeper dive into it.
@@codetothemoon It's worth it. We are now having a bunch of our production programs (mostly networking) written in Nim and we are super impressed.
We have written a few of our production tools (network related) in Nim and are super impressed. Really performant and easy to write at the same time.
lol I am one of those guys that perfers semicolons
nice! I was surprised at how many of you there are!
I prefer semicolons. And im a python dev...
Gleam is great tho
whoa interesting! ooc why do you prefer them?
@@codetothemoon I like when different "pieces of code" have very clear boundaries.
A great example would be braces for denoting code blocks. In brace-based languages I can copy-paste anything with whatever indentation (as long as it's ends up inside braces) and then run auto-formatter and the code would look nice. In python it is not as easy because indentation effects AST, and I have to manually fix indentation, and only then I can run auto-format.
Semi / no semi - pretty much the same but to lesser extent. What if I get a snippet consisting of multiple statements, but for whatever reason it's all one line (maybe someone can't use slack properly idk). If statements are separated with a semi - auto-format would fix it in a sec. Whitespace characters are easier to lose.
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.
also theres a really big difference between STATIC typing and STRONG typing. And its the main selling point of Rust for me!
I just don't see a compelling reason to pick gleam over what's already out there. I also think implied types on function signatures determined at compile time... is unhelpful during dev time
yeah - it's the recurrent challenge that new ecosystems face - even if it is good, is it enough to displace the currently accepted standards? for me, the rationale would be similar to the reasons I choose Rust for web development - primarily static types. Gleam has the static types but also has an edge over Rust in brevity. To me that's an interesting combination.
BEAM VM ... just saying.
good thing or bad thing?
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.
got it, i can understand this perspective!
I don't like semicolons, but I find it too hard to let go using them;
this seems to be a common sentiment!
I prefer semicolons just like I prefer having periods at the end sentences I read.
I can definitely see that - there are more folks with this stance than I thought there would be!
5:08 That’s not pedantic of you…. Floating functions are annoying. Allowing methods on classes/structs/records is just good design… grouping relevant methods together that travel around with that variable… that’s good. Floating methods are bad because they’re hard to find and can be put anywhere in the code; nothing to guide our design. Besides that, instance methods are the most functional thing you can do; they allow us to pass around many closures all at one, rather than one at a time.
i prefer semicolons
nice - there are definitely more of you than I thought there would be!
I like semicolons. idk why and can't explain it but they just feel right.
yeah, i can relate to that. I personally find it really hard to know whether I prefer something a certain way because I am more familiar with that approach, or because it is objectively better. Part of me still has an affinity for semicolons, and I'm not entirely sure why.
I prefer semicolons, because they are more explicit. But I don't care that much. Gleam looks really fun! Will have to try it soon
gotcha - as opposed to line breaks, which could potentially mean the end of an expression but could also appear in the middle of an expression arbitrarily, right?
@@codetothemoon exactly. I've seen some cases where JavaScript was throwing a weird/unexpected error, because the next line had a typo and it was being interpreted as a multi-line expression. Such cases are rare, but I just *might* be an explicitness extremist 😅
@@qwfp I'm pro-semicolon in languages that aren't whitespace-delimited. Javascript/Typescript has Automatic Semicolon Insertion, which is different and error-prone for exactly the reason you stated, so I'm very pro-semi for that lang. I don't mind being free of them for Golang, Python, Elixir, Gleam, etc - they're built with some forethought around that design choice. ASI was only invented in JS as a way to keep functioning in the browser even if the dev got some things wrong, which is a philosophy that I think ultimately failed and JS/TS has been recovering from ever since (see "use strict" lol)
@@dman01989 In the case of Gleam, since it has implicit return, I think I would prefer to have semicolons to distinguish between the final expression and the other ones. Because right now in Gleam, you can have `let x = "foo" "bar"` as a last expression, and the function will return "foobar", which is slightly unintuitive for me. Or maybe it should just not allow `let`-expression to have a return value.
But, again, that's a small issue and I'd rather get back to the tabs-vs-spaces war (it's spaces btw)
@@qwfp We agree on that one (spaces FTW). I think the let expression being the last expression of a function is a good point, though I'd argue that's a job for a linter rather than compiler. Rust is the only language where the presence or absence of a semicolon at the end of the last statement determines implicit return. I'm still not a huge fan of that. I've learned to look for it but still I think it was a mistake to have an optional implicit return (pick one or the other).
I like semicolons, sometimes they are needed (such as in TS, when having a cast as the first statement of a line you NEED semicolons otherwise it won't compile)
gotcha - but do you prefer languages that require them at the end of every statement, even in cases where the end of the statement could be inferred by other means?
@@codetothemoon I actually prefer, I like knowing the end of a statement, mainly in some cases where we have the builder pattern thar spans multiple linear, having the semicolon helps me figure out where a statement ends
this isn't really relevant in gleam though, it has no statements, everything is an expression
Actually I find myself neutral, my biggest concern in code is Angular unit tests nowadays the rest goes smoothly
I prefer semicolons;
nice, this perspective is turning out to be far more common than i thought it would be!
Well, not everything that comes with new methodology of writing the code means we have to embrace it!
Rust is the most flexible, and no need to remove loops to make a trend!
i used to be of the opinion that the more flexibility the better. recently i've sort of come around to the conclusion that the fewer ways there are to do something, the better. as long as the "one way" to do a particular thing is reasonable of course. That's just me.
Flexibility also means many ways to do the same thing, which gleam tries not to do. There should be one way to do something and it should be good.
No loops is part of functional languages because loops require mutability or using something like break
Why not use Dart for this direct to JS stuff? I do prefer semicolons. And you should remember that needless consistency is the hobgoblin of little minds.
I've heard great things about Dart! it definitely is pretty distinct from Gleam in terms of design decisions though. perhaps most notably, Dart supports dynamic types and mutability. Different tastes may favor one over the other.
Nope, hate ;
surprisingly, i think you're the first with this perspective to comment. I'm very surprised at the number of folks who prefer semicolons!
@@codetothemoon less is more?
F sharp. Or c# without loops and classes.
Useless stuff. The key of each lang is an idea of usage and not the lang features. Taken
Rust, spoiled its main idea with gc to achieve what?
The main goal is a type-safe language for the BEAM-Ecosystem
The forced immutability and no if or for loops feels emotionally painful for me. Like early returns needing a match statement and nested for loops needing nested map statements doesn't sound like a fun time.
yeah, you may have a point here. I couldn't think of any specific scenarios where these constraints would cause a huge issue for me, but I'm sure we could come up with some example scenarios where these loops, mutability and return statements would actually make the code more concise and readable.
As far as I know the BEAM VM doesn't have any mutability, so true mutability is simply not possible in the erlang-world.
The benefit of it is that you can pass data into erlang processes, which could even run on a different machine.
Early returns are somewhat possible with the 'use' keyword in gleam.
i like semicolons. one niche usecase is that multi cursor allows cool stuff with it.
good to know! what multi cursor abilities does it enable?
@@codetothemoon let's take something rudimentary that I did a few days ago.
>Select a block of text
>split selection by ; (Selection included line separated method calls)
>Profit.
(Editor is helix, I don't know how it will translate to other workflows)
yeah rust is dead, time to add gleam to linux kelner :3
hah!
I prefer semicolons. 👋
interesting! howcome?
@@codetothemoon I like them for the same reason periods are nice in written language. They serve as a good way to end a thought. Additionally, they simplify the rules and conditions for grammar in the language and parser. Finally, I'm not a fan of forced whitespace formatting.
@@GTLugoit doesn't use forced whitespace at all. it just parses lists of expressions where the ending can be inferred without semicolons. without macros rust also has "forced whitespace."
@@codetothemoon It ensures more consistency in the language. You don't have to ask yourself if you should put semicolons or not, like in JavaScript. JavaScript engineers don't have to be split up in two groups. In Python it looks odd having to put semicolons between statements on a single line while not on single line statements.
It also greatly simplifies the language's grammar and other rules.
And also in Rust, being a very expressive language, not putting the semicolon actually means something and I find it actually useful!
Oh... So it's like another js framework but it's a language on its own. Hm ok. Not gonna use anyways
I don't think its fair to say that it's a JS framework, for the same reason TypeScript isn't considered a JS framework. Both of them just have the ability to be compiled to JS.
that's a very inaccurate statement lol
I love semicolons, a quick semicolon to explain what I am doing, 2 semicolons for structured documentation. 3 semicolons to separate regions of code. Of course code should be readable without comments😊
except gleam is so slow, they made really beautiful syntax but forgot about performance completely
yeah I've glanced briefly at some performance benchmarks, they look pretty abysmal at the moment 😞 will be interesting to see how that narrative evolves
This isn't a Gleam thing specifically - Gleam compiles to JavaScript or Erlang, and then relies on JS Runtimes or the BEAM to run the code. Saying "Gleam is so slow" is saying that JS and/or Erlang are "so slow". Generalizing statements like this completely miss the point of the language.
what benchmarks? gleam compiles to erlang or javascript and has negligible runtime overhead. neither of those languages are slow in the domains you'd use them in, so i'm curious what those benchmarks were measuring
scala > gleam
I love Scala, but my two main problems with it were (1) so many ways to do the same thing, so "idiomatic" approaches are hard to nail down, and (2) Interop with Java types - Kotlin does this much, much better
Scala in 2024?
@@wondays654 it never ends
The fact it's garbage collect just makes me go "meh." The whole point, IMO, of Rust is no GC so execution is deterministic.
Rust could do a lot of things better, but Gleam seems to be strangely trying to be super performant but also not. More like a language technology showcase.
Also, we already have Go for this use case.
I'm not entirely sure what Gleam's performance narrative is yet, but as you say it's GC so right off the bat that puts it out of the running for applications that require maximum efficiency and consistency around performance and memory usage. I didn't get the sense that it is "trying to be super performant" - I got the sense that it instead optimizes for other things like developer experience, simplicity, etc.
While the niche it occupies seems to be closer to Go, Gleam seems to offer quite a few things that Go does not, and some might find those things compelling.
Type safety, I think, is an interesting idea for a BEAM language, which really doesn't have a ton of type-related optimization built in. It's not bad to be typesafe if you want a larger application and want to use the types as a tool for communication and static analysis, but ultimately, as a senior dev who is working in Elixir now, I'm reaching for static types a lot less than I would have expected. IMHO, Elixir & Gleam have a ton of potential for web servers in particular (IO-bound use cases), and they're very fast and efficient in that scenario. Golang, being compiled and GC'd, adds decent CPU performance as well which is nice, but IMHO it's horrifically boring so I don't use it for my side projects (I also like being more functional than Golang would have me be). OCaml I think is a nice in-between but the ecosystem last time I checked was not super great.
Agree
it seems like a garbage
howcome?