Rust is all about control. It's a programming language designed to give you the most ergonomic possible access to the lowest level primitives. If you're a web developer and you've never asked yourself "Should I use Message Passing or a Mutex here?", you probably shouldn't be using Rust.
Designed for the most ergonomic possible access to lower level primitives? Maybe designed for the safest way to access low level primitives, but ergonomics are far from Rusts priorities IMO. Rust is very very complex
@@IsaacHarrisHolt Hey, I’m the author of the Packt book Rust and Web Programming and I’m also writing the O’Reilly book on async Rust. Skill does inhibit productivity in Rust, but when the developer gets past a certain skillset, then Rust gets really productive and flexible. For my web systems, using Rust, I write less code than when I was coding web servers in Python. With just a change of one line, I can swap out databases, hook my API endpoint up to a unit testing harness. I can compile all my servers and JavaScript frontend into one binary, or burst it out into microservices. For async, if you just use the async functions, then all the traits are auto-implemented for you and the compiler will check that everything you pass in can be passed over threads. You want more control over your async traits? Then implement the future trait. The strong type system in rust combined with traits enables you to directly interact with third partly libs on a whole other level. On top of this, because of the lack of garbage collection, I can embed my Rust code into Redis, NGINX, Postgres etc, and WASM support is amazing. I’ve open sourced the code for the 3rd edition of Rust and web programming. If you want me to go through the code with you, email me at maxwellflitton@gmail.com
Sometimes I dream of a garbage collected mode for Rust that can use standard Rust ecosystem but when you write, all references are ref counted and you just don't care about lifetimes.
Great video, thanks. It's a bit sad that it was needed, though 😢 I'm one of many who are hopeful about the "native" backend for Gleam, so we could get rid of Go as a "middle ground" option 🙏
I recently did a full stack web development project completely in Rust for a university course and yes, it was very time consuming and difficult. I love Rust, but I would recommend a simpler and more specific language if developing prototypes or with hard deadlines. That said, the performance was noticing better than projects I have created in Django.
"Rewrite it in Rust" is 90% of the times just the Javascript PTSD taking place in the mind 😅.... "even then you should use GO" is a hard truth to swallow and thanks for saying that out loud! Great vid!!!
If rust was a panaceum, gleam team wouldn't even try writing the compiler for their language in an already "perfect" one. They both have their use cases.
Rust has no use case, if you must write systems code, use c++.. unless you need to write a library, or the lowest level stuff, then use C. If you need something safe, write it in C#, everyone loves it and it's very productive. There is nothing that must be written in a systems language, yet also has safety an even higher design priority. Gleem might have a use case, Rust doesn't.
@@cyberpunkspike No need for safety in a systems language? Over half of all CVEs are memory vulnerabilities. Write your libraries in C? Remember that heartbleed was caused by a missing bounds check in a C library.
@antonf.9278 Reading isn't a strong point for Rust degenerates, I know... Security isn't the highest design priority, doesn't matter if you think it should be, it isn't. If you need systems level code, you end up writing large amounts of unsafe Rust, otherwise you didn't need to write systems code in the first place.
Just a pet peeve of mine, but I hate the phrase "don't compare...". Why not? What is this video if not comparing those two languages? By all means compare them, just be mindful that the differences do not end on few simple characteristics. If you compare soley on speed for example, only then you are making a mistake. And of course this extends to other things "comparing apples to oranges", "don't compare my actions to this person's" etc.
I think comparisons like ‘Rust vs. Gleam’ aren’t very interesting because they usually focus only on syntax. If you want a more in-depth comparison, you need to include something similar to the BEAM, as it’s a core part of Gleam on the backend. Rust has some comparable libraries like Bastion (though it’s outdated) and Lunatic. Alternatively, you could compare Gleam’s actor model with Rust and Actix's actor model
@@IsaacHarrisHolt I understand your point. My issue is only with semantics. It's just a pet peeve, do not pay it your mind. It's like when people use "literally" when that's not what they mean.
One day I would like to see a thorough comparison between Gleam and Elixir since they are very similar in a lot of ways and the biggest differences I know of would be static typing and syntax. But I don't know too much about Elixir (I use it for personal projects but I am not an expert) and I know nothing about Gleam (except for a the view videos from Isaac I have watched) The reason is because so far I haven't seen anything from Gleam that would make me choose it over Elixir. But a side by side comparison might shed better light on a few things.
Totally agree. This has annoyed me on so many topics. A common one is claiming you "can't compare an editor vs IDE"... Well we're all deciding between the 2 options, and usually don't need both at once... So how to pick? That's what a comparison is. They don't have to be exactly the same thing in every single facet. If they were... There wouldn't really be anything to compare anyway. Maybe they "can't"... But they're confusing their lack of thinking and reasoning abilities with mine. I'm quite capable.
What I find hard for now with Gleam is its standard library. You can't even build a simple web server simply, you need to use a package for that, and it's pretty uncommon and a lot different because it uses the actor model. Also, there is no official doc on how to use concurrency, it's not clear, I can't find anything on the site that talks about that. There is nothing like the "goroutines" to build concurrent programs. I know that there is a package to build concurrent programs, but it's not clear on how to use it. I think that's the biggest problem and a huge downside compared to "Go" for example, where everything is straightforward. Saying that you can learn Gleam in an afternoon is not true at all. Learning how to loop and create functions, types and other basic things is obvious in all languages. I really like the language, I hope it will get the documentation and the support it deserves, If I had the level to deeply understand the concurrency in Gleam, I would've gladly contributed.
I think the standard library is well-equipped. The reason there's no webserver implementation is because Node and Erlang handle webservers very differently, so there's no way to make something that works well across both. Also, it's actually reasonably uncommon for programming languages to provide fully-featured webservers in the standard library - Rust doesn't either afaik. As for concurrency, again it's because there's big differences in how these things are handled on the BEAM vs on Node. That said, I agree the documentation needs extending a fair bit, and it's why I made a video on the topic ;) If you want another good resource: github.com/bcpeinhardt/learn_otp_with_gleam
There's nothing hard about using a package. The standard library is a normal package. Large standard libraries are a relic of a time before we had package management.
Because Gleam is a very young language. Version 1.0 was released in March, 5 months ago. Everything that you are asking is in an Elixir. There are a lot of books, learning materials, and videos about the language, OTP, and BEAM. Personally, Elixir is the best choice because of the materials.
@infantfrontender6131this is true, but a lot of those resources (and existing Erlang resources) can also be applied to Gleam! The concurrency model is (mostly) the same after all.
@@lpil @IsaacHarrisHolt Thanks a lot for taking the time to answer, thanks for the clarification. That's what I thought, compiling to JS and Erlang makes certain choices probably harder. Gleam is in good hands, that's for sure! I'll take time to understand the concurrency in Gleam using the GitHub repo, thanks!
Isaac, thanks for such a great explanation! Let me ask you a question of a developer who likes Elixir (and its great ecosystem) and suffers from lack of strong type system. From your point of view, is Gleam mature enough for production? Can it be considered as a replacement for Elixir (even if not now but in time)? At the moment it seems more like a concept...
Gleam is definitely production ready! There are already companies using it, in fact. I know of one in particular that uses Phoenix LiveView for their front end, but call out to Gleam code to have type safety for their business logic
If you use copilot or codeium for fancy autocomplete with gleam, it will provide rust code 99% of the time. Gleam is a new language that AI hasn’t had time to familiarize themselves with yet. That was my initial reason for comparing gleam to rust. Those few keywords that rust and gleam have in common make it very difficult for copilot to work when in a gleam project.
I tend to find that Copilot's okay once you've written a few lines, but it does sometimes get the syntax mixed up. The same will be true of any sufficiently new language though.
TL;DR: The purposes of the languages are: - Rust: Power, memory safety, and performance. - Gleam: Concurrency, fault tolerance, and ease of learning. Key differences: - Rust: Has a steeper learning curve, requiring more effort to master. - Gleam: Is designed to be easy to learn and write. - Rust: Runs natively on the machine and manages memory through the borrow checker, leading to better performance and lower memory usage. - Gleam: Runs on the Erlang VM and uses garbage collection for memory management, which can result in slower performance and higher memory usage.
7minutes 46seconds ain’t that long… who are these people who want to know about cutting edge languages without any time to watch a brief video? Would you have preferred a TikTok or something?
People who want to farm likes on their comments for... some reason. I've seen lots of stuff like this, and I'm convinced at least some of it is AI generated.
I wonder if i can integrate gleam with my existing code base. It'd be too much to rewrite in gleam, but would be cool to write some components with gleam
The comparison that would be valid to consider is Gleam vs. Elixir. Both target BEAM, but Gleam is apparently not using all the advantages. Like macros and declarativness
I'd love to see a similar video comparing Gleam to Go. The goals of Gleam you stated in the video are practically exactly the same as the stated goals of Go. Not to mention that Go is a much easier sell to most developers because it's one of the most procedural languages out there and thus it's more friendly to those coming from an old Java background. How do you sell someone on Gleam when Go already exists and is more popular at the moment? EDIT: and more importantly, what arguments would you use to sell a small development team in a company on Gleam, if any?
Gleam and Go are similar, for sure, but when it comes to building resilient software, the BEAM has a lot of nice things that Go doesn't. For example, Go makes it difficult to detect if a process has crashed (you kinda have to check it manually)
Our backend is built around warp which could potentially be used to serve the gleam application I'm not sure what the value in that would be over just using pure gleam or pure rust. What are your suggestions for incremental adoption of gleam in cases where you're already using rust?
If you're aiming to adopt any language incrementally, the most important thing to do is use a shared set of types for communicating between the services. You could use protobufs, OpenAPI specs, or whatever else you like, but make sure there's a common schema.
I'd argue that while the language is probably just as complex, Rust's learning resources (the book, etc.) are a lot more accessible (and arguably better) than those for C++. It's hard to know where to start with C++ at least!
My point was mostly around documentation, and while Rust is probably more complex than C++ if you're only using modern stuff, the problem is that C++ is so, so bloated that reading C++ code is a bit of a gamble as to whether it'll be using features you're familiar with or not
@@IsaacHarrisHolt A B S O L U T E L Y. I'm currently using C++ and I would do anything to get Rust syntax. Basic simple Rust is really really readable, you do your little .clone(), the match on Result, yadi yada it's all good and simple, whereas basic C++ is already unreadable (and this is coming from someone who's mother tongue is C). But once your start to introduce lifetime annotation sprinkled with some traits, or higher bound trait, and macro than yes both language actively compete for who's going to be the least readable.
I haven't tried gleam at this moment, but I do love Rust. And I agree that you definitely shouldn't use it for all cases. In general I'm slightly annoyed that typically speed is the only reason specified for using Rust. I think Rust is also great for having strong reliability and structure in your code. When that is my goal, my style of writing also makes me avoid issues with lifetimes and generics. If you code strategically it becomes much quicker to write in my experience. Based purely on intuition I'd say it takes about 1.5x the time to write in this style in Rust, with about 4x the time if I optimize for performance. This isn't a proper measurement though, just a gut feeling. Anyways, definitely agree with you in general.
Fair enough! I think the reliability and structure come from the type system though, especially ADTs. Since Gleam also has those, I don't see it as a particular win for Rust in this particular case. Also, since you haven't tried Gleam, I can't really put much faith in those 1.5x and 4x numbers. You also sound like you're fairly proficient in Rust, so it makes sense that it's gonna be faster for you to code that than Gleam
@@IsaacHarrisHolt I was mostly comparing to languages I use when iteration speed is my priority, I can't make the comparison to Gleam for obvious reasons. In my experience the borrow checker does have an impact on how I structure my code, or to be more precise avoiding conflict with the borrow checker does. But to be fair it's probably because I tend to over-complicate types by default, so maybe it's just keeping my bad habits in check. But thinking about it now I am getting more interested in looking into Gleam. I'll probably try to pick it up once my schedule clears up. Anyways, thank you for the useful video and response. I've subscribed and will check out more of your videos later, as I'm getting more interested in Gleam.
Agreed! I don’t really care so much about the *performance* that rust provides… it’s a gigantic benefit of course… I’m much more interested in the reliability aspects. I quite like that my code doesn’t generate 3AM emergencies. Being able to sleep soundly at night is worth far more than anything. I also think the video is greatly glossing over the development time aspect… Yes, it may take longer to write code in Rust (at least until you get good enough at it)… but what you spend on development time is *more* than made up by lack of debugging and chasing runtime errors! So many folks miss that Rust is able to give you such incredibly reliable software, and focus solely on the “performance” aspect alone…
Again though, that reliability comes mostly from the type system, which is shared with Gleam. Also, Gleam runs on the BEAM, which was also designed for creating reliable software - it's why it exists.
yeah, the use case is absolutely different, but the main reason i'm interested in gleam is because its syntax is familiar to me as someone who learned rust first
As a Rust user, I have to agree the "rewrite it in Rust" movement was definitely a mistake. I think what a lot of people don't understand is that coding languages are entirely situational by definition, as a coding language is just a specific interpretation of abstraction of machine code. Sure, a language like C is technically "general purpose," but how many people are making LLM's in C? How many do you think are writing embedded firmware (not counting the RPi Pico) or system drivers in Python? You know? Rust is great for a lot of reasons, but it's not an end-all-be-all. Nothing really is.
This is a great take. These days we're also seeing more and more specialist programming languages and fewer "general purpose" ones, and I think that's fine! Alternatively, we see languages like Gleam which can compile to different backends depending on the use case you're targeting.
Currently I’m using Elixir with the Rustler package for FFI when I need to easily use Rust for anything that is performance critical. When we have some of the elixir package equivalents and FFI packages like Rustler in Gleam then I’ll make the switch and see how I like it.
Yeah, I don’t like Elixir’s syntax, I prefer Erlang’s. But I’m waiting on a Rustler for Gleam too to start using some Gleam. I would also love if there was a way to do long lived interop between BEAM processes and Rust/C than NIFs.
@@IsaacHarrisHolt from what I saw before I had to write a bridge to use elixir packages in gleam and this which seemed very cumbersome and annoying. If there is an easier implementation I’d love to see a video on it!
You have to write an FFI, but it's not particularly complex. And sometimes you just need to create the @external annotation. I have a video on the topic :)
@@IsaacHarrisHolt I’ll check it out. I have a pipeline in broadway with a couple of complex functions I am trying to move over. I’ll see how feasible it is for me.
I'm rooting for Gleam. The lack of type safety in Erlang and Elixir has always turned me off from using them. I do wish it had gone for a more "traditional" ML syntax instead of the rust style one. It feels like the punctuation is excessive, but that's mostly just personal taste. Re: using Go -- the problem with Go (that Gleam doesn't have) is that it isn't data race free. In Java, you can only have benign race conditions, in Go race conditions can leave memory and gc data in an incoherent state and thus violate type and memory safety. Uber found thousands of these race conditions when they added thread sanitizer to their workflow once it was available in Go. This is the kind of bug that is trivially easy to write by accident and that eats up tons and tons of development time. So I've never been inclined to use Go despite it's other benefits. Gleam, by virtue of running on BEAM, just doesn't have this problem. So it's kind of ideal for developing that kind of software.
Yeah, you convinced me. After I deploy my current ongoing Node project, I will try to rewrite many of my packages into Gleam, especially the backend ones. Is there a chance that Gleam to JavaScript will work fine for browser apps? Maybe not yet it probably doesn't have JSX support yet.
This is amazing, I’ve been interested in Gleam for a while now, I’m in a crossroad between learning Golang and Gleam. A lot of people keep recommending Golang, it’s understandable since Golang is a bit older and more popular but Gleam is really appealing, personally I love Erlang and the Erlang VM(Beam) and am planning to rewrite a TypeScript backend so, do you think Gleam a better alternative to Typescript?
I personally would stay away from JS/TS for the backend, so yes, do it in Gleam! If you can, run it on the Erlang target though - that's much better suited to backend work than the JS target.
The hardest part for me to grasp about Gleam is that it targets the BEAM VM... But it's not similar to Erlang, or Elixir. I have some experience in Elixir, but I have to stop myself everytime to just use a dang atom, and create a dang Sum Type...
Alternately, you can write your own virtual machine in raw machine code and then rewrite your SaaS application in your custom VM byte code. It is certainly an idea, but less certainly a good one.
@@IsaacHarrisHolt tbh it sounds like a fun project that would tickle my autism just right, but I have already written two virtual machines, so I should probably leave it alone lol
Gleam looks really nice! I have worked with Elixir in the past, and liked many things about it. But I also worked with ReasonML, and I prefer its style and type system. Gleam seems to combine the benefits of both. And makes getting into Rust easier because of its similarities in syntax. So you should learn both I guess.
I like the comparison of gleam to go. Peole hate the comparison of gleam to rust and pretty often say that gleam is go, but functional one and honestly I totally get it cuz both languages are really simply-powerful and really productive, but the difference is that gleam is more functional.
That's fair, but it's also a completely different programming paradigm. And there are those who would argue that significant whitespace makes Python harder to read, so it's very subjective
The use cases can overlap a good amount, and comparing programming languages is important to understand the differences - that’s the entire point of this video. Of course they are very different languages though, and use cases don’t overlap too much.
@@IsaacHarrisHolt I agree, but there are not a ton of better options which provide the same that rust does with proper sum types and good zero-cost abstraction. But it defintely is annoying to see everything no matter how small or high-level getting rewritten in rust despite not being something that would stand to benefit much from it.
You showed Kotlin in your video a language which often gets forgotten about. Does gleam have any influences from it? Kotlin has compose which let's you build gui very simply I could make an app without really reading about compose.
I don't know if Gleam has taken anything from Kotlin, to be honest. I'm not massively familiar with the language myself. Gleam's inspirations are mostly ML languages
At least getting into Gleam exposes you to the Erlang VM and encourages you to dig deeper. Getting up to speed with OTP is one of the best things you can do to become a better architect - even if you never write a single line of Erlang. On the negative side - Gleam is riding on the back of Rust’s current “popularity”, which could easily crash and burn as quickly as it appeared. As long as you don’t go tieing your identity to your tools, you should get something positive out of it
Elixir is gonna have to do what TS did and stick a type system on top of an existing dynamic language with all its quirks. It'll never have guarantees as strong as Gleam's
"Stop Comparing Rust To Gleam" That's not how the internet works. Now they're going to compare them. lmao. Interested in beam langs,. still don't really have a project for one, i just reach for Go for most things. but beam langs just make a lot of sense in chat and other similar type of projects. maybe handling a lot of inbound data points like weather, markets, etc.
Oh I'm well aware that the internet will do whatever it likes regardless of what I think 😂 Just wanted to make this video for me to link to when people bring it up in the future! Also, you're right about that being a good use for BEAM langs. Take a look at the Waterpark project, which was written in Erlang (there are good talks here on YT). Fascinating stuff.
@@IsaacHarrisHoltoh yeah. i'll check it out. I remember learning about erlang after watching a strange loop video and then diving deep into whatsapp's use of it. the video of the 1 server running at half capacity, but having like 3M concurrent convos is insane/
@@IsaacHarrisHolt any good web frameworks? might spin out an overengineered blog lmao. i'll need to dive into all the videos and just stumble through it.
It doesn't matter if the languages are targetting different goals. There is a lot to learn from every language. To try and stifle discussion about it is moronic at best and leads to situations like the Linux community being full of people like Theodore Ts'o who see interacting with another language as an attack on their identity and skills.
Actors is one of my favorite concurrency models to implement. It's ergonomic as hell, and I would have never started doing it without being able to discuss what erlang and elixir did differently from the languages I use.
@@IsaacHarrisHolt the video sounded more on the side of preventing the comparisons at all. Though I do agree that you should know which to choose in which scenario. Even though I'm not a fan of gleam (not a fan of complete immutability mainly) I still would rather someone pick that if they're just making a simple crud app and their only concern is speed of development and deployment.
Rather than the hammer comparison I'd say more like Rust is a swiss army knife in a lockbox, it can do everything you need to if you're planning to do a big project with a lot of different requirements, but it's going to be way slower than just grabbing the screwdriver from the drawer
Glean looks like simplified rust with garbage collection. But I will pass because no traits mean you have to hunt for all the functions like in python instead of just using a dot.
If you assume Gleam needs traits you again just directly compare two fundamentally different languages. Not sure how Gleam does it but even in Rust you can often fully replace a trait with an enum and it's just as simple to call the method.
They are fundamentally different and are not even comparable. For example, if you target bare-metal embedded system, an Erlang runtime is nearly impossible, while Rust is perfectly fine. Also they have very different ways to define and deal with ABIs. It’s not just the syntax.
@@IsaacHarrisHolt There entire language is built in Rust and runs on the BEAM VM which is built in Erlang. So writing gleam is really just running Rust on the BEAM VM
@IsaacHarrisHolt was thinking more of the huge performance loss.from pretending to be dynamic Like as far as I know the VM still has to check types even tho it's static. This could have been avoided
What do you say to people who argue that through tools like SQLx and Axum Rust has made CRUD-level back-end development as easy as any other language but with the additional benefits of speed, safety, etc?
They've made certain parts of backend development easy, for sure, but they don't really address the other issues with using Rust for that purpose. My point wasn't that Rust is necessarily massively difficult to use for these things, but it does take longer to write and doesn't have lots of the primitives you need to do it in the best way possible
I can totally see recommending Gleam to most people for small projects, but it hasn't had the time to have the same kind of library ecosystem that Rust has. I think that'll change as the time passes. I say that with the use of Erlang/Elixir libraries in mind as well. Take working with databases, for example, still not super easy in Gleam. It's gotten pretty good recently, but not great. There are still things that are missing, which I'm sure will improve with time. After all, Gleam is much simpler than Rust when it comes to writing high level code since you don't have to think about ownership or lifetimes which make Rust hard. Tail call elimination by default is also a very nice in Gleam. In Rust, it's still not super easy to know when it happens and when it doesn't. I look forward to Gleam growing as a language. BEAM is a very nice language, and I think with Gleam's type system on BEAM, we're only scratching the surface of what's possible.
I find it hard to grasp how you can recommend that someone uses Go for SaaS backend development given lack of ADTs, pattern matching etc. Why not just use Gleam instead then? Gleam == Rust > Go for this use case imo.
I don't agree that Gleam == Rust. And while ADTs are great, in Rust's case, with everything else, they really slow you down. Go's approach is different but allows you to move a lot faster
@@IsaacHarrisHolt I disagree. Defining data structures that model reality is an enormous part of software engineering. Golang’s lack of tagged unions (enums) forces a developer to model their data differently, meaning the code is less like reality, resulting in poorer quality code due to increased mental overhead for the developer to match the code to the real-world problem.
I agree that not having tagged unions is a pain point in Go, but even using ADTs you end up having to do a bit of type gymnastics to perfectly model reality - sadly the real world isn't as simple as sum and product types. What Go and its type system give you is a great deal of flexibility without getting in your way. I don't find that there's this mental overhead you mentioned.
@@IsaacHarrisHolt I’m very familiar with Go. I don’t feel its type system gives much flexibility at all. I feel it’s extremely shallow. Looks like we’ll have to agree to disagree 🤷♂️
I came into Rust because of my Erlang experience. That's why Rust sparked my interest at all, not my C/C++ experience. I.e. Rust adds some Erlang like capabilities that I care about a lot for. What it adds to C/C++ is significant, but I don't care that much about it. So yes I will always compare Gleam to Rust. That and the obvious wasm context.
Not to invalidate your experience, but I do think you're missing the point. Sure, you can come from Erlang to Rust and sure, Rust may have some Erlang-y features, and sure, you may want to choose to spend your time on only one of Gleam or Rust - that's fair - but what I'm trying to say is that the languages aren't comparable. Lots of people seem to think that because they look the same, they can be used for the same things, which is not the case.
@@IsaacHarrisHolt let me rephrase my comment. The only reason I'd even look at Gleam is if it was a Rust like Erlang. By definition that means I would compare them. JS like Erlang is a shit proposition, though a lot of big corps may fall for that.
As someone who loves rust, gleam for webservers is the way I want to go. My one hold up is I'm waiting for better MongoDB, or other no-sql variant to have more support. I'm just a no-sql fanboy over sql.
i don't like go because i find that in its pursuit to make things simple it becomes very complex. gleam has a middle ground which i think is a lot better. ideally i would prefer gleam as my backend language. although i think rust is superior in the fullstack/wasm area with technologies such as leptos and dioxus. with a javascript framework i think a gleam backend makes more sense for most scenarios. gleam is simply too limited as a language for fullstack development. rust is able to achieve a seamless experience on fullstack through metaprogramming.
I disagree with your last point. Gleam is great for full stack stuff. You get type safety across the board while also being able to use JavaScript and not rely on WASM awkwardness. There's more boilerplate with Gleam, but that's a good thing - at least you can see what's going on. Have you ever tried to debug a Rust macro?
@@IsaacHarrisHolt there's a difference between a random macro and the framework macro that everything is built around. not to say that it can't break, but it's far less likely. i've never had issues with the macros in those frameworks. there is nothing new or unique to the idea of metaprogramming in frontend. that is how all of the javascript frameworks are built. the main difference is that it's not baked into the language like it is in rust. there's also different levels to boilerplate in how much is good and how much is bad. obviously a lot of that is subjective, but i've used a lot of different frameworks, and i think many people would agree with me that gleam for frontend has too much boilerplate. if gleam had metaprogramming this could all be solved and it would be great. again, that is not some new concept that rust introduced.
I'm not saying Rust invented macros or metaprogramming - you used Rust as an example, so I merely followed your lead. Frontend Gleam itself has very little boilerplate. In fact, it's generally a lot simpler than React applications (for example). It's just a different syntax.
@@IsaacHarrisHolt there is objectively more boilerplate because there is always a model, message, update, and view. look at the difference of code required in a simple counter example. now imagine how much code is required with a lot of complex state. it's night and day. those are old patterns that have existed long before gleam and the javascript community decided against it. the react hooks pattern was built off of what we learned from the past and currently makes the most sense. unless there is something new or innovative, it makes sense to continue building off of established modern patterns.
@@IsaacHarrisHolt i think a swiftui pattern would make more sense for gleam. no metaprogramming required. there are some proof of concepts in other languages for gui's but none for the web that i've seen.
"More a case of shared inspiration than shared goals" Nope. I assure you that any language which introduces algebraic data types is most certainly pursuing a shared goal of allowing the programmer to eliminate classes of errors at compile time.
Rewrite it in Rust is absolutely a good thing, because it is about rewriting critical things in Rust, like OS things, and basic libraries. Writing a backend in Rust is irrelevant to this. Also, the argument about complexity when writing a backend is way overblown. Like in every language, you are not likely to write a server from scratch. You will use a framework. And Rust has perfectly usable frameworks to do this job. I mean, have you ever seen the code for Spring framework for example? It is totally hard to navigate, and you will not write code like this 99,99% of the time. Likewise, you will not meet this complexity that you are talking about. Very, VERY tired arguments at this point.
Agree that rewriting critical infra in Rust is great, and the frameworks do make things easier. My point is that you could achieve the same result faster with other languages, making Rust totally overkill.
@@IsaacHarrisHolt I still disagree. You can totally move fast in Rust, and the language gives you tools to do exactly that, while giving you ways to dig deeper afterwards. If you are already proficient in the language, you might also be able to skip the crutches, and write performant code right away. In any case, as you said in the video, it is totally worth learning Rust. What I disagree with is that you can use it for whatever you want, especially if you find it enjoyable to write (which many people do). If you don't find it enjoyable, you are absolutely free to write in another language, but the arguments against are feeble. Enjoyability is subjective, anyways. Only one arguments against is actually serious: trying to convert an already existing memory safe codebase which many people work on. On the other hand, it is absolutely useful to try to convert C/C++ codebases to Rust, anyone who doesn't see this is just hating.
Fair enough, but as you mentioned, someone proficient in Rust can move quickly. I agree - my argument in the video is that it takes much longer to become proficient in Rust than it does in Go or Gleam, meaning it'll be harder to onboard new team members, harder to find talent, etc.
@@IsaacHarrisHolt That's cute. Still you are selling misconception that Rust is some "special language" for "special rare purposes", when opposite is true. Rust is very much general purpose like no other language out there now, and most people working in it, in different areas, generally have nice things to say about it. Is it harder to learn? Yes. But it is hard because it doesn't hide ugly truths. Still miles easier than C++, so it's not that hard either like youtubers like to harp about it.
I'm not saying Rust is for rare purposes. I'm saying there are generally more productive alternatives for most of the work people watching my channel are going to do. I wouldn't want to write an OS in Gleam any more than I'd want to write a distributed service in Rust. The concept of a "general purpose" programming language is inherently flawed - there's no programming language that will be able to do everything well. Ultimately, sure, every Turing-complete language with the ability to manipulate bits can do everything, but that doesn't mean they should be applied to every use case. And Rust being hard is fine - the tradeoffs it makes are necessary for the stuff it was designed for and the philosophy it follows - but damn does it make simple things a lot more complicated than they need to be.
@@IsaacHarrisHolt When I say general purpose I don't mean "one programming language to rule them all", what I mean is good, solid, viable option for the task. And Rust is that in many areas and it is getting better over time. Productivity is relative, most people would be more productive in Go for web services, but I would be in Rust, simply because I'm more familiar with Rust than Go. And Rust really is surprisingly productive once you learn it enough. Obviously for distributed services can't compete with anything that lies on top of BEAM, but for anything heavily concurrent and multi threaded I would not even consider anything else. On the other note, if you are only doing web front end and nothing else, you will most likely be in JS/TS world. There is integration with other languages as well. Rust works with Python really well for example, with JS also. Anyone half serious about programming should know more than one language anyway. It is just so tiring to see people who don't know Rust and proclaiming it to be this "ultra hard language in which you struggle to do anything". BTW, what are those simple things that Rust makes complicated in your experience? Besides linked lists, which are rarely used in real world projects anyway.
@@IsaacHarrisHolt well, in all seriousness, there are a bunch of things: 1. Nim has multiple memory management models. GC (with bunch of very efficient models like ARC and ORC that you can pick) or no GC. You as the programmer get to chose based on your needs 2. No function coloring when writing async code, kinda like Go 3. clean and elegant syntax. You can really pick it up in an afternoon 4. No VM 5. Nim code can emit C, C++ and JS, this way you can have one language for both front and backend development 6. Extremely fast and efficient (it beats some of our Rust-based applications at work, so we migrated some of them already) 7. very good cross compilation support (not as good as Go but it is very close) 8. Tiny binary sizes, we are talking KBs not even MBs 9. You can use existing C and C++ libraries easily in Nim 10. You can easily create Python modules in Nim and import them in Python in just like 4 lines of code These are just a few of the many positives about Nim. I personally code in Python, Go, Rust and Nim for work and personal projects and when writing Nim, I am the most productive. Just give it a chance, you will not regret it. The only problem with Nim (and Gleam) is it does not have a huge community but hopefully that will change.
@@IsaacHarrisHolt "As a community, we want to be friendly too. People from around the world, of all backgrounds, genders, and experience levels are welcome and respected equally. See our community code of conduct for more. Black lives matter. Trans rights are human rights. No nazi bullsh*t." ... from this bs already u know what kind of people behind this lang, toy language basicly.. even their political bs message is exclusion ... they sayu all backgrounds, and in the same sentence exclude nazis ... lol i mean i wont never trust a language, who lacks even basic logic ; ) that political nonsense makes sure only people who will use this is maybe americans ... noone in the world will support a language, wich is political and promotes communism .. just saying, even haskell has more chances to become mainstream language, than gleam ; ) ))
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Rust is all about control. It's a programming language designed to give you the most ergonomic possible access to the lowest level primitives. If you're a web developer and you've never asked yourself "Should I use Message Passing or a Mutex here?", you probably shouldn't be using Rust.
I don't disagree! But that's not what Gleam is for, so the comparison just doesn't make sense.
@@IsaacHarrisHolt I'm pretty sure that was his point...
Maybe I'm an idiot 😅
@@IsaacHarrisHoltI don’t know, you seem alright to me
Designed for the most ergonomic possible access to lower level primitives?
Maybe designed for the safest way to access low level primitives, but ergonomics are far from Rusts priorities IMO. Rust is very very complex
You're absolute right. Rust it's like F1 car; there is a lot of things were it's the best vehicle, but it's not an everyday car.
Absolutely. It's very fast and very efficient, but boy can it be uncomfortable
Clearly a skill issue. Plus they can’t steal your car because you can take your steering wheel with you.
@@IsaacHarrisHolt Hey, I’m the author of the Packt book Rust and Web Programming and I’m also writing the O’Reilly book on async Rust. Skill does inhibit productivity in Rust, but when the developer gets past a certain skillset, then Rust gets really productive and flexible. For my web systems, using Rust, I write less code than when I was coding web servers in Python. With just a change of one line, I can swap out databases, hook my API endpoint up to a unit testing harness. I can compile all my servers and JavaScript frontend into one binary, or burst it out into microservices. For async, if you just use the async functions, then all the traits are auto-implemented for you and the compiler will check that everything you pass in can be passed over threads. You want more control over your async traits? Then implement the future trait. The strong type system in rust combined with traits enables you to directly interact with third partly libs on a whole other level. On top of this, because of the lack of garbage collection, I can embed my Rust code into Redis, NGINX, Postgres etc, and WASM support is amazing. I’ve open sourced the code for the 3rd edition of Rust and web programming. If you want me to go through the code with you, email me at maxwellflitton@gmail.com
Best analogy ever!!! hahaha
You can ride F1 cars on it only on the track. You will be banned if you try to ride on city roads. The same with Rust
It's very rare to watch a video about a specific technology and agree with every word said in it, but here we are, you took the words out of my mouth
I'm glad we agree! Even the unpopular opinion 😂
Sometimes I dream of a garbage collected mode for Rust that can use standard Rust ecosystem but when you write, all references are ref counted and you just don't care about lifetimes.
You would need some kind of runtime for that, no?
Sounds like Gleam to me... (sarcasm)
@@IsaacHarrisHolt I will explore it sometime in the future, I promise
Sounds like you want Rc's and RefCells!
@@loganhodgsn kind of, more like Rc and multi threaded promoted to Arc and Mutex at compile time, idk
Someone needs to make this kind of video but for Rust vs Zig instead.
Fair, but the Venn diagram there DOES overlap
All subpar languages when compared to the lords language - C#
@@Kane0123 lmfao
Please don't.
@@Kane0123 I think you've misspelled Holy C.
Great video, thanks. It's a bit sad that it was needed, though 😢
I'm one of many who are hopeful about the "native" backend for Gleam, so we could get rid of Go as a "middle ground" option 🙏
It's definitely on the cards!
Don't you dare touch go. It's amazing.
I recently did a full stack web development project completely in Rust for a university course and yes, it was very time consuming and difficult. I love Rust, but I would recommend a simpler and more specific language if developing prototypes or with hard deadlines. That said, the performance was noticing better than projects I have created in Django.
Interesting. Let me know how you get on with Gleam!
"Rewrite it in Rust" is 90% of the times just the Javascript PTSD taking place in the mind 😅.... "even then you should use GO" is a hard truth to swallow and thanks for saying that out loud! Great vid!!!
Thank you!
Discord replaced their Go with Rust.
If rust was a panaceum, gleam team wouldn't even try writing the compiler for their language in an already "perfect" one. They both have their use cases.
Absolutely. My argument is just that those use cases are generally quite separate.
Rust has no use case, if you must write systems code, use c++.. unless you need to write a library, or the lowest level stuff, then use C. If you need something safe, write it in C#, everyone loves it and it's very productive. There is nothing that must be written in a systems language, yet also has safety an even higher design priority. Gleem might have a use case, Rust doesn't.
@@cyberpunkspike
No need for safety in a systems language?
Over half of all CVEs are memory vulnerabilities.
Write your libraries in C? Remember that heartbleed was caused by a missing bounds check in a C library.
@antonf.9278 Reading isn't a strong point for Rust degenerates, I know... Security isn't the highest design priority, doesn't matter if you think it should be, it isn't. If you need systems level code, you end up writing large amounts of unsafe Rust, otherwise you didn't need to write systems code in the first place.
Just a pet peeve of mine, but I hate the phrase "don't compare...".
Why not?
What is this video if not comparing those two languages?
By all means compare them, just be mindful that the differences do not end on few simple characteristics.
If you compare soley on speed for example, only then you are making a mistake.
And of course this extends to other things "comparing apples to oranges", "don't compare my actions to this person's" etc.
I think comparisons like ‘Rust vs. Gleam’ aren’t very interesting because they usually focus only on syntax. If you want a more in-depth comparison, you need to include something similar to the BEAM, as it’s a core part of Gleam on the backend. Rust has some comparable libraries like Bastion (though it’s outdated) and Lunatic. Alternatively, you could compare Gleam’s actor model with Rust and Actix's actor model
My whole point is not to compare these things because the comparisons don't make sense. This video is simply pointing out why
@@IsaacHarrisHolt I understand your point. My issue is only with semantics.
It's just a pet peeve, do not pay it your mind. It's like when people use "literally" when that's not what they mean.
One day I would like to see a thorough comparison between Gleam and Elixir since they are very similar in a lot of ways and the biggest differences I know of would be static typing and syntax. But I don't know too much about Elixir (I use it for personal projects but I am not an expert) and I know nothing about Gleam (except for a the view videos from Isaac I have watched)
The reason is because so far I haven't seen anything from Gleam that would make me choose it over Elixir. But a side by side comparison might shed better light on a few things.
Totally agree. This has annoyed me on so many topics.
A common one is claiming you "can't compare an editor vs IDE"...
Well we're all deciding between the 2 options, and usually don't need both at once... So how to pick? That's what a comparison is. They don't have to be exactly the same thing in every single facet. If they were... There wouldn't really be anything to compare anyway.
Maybe they "can't"... But they're confusing their lack of thinking and reasoning abilities with mine. I'm quite capable.
> Not Rust
> Looks inside source code
> Rust
😮
Gleam isn’t rust in the same way that python isn’t C
@@andrewhennis1786
> Looks inside source code
> It's just C bindings
Good luck finding any Rust bindings in Gleam...
@@IsaacHarrisHolt ?!?
Gleam doesn't bind to Rust. The compiler is written in Rust, sure, but the compiler has to be written in SOMETHING
What I find hard for now with Gleam is its standard library. You can't even build a simple web server simply, you need to use a package for that, and it's pretty uncommon and a lot different because it uses the actor model.
Also, there is no official doc on how to use concurrency, it's not clear, I can't find anything on the site that talks about that. There is nothing like the "goroutines" to build concurrent programs.
I know that there is a package to build concurrent programs, but it's not clear on how to use it.
I think that's the biggest problem and a huge downside compared to "Go" for example, where everything is straightforward. Saying that you can learn Gleam in an afternoon is not true at all. Learning how to loop and create functions, types and other basic things is obvious in all languages.
I really like the language, I hope it will get the documentation and the support it deserves, If I had the level to deeply understand the concurrency in Gleam, I would've gladly contributed.
I think the standard library is well-equipped. The reason there's no webserver implementation is because Node and Erlang handle webservers very differently, so there's no way to make something that works well across both. Also, it's actually reasonably uncommon for programming languages to provide fully-featured webservers in the standard library - Rust doesn't either afaik.
As for concurrency, again it's because there's big differences in how these things are handled on the BEAM vs on Node. That said, I agree the documentation needs extending a fair bit, and it's why I made a video on the topic ;)
If you want another good resource: github.com/bcpeinhardt/learn_otp_with_gleam
There's nothing hard about using a package. The standard library is a normal package.
Large standard libraries are a relic of a time before we had package management.
Because Gleam is a very young language. Version 1.0 was released in March, 5 months ago.
Everything that you are asking is in an Elixir. There are a lot of books, learning materials, and videos about the language, OTP, and BEAM. Personally, Elixir is the best choice because of the materials.
@infantfrontender6131this is true, but a lot of those resources (and existing Erlang resources) can also be applied to Gleam! The concurrency model is (mostly) the same after all.
@@lpil @IsaacHarrisHolt Thanks a lot for taking the time to answer, thanks for the clarification.
That's what I thought, compiling to JS and Erlang makes certain choices probably harder.
Gleam is in good hands, that's for sure! I'll take time to understand the concurrency in Gleam using the GitHub repo, thanks!
Isaac, thanks for such a great explanation! Let me ask you a question of a developer who likes Elixir (and its great ecosystem) and suffers from lack of strong type system. From your point of view, is Gleam mature enough for production? Can it be considered as a replacement for Elixir (even if not now but in time)? At the moment it seems more like a concept...
Gleam is definitely production ready! There are already companies using it, in fact. I know of one in particular that uses Phoenix LiveView for their front end, but call out to Gleam code to have type safety for their business logic
If you use copilot or codeium for fancy autocomplete with gleam, it will provide rust code 99% of the time. Gleam is a new language that AI hasn’t had time to familiarize themselves with yet. That was my initial reason for comparing gleam to rust. Those few keywords that rust and gleam have in common make it very difficult for copilot to work when in a gleam project.
I tend to find that Copilot's okay once you've written a few lines, but it does sometimes get the syntax mixed up. The same will be true of any sufficiently new language though.
yeah i would expect zig/gleam to not be supported honestly, i'd even turn of supermaven if i was trying out gleam.
Supermaven works well with Gleam, can confirm
Don't use AI. Problem solved.
TL;DR: The purposes of the languages are:
- Rust: Power, memory safety, and performance.
- Gleam: Concurrency, fault tolerance, and ease of learning.
Key differences:
- Rust: Has a steeper learning curve, requiring more effort to master.
- Gleam: Is designed to be easy to learn and write.
- Rust: Runs natively on the machine and manages memory through the borrow checker, leading to better performance and lower memory usage.
- Gleam: Runs on the Erlang VM and uses garbage collection for memory management, which can result in slower performance and higher memory usage.
Pretty much
7minutes 46seconds ain’t that long… who are these people who want to know about cutting edge languages without any time to watch a brief video? Would you have preferred a TikTok or something?
People who want to farm likes on their comments for... some reason. I've seen lots of stuff like this, and I'm convinced at least some of it is AI generated.
FINE. I’ll learn Gleam. This is a wonderful video.
I promise it'll be a good decision ;)
Why not learn Rust instead?
🤦🏻♂️
instant legacy code.
Great video. You have earned yourself a subscribed.
(also style seams very No Boilerplate inspired. Clear & easy to follow.)
Thank you! And yes, Tris is a big inspiration
I wonder if i can integrate gleam with my existing code base. It'd be too much to rewrite in gleam, but would be cool to write some components with gleam
What language is the existing codebase? If it's JS/TS or a BEAM language, probably!
The comparison that would be valid to consider is Gleam vs. Elixir. Both target BEAM, but Gleam is apparently not using all the advantages. Like macros and declarativness
Agreed!
Wait a minute, what kind of nighttime activities do you have where you use a hammer and a corkscrew at the same time?
Uhhh... drunken woodworking?
@IsaacHarrisHolt that is an activity xD
I'd love to see a similar video comparing Gleam to Go. The goals of Gleam you stated in the video are practically exactly the same as the stated goals of Go. Not to mention that Go is a much easier sell to most developers because it's one of the most procedural languages out there and thus it's more friendly to those coming from an old Java background. How do you sell someone on Gleam when Go already exists and is more popular at the moment?
EDIT: and more importantly, what arguments would you use to sell a small development team in a company on Gleam, if any?
Gleam and Go are similar, for sure, but when it comes to building resilient software, the BEAM has a lot of nice things that Go doesn't. For example, Go makes it difficult to detect if a process has crashed (you kinda have to check it manually)
Before this vid I thought my analogies were inane, but you sir take the cake with ease.
How kind, thank you :)
Our backend is built around warp which could potentially be used to serve the gleam application I'm not sure what the value in that would be over just using pure gleam or pure rust. What are your suggestions for incremental adoption of gleam in cases where you're already using rust?
If you're aiming to adopt any language incrementally, the most important thing to do is use a shared set of types for communicating between the services. You could use protobufs, OpenAPI specs, or whatever else you like, but make sure there's a common schema.
Random People saying just use rust as if rust is not as difficult to learn as C++ .
I'd argue that while the language is probably just as complex, Rust's learning resources (the book, etc.) are a lot more accessible (and arguably better) than those for C++. It's hard to know where to start with C++ at least!
@@IsaacHarrisHolt agree on this.
@IsaacHarrisHolt Have to disagree. Yes, it's easier to start with Rust, less complexity when using crates etc. But C++ has a much easier structure.
My point was mostly around documentation, and while Rust is probably more complex than C++ if you're only using modern stuff, the problem is that C++ is so, so bloated that reading C++ code is a bit of a gamble as to whether it'll be using features you're familiar with or not
@@IsaacHarrisHolt A B S O L U T E L Y. I'm currently using C++ and I would do anything to get Rust syntax. Basic simple Rust is really really readable, you do your little .clone(), the match on Result, yadi yada it's all good and simple, whereas basic C++ is already unreadable (and this is coming from someone who's mother tongue is C). But once your start to introduce lifetime annotation sprinkled with some traits, or higher bound trait, and macro than yes both language actively compete for who's going to be the least readable.
I haven't tried gleam at this moment, but I do love Rust. And I agree that you definitely shouldn't use it for all cases. In general I'm slightly annoyed that typically speed is the only reason specified for using Rust. I think Rust is also great for having strong reliability and structure in your code. When that is my goal, my style of writing also makes me avoid issues with lifetimes and generics. If you code strategically it becomes much quicker to write in my experience. Based purely on intuition I'd say it takes about 1.5x the time to write in this style in Rust, with about 4x the time if I optimize for performance. This isn't a proper measurement though, just a gut feeling.
Anyways, definitely agree with you in general.
Fair enough! I think the reliability and structure come from the type system though, especially ADTs. Since Gleam also has those, I don't see it as a particular win for Rust in this particular case.
Also, since you haven't tried Gleam, I can't really put much faith in those 1.5x and 4x numbers. You also sound like you're fairly proficient in Rust, so it makes sense that it's gonna be faster for you to code that than Gleam
@@IsaacHarrisHolt I was mostly comparing to languages I use when iteration speed is my priority, I can't make the comparison to Gleam for obvious reasons. In my experience the borrow checker does have an impact on how I structure my code, or to be more precise avoiding conflict with the borrow checker does. But to be fair it's probably because I tend to over-complicate types by default, so maybe it's just keeping my bad habits in check. But thinking about it now I am getting more interested in looking into Gleam. I'll probably try to pick it up once my schedule clears up.
Anyways, thank you for the useful video and response. I've subscribed and will check out more of your videos later, as I'm getting more interested in Gleam.
Thanks!
Agreed! I don’t really care so much about the *performance* that rust provides… it’s a gigantic benefit of course… I’m much more interested in the reliability aspects.
I quite like that my code doesn’t generate 3AM emergencies. Being able to sleep soundly at night is worth far more than anything.
I also think the video is greatly glossing over the development time aspect…
Yes, it may take longer to write code in Rust (at least until you get good enough at it)… but what you spend on development time is *more* than made up by lack of debugging and chasing runtime errors!
So many folks miss that Rust is able to give you such incredibly reliable software, and focus solely on the “performance” aspect alone…
Again though, that reliability comes mostly from the type system, which is shared with Gleam. Also, Gleam runs on the BEAM, which was also designed for creating reliable software - it's why it exists.
yeah, the use case is absolutely different, but the main reason i'm interested in gleam is because its syntax is familiar to me as someone who learned rust first
It's a fairly standard C-style syntax, but I can see what you mean
As a Rust user, I have to agree the "rewrite it in Rust" movement was definitely a mistake. I think what a lot of people don't understand is that coding languages are entirely situational by definition, as a coding language is just a specific interpretation of abstraction of machine code. Sure, a language like C is technically "general purpose," but how many people are making LLM's in C? How many do you think are writing embedded firmware (not counting the RPi Pico) or system drivers in Python? You know? Rust is great for a lot of reasons, but it's not an end-all-be-all. Nothing really is.
This is a great take. These days we're also seeing more and more specialist programming languages and fewer "general purpose" ones, and I think that's fine!
Alternatively, we see languages like Gleam which can compile to different backends depending on the use case you're targeting.
Currently I’m using Elixir with the Rustler package for FFI when I need to easily use Rust for anything that is performance critical. When we have some of the elixir package equivalents and FFI packages like Rustler in Gleam then I’ll make the switch and see how I like it.
Yeah, I don’t like Elixir’s syntax, I prefer Erlang’s. But I’m waiting on a Rustler for Gleam too to start using some Gleam. I would also love if there was a way to do long lived interop between BEAM processes and Rust/C than NIFs.
You can use any Elixir/Erlang package in Gleam, so you can use NIFs (see the Argus package)
@@IsaacHarrisHolt from what I saw before I had to write a bridge to use elixir packages in gleam and this which seemed very cumbersome and annoying. If there is an easier implementation I’d love to see a video on it!
You have to write an FFI, but it's not particularly complex. And sometimes you just need to create the @external annotation. I have a video on the topic :)
@@IsaacHarrisHolt I’ll check it out. I have a pipeline in broadway with a couple of complex functions I am trying to move over. I’ll see how feasible it is for me.
what about gleam vs go?
There's a lot more overlap here, but generally Go will be higher performance because it's compiled. Gleam's type system is a lot nicer though
@@felipe5195 gleam is functional, go is imperative
I'm rooting for Gleam. The lack of type safety in Erlang and Elixir has always turned me off from using them. I do wish it had gone for a more "traditional" ML syntax instead of the rust style one. It feels like the punctuation is excessive, but that's mostly just personal taste.
Re: using Go -- the problem with Go (that Gleam doesn't have) is that it isn't data race free. In Java, you can only have benign race conditions, in Go race conditions can leave memory and gc data in an incoherent state and thus violate type and memory safety. Uber found thousands of these race conditions when they added thread sanitizer to their workflow once it was available in Go.
This is the kind of bug that is trivially easy to write by accident and that eats up tons and tons of development time. So I've never been inclined to use Go despite it's other benefits. Gleam, by virtue of running on BEAM, just doesn't have this problem. So it's kind of ideal for developing that kind of software.
This is a fair point! Thankfully the -race flag in `go test` etc. helps a lot with this now.
Yeah, you convinced me. After I deploy my current ongoing Node project, I will try to rewrite many of my packages into Gleam, especially the backend ones.
Is there a chance that Gleam to JavaScript will work fine for browser apps? Maybe not yet it probably doesn't have JSX support yet.
Gleam to JS works great for browser! We even have our own frontend framework
Great video -- You should probably also mention the absence of loops in gleam,
That's just par for the course with functional languages
OCaml, Clojure, F#… 🤔
This is amazing, I’ve been interested in Gleam for a while now, I’m in a crossroad between learning Golang and Gleam. A lot of people keep recommending Golang, it’s understandable since Golang is a bit older and more popular but Gleam is really appealing, personally I love Erlang and the Erlang VM(Beam) and am planning to rewrite a TypeScript backend so, do you think Gleam a better alternative to Typescript?
I personally would stay away from JS/TS for the backend, so yes, do it in Gleam! If you can, run it on the Erlang target though - that's much better suited to backend work than the JS target.
@@IsaacHarrisHolt that’s what I thought as well
The hardest part for me to grasp about Gleam is that it targets the BEAM VM... But it's not similar to Erlang, or Elixir. I have some experience in Elixir, but I have to stop myself everytime to just use a dang atom, and create a dang Sum Type...
It'll create much safer code in the long run!
Alternately, you can write your own virtual machine in raw machine code and then rewrite your SaaS application in your custom VM byte code. It is certainly an idea, but less certainly a good one.
Bet
@@IsaacHarrisHolt tbh it sounds like a fun project that would tickle my autism just right, but I have already written two virtual machines, so I should probably leave it alone lol
Hahaha I know the feeling!
Gleam looks really nice! I have worked with Elixir in the past, and liked many things about it. But I also worked with ReasonML, and I prefer its style and type system. Gleam seems to combine the benefits of both. And makes getting into Rust easier because of its similarities in syntax. So you should learn both I guess.
I definitely encourage learning both! You can't contribute to the Gleam compiler without Rust after all 😉
I like the comparison of gleam to go. Peole hate the comparison of gleam to rust and pretty often say that gleam is go, but functional one and honestly I totally get it cuz both languages are really simply-powerful and really productive, but the difference is that gleam is more functional.
Absolutely! Gleam is definitely more of a functional Go than a functional Rust
I love the focus on productivity. In terms of readability I think it doesn't quite reach python, which is a shame.
That's fair, but it's also a completely different programming paradigm.
And there are those who would argue that significant whitespace makes Python harder to read, so it's very subjective
Hello I hope you're fine I was thinking about using gleam on my front end to replace JS is it possible
Yes! Absolutely possible. Take a look at Lustre
The use cases can overlap a good amount, and comparing programming languages is important to understand the differences - that’s the entire point of this video.
Of course they are very different languages though, and use cases don’t overlap too much.
I think people probably misuse Rust a lot of the time sadly. There's a lot it can do, but there's also a lot it probably shouldn't.
@@IsaacHarrisHolt I agree, but there are not a ton of better options which provide the same that rust does with proper sum types and good zero-cost abstraction. But it defintely is annoying to see everything no matter how small or high-level getting rewritten in rust despite not being something that would stand to benefit much from it.
Good job Gleam is here to save the day 😉
@@IsaacHarrisHolt Yess!! Gleam is so good for so much!
If i was so amateur that my brain only knowing html and css, can i learn gleam as my mother language?
Yes! Gleam is very easy to pick up. I recommend going through the Gleam Tour
You showed Kotlin in your video a language which often gets forgotten about. Does gleam have any influences from it? Kotlin has compose which let's you build gui very simply I could make an app without really reading about compose.
I don't know if Gleam has taken anything from Kotlin, to be honest. I'm not massively familiar with the language myself. Gleam's inspirations are mostly ML languages
At least getting into Gleam exposes you to the Erlang VM and encourages you to dig deeper.
Getting up to speed with OTP is one of the best things you can do to become a better architect - even if you never write a single line of Erlang.
On the negative side - Gleam is riding on the back of Rust’s current “popularity”, which could easily crash and burn as quickly as it appeared.
As long as you don’t go tieing your identity to your tools, you should get something positive out of it
I don't agree that Gleam is in any way riding Rust's coat-tails. What makes you say that?
Hold up I would love to circle back to the night time activities involving a hammer/corkscrew, have I been doing things wrong for all these years?
I can neither confirm nor deny
Everything you said seems really reasonable. If Rust is the new C/++ then Gleam seems like it could be the new Java.
It's more like the new Erlang. Java, again, has different design goals and goes quite heavily on OOP, whereas Gleam is functional.
What about Gleam vs Elixir, since Elixir introduces "gradually static typing"? ;)
Elixir is gonna have to do what TS did and stick a type system on top of an existing dynamic language with all its quirks. It'll never have guarantees as strong as Gleam's
Nice video Isaac ❤
Thanks :)
Gleam vs Go when?
Probably not going to happen I'm afraid
Nice vid!!
Thank you thank you!
"Stop Comparing Rust To Gleam"
That's not how the internet works. Now they're going to compare them. lmao.
Interested in beam langs,. still don't really have a project for one, i just reach for Go for most things. but beam langs just make a lot of sense in chat and other similar type of projects. maybe handling a lot of inbound data points like weather, markets, etc.
Oh I'm well aware that the internet will do whatever it likes regardless of what I think 😂 Just wanted to make this video for me to link to when people bring it up in the future!
Also, you're right about that being a good use for BEAM langs. Take a look at the Waterpark project, which was written in Erlang (there are good talks here on YT). Fascinating stuff.
@@IsaacHarrisHoltoh yeah. i'll check it out. I remember learning about erlang after watching a strange loop video and then diving deep into whatsapp's use of it. the video of the 1 server running at half capacity, but having like 3M concurrent convos is insane/
Honestly the BEAM is crazy. Sasa Juric's talks are great too
@@IsaacHarrisHolt any good web frameworks? might spin out an overengineered blog lmao.
i'll need to dive into all the videos and just stumble through it.
nvm just found your videos on it!
Gleam syntax reminds me Swift language
Oh interesting! I'd say Gleam and Swift are pretty different. I've not used Swift extensively, but I've heard good things.
It doesn't matter if the languages are targetting different goals. There is a lot to learn from every language. To try and stifle discussion about it is moronic at best and leads to situations like the Linux community being full of people like Theodore Ts'o who see interacting with another language as an attack on their identity and skills.
Actors is one of my favorite concurrency models to implement. It's ergonomic as hell, and I would have never started doing it without being able to discuss what erlang and elixir did differently from the languages I use.
Languages being different is a good thing, and we should be allowed to discuss their differences.
I'm not trying to stifle discussion, I'm trying to make sure people aren't trying to decide whether they use Gleam or Rust for a particular project
@@IsaacHarrisHolt the video sounded more on the side of preventing the comparisons at all. Though I do agree that you should know which to choose in which scenario. Even though I'm not a fan of gleam (not a fan of complete immutability mainly) I still would rather someone pick that if they're just making a simple crud app and their only concern is speed of development and deployment.
Rather than the hammer comparison I'd say more like Rust is a swiss army knife in a lockbox, it can do everything you need to if you're planning to do a big project with a lot of different requirements, but it's going to be way slower than just grabbing the screwdriver from the drawer
Omg! You can declare variables in this language it must be the same as this other language!
- People who said Rust = Gleam
Yeppp that about sums it up 😅
Now do Elixir vs. Gleam. Both are Erlang based languages.
Yes, that is a valid comparison. However, I don't think it's one I'm gonna make. I mostly made this video to stop the comparisons.
well done!
Thanks!
still waiting for gleam to be a part of linux kelner :3
We'll get there 😉
Glean looks like simplified rust with garbage collection. But I will pass because no traits mean you have to hunt for all the functions like in python instead of just using a dot.
You can just read the documentation
If you assume Gleam needs traits you again just directly compare two fundamentally different languages. Not sure how Gleam does it but even in Rust you can often fully replace a trait with an enum and it's just as simple to call the method.
Thank you! Great Video!
Glad you liked it!
2:00 so true (zorua best)
Absolutely!
They are fundamentally different and are not even comparable. For example, if you target bare-metal embedded system, an Erlang runtime is nearly impossible, while Rust is perfectly fine. Also they have very different ways to define and deal with ABIs. It’s not just the syntax.
Yep! Agreed
I feel like technically gleam is ONLY Erlang and Rust xD
I'm not sure I see your reasoning here
@@IsaacHarrisHolt There entire language is built in Rust and runs on the BEAM VM which is built in Erlang. So writing gleam is really just running Rust on the BEAM VM
I mean, not quite 😅 you're not running Rust. It's just the compiler that's written in Rust. And it also compiles to JS!
@@IsaacHarrisHolt Okay yeah that’s fair. Compiling to JS (although extremely useful) is such a hilarious concept to me.
It makes a lot of sense here, and Gleam manages to do a lot with it
Thanks for sharing! Even if I didn't need it. ✌️
You're welcome!
Gleam is great!
Yes!
Gleam is not Rust
Elixir is not Ruby
Someone gets it
What's very weird with gleam is that it's statically typed but its vm isnt
True, but you only need static types at compile time anyway
@IsaacHarrisHolt was thinking more of the huge performance loss.from pretending to be dynamic
Like as far as I know the VM still has to check types even tho it's static. This could have been avoided
Fair. Gleam native won't have this problem, when it happens
@IsaacHarrisHolt we just need a statistically typed beam and it would be nicer
Why not just use machine code?
Good question! Gonna go rewrite it in Binary
What do you say to people who argue that through tools like SQLx and Axum Rust has made CRUD-level back-end development as easy as any other language but with the additional benefits of speed, safety, etc?
They've made certain parts of backend development easy, for sure, but they don't really address the other issues with using Rust for that purpose. My point wasn't that Rust is necessarily massively difficult to use for these things, but it does take longer to write and doesn't have lots of the primitives you need to do it in the best way possible
I can totally see recommending Gleam to most people for small projects, but it hasn't had the time to have the same kind of library ecosystem that Rust has. I think that'll change as the time passes.
I say that with the use of Erlang/Elixir libraries in mind as well. Take working with databases, for example, still not super easy in Gleam. It's gotten pretty good recently, but not great.
There are still things that are missing, which I'm sure will improve with time. After all, Gleam is much simpler than Rust when it comes to writing high level code since you don't have to think about ownership or lifetimes which make Rust hard. Tail call elimination by default is also a very nice in Gleam. In Rust, it's still not super easy to know when it happens and when it doesn't.
I look forward to Gleam growing as a language. BEAM is a very nice language, and I think with Gleam's type system on BEAM, we're only scratching the surface of what's possible.
Working with databases has recently become much easier thanks to the Squirrel library!
@@IsaacHarrisHolt Perhaps make a video about the gleam web ecosystem: sql, kafka, elastic search, jwt... etc. What is working well? What is missing?
0:38 huh
😉
You’ll get there Louis
Okay but hear me out
Gopher
I do mention Go in the video 😉
I find it hard to grasp how you can recommend that someone uses Go for SaaS backend development given lack of ADTs, pattern matching etc. Why not just use Gleam instead then? Gleam == Rust > Go for this use case imo.
I don't agree that Gleam == Rust.
And while ADTs are great, in Rust's case, with everything else, they really slow you down. Go's approach is different but allows you to move a lot faster
@@IsaacHarrisHolt I disagree. Defining data structures that model reality is an enormous part of software engineering. Golang’s lack of tagged unions (enums) forces a developer to model their data differently, meaning the code is less like reality, resulting in poorer quality code due to increased mental overhead for the developer to match the code to the real-world problem.
I agree that not having tagged unions is a pain point in Go, but even using ADTs you end up having to do a bit of type gymnastics to perfectly model reality - sadly the real world isn't as simple as sum and product types.
What Go and its type system give you is a great deal of flexibility without getting in your way. I don't find that there's this mental overhead you mentioned.
@@IsaacHarrisHolt I’m very familiar with Go. I don’t feel its type system gives much flexibility at all. I feel it’s extremely shallow. Looks like we’ll have to agree to disagree 🤷♂️
@@liamwoodleigh no worries! Glad we could have a civil conversation :)
I came into Rust because of my Erlang experience. That's why Rust sparked my interest at all, not my C/C++ experience. I.e. Rust adds some Erlang like capabilities that I care about a lot for. What it adds to C/C++ is significant, but I don't care that much about it.
So yes I will always compare Gleam to Rust. That and the obvious wasm context.
Not to invalidate your experience, but I do think you're missing the point. Sure, you can come from Erlang to Rust and sure, Rust may have some Erlang-y features, and sure, you may want to choose to spend your time on only one of Gleam or Rust - that's fair - but what I'm trying to say is that the languages aren't comparable. Lots of people seem to think that because they look the same, they can be used for the same things, which is not the case.
@@IsaacHarrisHolt let me rephrase my comment. The only reason I'd even look at Gleam is if it was a Rust like Erlang. By definition that means I would compare them. JS like Erlang is a shit proposition, though a lot of big corps may fall for that.
As someone who loves rust, gleam for webservers is the way I want to go. My one hold up is I'm waiting for better MongoDB, or other no-sql variant to have more support. I'm just a no-sql fanboy over sql.
Totally fair! But you should just use Postgres 😉
Gleam is clean
💯
i don't like go because i find that in its pursuit to make things simple it becomes very complex. gleam has a middle ground which i think is a lot better. ideally i would prefer gleam as my backend language. although i think rust is superior in the fullstack/wasm area with technologies such as leptos and dioxus. with a javascript framework i think a gleam backend makes more sense for most scenarios. gleam is simply too limited as a language for fullstack development. rust is able to achieve a seamless experience on fullstack through metaprogramming.
I disagree with your last point. Gleam is great for full stack stuff. You get type safety across the board while also being able to use JavaScript and not rely on WASM awkwardness.
There's more boilerplate with Gleam, but that's a good thing - at least you can see what's going on. Have you ever tried to debug a Rust macro?
@@IsaacHarrisHolt there's a difference between a random macro and the framework macro that everything is built around. not to say that it can't break, but it's far less likely. i've never had issues with the macros in those frameworks. there is nothing new or unique to the idea of metaprogramming in frontend. that is how all of the javascript frameworks are built. the main difference is that it's not baked into the language like it is in rust. there's also different levels to boilerplate in how much is good and how much is bad. obviously a lot of that is subjective, but i've used a lot of different frameworks, and i think many people would agree with me that gleam for frontend has too much boilerplate. if gleam had metaprogramming this could all be solved and it would be great. again, that is not some new concept that rust introduced.
I'm not saying Rust invented macros or metaprogramming - you used Rust as an example, so I merely followed your lead.
Frontend Gleam itself has very little boilerplate. In fact, it's generally a lot simpler than React applications (for example). It's just a different syntax.
@@IsaacHarrisHolt there is objectively more boilerplate because there is always a model, message, update, and view. look at the difference of code required in a simple counter example. now imagine how much code is required with a lot of complex state. it's night and day. those are old patterns that have existed long before gleam and the javascript community decided against it. the react hooks pattern was built off of what we learned from the past and currently makes the most sense. unless there is something new or innovative, it makes sense to continue building off of established modern patterns.
@@IsaacHarrisHolt i think a swiftui pattern would make more sense for gleam. no metaprogramming required. there are some proof of concepts in other languages for gui's but none for the web that i've seen.
Do you think anyone has a life and no time to learn 1000 programming languages?
If you're watching my channel, then probably not 😉
Gleam is the child of rust instead 😂 jk
Hahah I mean, there was probably some inspiration
"More a case of shared inspiration than shared goals"
Nope.
I assure you that any language which introduces algebraic data types is most certainly pursuing a shared goal of allowing the programmer to eliminate classes of errors at compile time.
Okay, fair point, but that's not what I was trying to get across here.
Rewrite it in Rust is absolutely a good thing, because it is about rewriting critical things in Rust, like OS things, and basic libraries.
Writing a backend in Rust is irrelevant to this.
Also, the argument about complexity when writing a backend is way overblown. Like in every language, you are not likely to write a server from scratch. You will use a framework. And Rust has perfectly usable frameworks to do this job. I mean, have you ever seen the code for Spring framework for example? It is totally hard to navigate, and you will not write code like this 99,99% of the time. Likewise, you will not meet this complexity that you are talking about.
Very, VERY tired arguments at this point.
Agree that rewriting critical infra in Rust is great, and the frameworks do make things easier.
My point is that you could achieve the same result faster with other languages, making Rust totally overkill.
@@IsaacHarrisHolt I still disagree. You can totally move fast in Rust, and the language gives you tools to do exactly that, while giving you ways to dig deeper afterwards. If you are already proficient in the language, you might also be able to skip the crutches, and write performant code right away.
In any case, as you said in the video, it is totally worth learning Rust. What I disagree with is that you can use it for whatever you want, especially if you find it enjoyable to write (which many people do). If you don't find it enjoyable, you are absolutely free to write in another language, but the arguments against are feeble. Enjoyability is subjective, anyways.
Only one arguments against is actually serious: trying to convert an already existing memory safe codebase which many people work on.
On the other hand, it is absolutely useful to try to convert C/C++ codebases to Rust, anyone who doesn't see this is just hating.
Fair enough, but as you mentioned, someone proficient in Rust can move quickly. I agree - my argument in the video is that it takes much longer to become proficient in Rust than it does in Go or Gleam, meaning it'll be harder to onboard new team members, harder to find talent, etc.
"its incredibly hard to do large scale refactors"
oh but thats where youre wrong
Please, sir, add a 'a lifetime to a type that you use everywhere and come back to me.
Rust is the best general purpose language out there at this moment. Your analogy is just dumb. Seems like you are coping with skill issues.
I'm just not wearing Rust-tinted glasses 😉
@@IsaacHarrisHolt That's cute. Still you are selling misconception that Rust is some "special language" for "special rare purposes", when opposite is true.
Rust is very much general purpose like no other language out there now, and most people working in it, in different areas, generally have nice things to say about it.
Is it harder to learn? Yes. But it is hard because it doesn't hide ugly truths.
Still miles easier than C++, so it's not that hard either like youtubers like to harp about it.
I'm not saying Rust is for rare purposes. I'm saying there are generally more productive alternatives for most of the work people watching my channel are going to do.
I wouldn't want to write an OS in Gleam any more than I'd want to write a distributed service in Rust.
The concept of a "general purpose" programming language is inherently flawed - there's no programming language that will be able to do everything well. Ultimately, sure, every Turing-complete language with the ability to manipulate bits can do everything, but that doesn't mean they should be applied to every use case.
And Rust being hard is fine - the tradeoffs it makes are necessary for the stuff it was designed for and the philosophy it follows - but damn does it make simple things a lot more complicated than they need to be.
@@IsaacHarrisHolt When I say general purpose I don't mean "one programming language to rule them all", what I mean is good, solid, viable option for the task.
And Rust is that in many areas and it is getting better over time.
Productivity is relative, most people would be more productive in Go for web services, but I would be in Rust, simply because I'm more familiar with Rust than Go.
And Rust really is surprisingly productive once you learn it enough.
Obviously for distributed services can't compete with anything that lies on top of BEAM, but for anything heavily concurrent and multi threaded I would not even consider anything else.
On the other note, if you are only doing web front end and nothing else, you will most likely be in JS/TS world.
There is integration with other languages as well. Rust works with Python really well for example, with JS also.
Anyone half serious about programming should know more than one language anyway.
It is just so tiring to see people who don't know Rust and proclaiming it to be this "ultra hard language in which you struggle to do anything".
BTW, what are those simple things that Rust makes complicated in your experience?
Besides linked lists, which are rarely used in real world projects anyway.
No Rust no Gleam, Nim is the way :P
Oooh controversial. Sell me on why 👀
@@IsaacHarrisHolt well, in all seriousness, there are a bunch of things:
1. Nim has multiple memory management models. GC (with bunch of very efficient models like ARC and ORC that you can pick) or no GC. You as the programmer get to chose based on your needs
2. No function coloring when writing async code, kinda like Go
3. clean and elegant syntax. You can really pick it up in an afternoon
4. No VM
5. Nim code can emit C, C++ and JS, this way you can have one language for both front and backend development
6. Extremely fast and efficient (it beats some of our Rust-based applications at work, so we migrated some of them already)
7. very good cross compilation support (not as good as Go but it is very close)
8. Tiny binary sizes, we are talking KBs not even MBs
9. You can use existing C and C++ libraries easily in Nim
10. You can easily create Python modules in Nim and import them in Python in just like 4 lines of code
These are just a few of the many positives about Nim. I personally code in Python, Go, Rust and Nim for work and personal projects and when writing Nim, I am the most productive.
Just give it a chance, you will not regret it. The only problem with Nim (and Gleam) is it does not have a huge community but hopefully that will change.
I've used Nim before! ruclips.net/video/Bo7lXrqaaIc/видео.htmlsi=S4NmnN0PcB-3b6yt
But this is interesting. I'm all in on Gleam at the moment though ;)
@@IsaacHarrisHolt Yes, I remember. That is why I subscribed :))
Ah cool!
Creating new languages in 2024 should be fined 10 million dollars.
Good job both Gleam and Rust were created before 2024 then!
gleam is more like higher-level elixir/erlang
With static types! It's no higher- or lower-level than either - they all compile to the same thing ultimately
@@IsaacHarrisHolt "As a community, we want to be friendly too. People from around the world, of all backgrounds, genders, and experience levels are welcome and respected equally. See our community code of conduct for more.
Black lives matter. Trans rights are human rights. No nazi bullsh*t."
... from this bs already u know what kind of people behind this lang, toy language basicly.. even their political bs message is exclusion ... they sayu all backgrounds, and in the same sentence exclude nazis ... lol
i mean i wont never trust a language, who lacks even basic logic ; )
that political nonsense makes sure only people who will use this is maybe americans ...
noone in the world will support a language, wich is political and promotes communism
.. just saying, even haskell has more chances to become mainstream language, than gleam ; ) ))