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
"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!!!
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 🙏
@@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
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.
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.
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.
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.
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!
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.
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.
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
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.
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.
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.
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.
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
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...
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.
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
Which Gleam projects have scaled to thousands of lines of code? Moreover, which of those non-existent projects have existed long enough to be refactored?
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
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
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
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.
"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.
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.
"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.
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
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
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 🤷♂️
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.
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.
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.
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.
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
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.
@@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.
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)
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.
@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
@@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 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! ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Bo7lXrqaaIc.htmlsi=S4NmnN0PcB-3b6yt But this is interesting. I'm all in on Gleam at the moment though ;)
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.
@@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 ; ) ))
