Rust selling point 1. World's friendliest compiler 2. Challenging and feels good 3. No Garbage Collector 4. Blazingly fast 5. Strongly typed 6. Fantastic documentation
ปีที่แล้ว
World's unfriendliest compiler rather. Blazing fast is a lie. It's obviously trailing behind Zig or C. For Zig and C you can say blazing fast. Why are rust nerds always showing having garbage collector as a minus. That may be true to Java which creates spikes. Go's GC works differently. In the end it is always up to the developer how to use the language.
Go is simple and easy to learn, developers can easy adopt and use it in production in a short time, I am now learning Rust and I think the learning curve is very deep even though I have been programming for over 10 years.
From personal experience once your Rust project compiles it often runs as expected. You spent less time debugging. Also runtime performance is jaw dropping. I've seen Rust version beating C/C++ by up to 30% Learning curve for Rust is steep but worth it as you spend much more time using a tool compared to learning how to use it.
@@rendoesmath honestly I could see someone with more experience having even more difficulty shaking off some of the implicit assumptions a lot of other languages make, rusts ownership and borrowing concept are pretty different from most common languages. Beginner programmers are a bit more flexible so can probably pick it up easier. No need to shame.
@@rendoesmath There are different types of programming though. Systems programming for example, where Rust would be a natural fit, isn't going to be an area most web devs are going to be familiar with. I often think people new to Rust aren't so much confused by Rust itself, it's rather that they aren't really familiar with the domains Rust is used in. Which I get. Sometimes people simply think Rust is like a cool new way to do an API or something. Rust is a bit like finding an advanced car repair manual in Russian. You might speak fluent Russian, but if you don't understand anything about cars, the manual will still seem confusing.
As a beginner programmer, I've been enjoying Rust a lot. The strict compiler might seem annoying at first, but when stuff goes wrong (which is all the time), it's genuinely helpful unlike any other language I've tried. Writing code being time consuming isn't really a factor for me-I already aim to write verbose and easily readable code as my highest priority. The idea being spending more time writing code now = less time being confused later.
I've personally learned the basics of C++ first, then moved to Rust. That really taught me a lot about memory management and low level languages. After C++, moving to Rust was a breeze. You can also start directly with Rust, that depends on the amount of effort you want to put in :)
Rust is adding ~14 language features a year. C++ adds about ~10. C adds about ~0.7, and Go about ~2. To quote Drew DeVault: “Go is the result of C programmers designing a new programming language, and Rust is the result of C++ programmers designing a new language”
Just used that Drew quote like a couple comments above yours. Oops. Wasn't sure if I was gonna see it down here. I had initially thought about learning Rust, but then I realized just how insanely fast it's expanding (and how non-uniform the syntax feels), and quickly decided to learn Go instead. I'm really liking that choice so far. Go is an excellent language. Probably gonna replace most of my Python use cases.
@@friend7120 Rust wants to be the new C from what I recalled. Don't see how C++ fits in here but GO wants to be the new C# (in their respective fronts)
@@renatosardinhalopes6073 I don't think the Rust team has ever said they want to be the new C. One of the 'founders' (forget his name) said that if C++ keeps improving, it'll negate the need for Rust entirely. seems a pretty clear indication that C++, not C, is what Rust is competing with Go is used in very different areas to C#, so i'm not sure about that comparison
professional C developer and I've recently tried both rust and go. I can't get over how much I love go. it feels like a modern C to me. rust borrow checking and ownership makes sense as a concept but in practice is really rough for me to get right. one of my favorite things about both is they aren't "truly" OO. I think OO just adds so much abstraction and confusion, while things like C are much more straightforward. you have a piece of memory that contains data and you manipulate that data by accessing the memory. that data is not "performing" any actions itself like objects are thought to do. and for the most part both rust and go don't have that overly abstracted OO feeling!
I can't speak for Go, but Rust doesn't feel "OO" because it _isn't_ object-oriented. It's an amalgamation of procedural and functional programming (and, probably, some other aspects I can't name).
Exactly! Go is the new C :) I used to love C++, and Rust seemed super cool at that time. But then I switched to C and realized that Go is super cool :)
Ideally Go should be compared with C# or Java and Rust should be compared with C/C++ . At end of the day for embedded systems what counts is how fast a executable runs on hardware. So looks like Rust could be a successor to C/C++ for embedded systems.
I can agree to that. I really like rust, but I'm not totally sure, I should recommend it to beginners. But most languages beginners start with when learning programming, are pretty bad, like Java, C# are just bad languages, C, C++ are too low level, C++, Rust are too complex, and dynamically typed languages like python are difficult to use when wanting to teach about types. Go also was the first programming language I learnt after learning some application specific programming languages (GML) and some popular ones (Java, C++, Python). But because of the lack of generics, I didn't continue using it.
I've used Go, Rust, C#, JS, Java and VB so far. Rust is by far the coolest language imo. Go and C# are on second place for different reasons. Go is simple and good for small apps, C# is great for large apps and if you want to do many different things, due to having a vast ecosystem. I'm building a web application with Rust right now. I chose it due to security and performance. All my benchmarks placed Rust FAR ahead of other languages. And Rust forces you to architect your applications in a safer manner, which is critical for my application, since it's dealing with customer data. :)
Go for small apps? Currently I am seeing lots of complex applications being written in go most notably docker and kubernetes and tons of server backends
@@madanmohatra7190 The creator of Kubernetes said that he would probably have used Rust if he were to rebuild it again. They had to create a lot of workarounds for Go's limited set of features. I think they basically implemented their own hacky version of generics inside of Go.
@@WorstDeveloper 😂 😂 I found this on docker website Its creator Solomon Hykes cited Go's standard library, concurrency primitives, and ease of deployment as key factors, and said "To put it simply, if Docker had not been written in Go, it would not have been as successful." Looks like they made some good compromises
@@madanmohatra7190 Well yes, Rust didn't even reach version 1.0 until long after Kubernetes had been released. So Rust was definitely not an option back then. Btw, I have nothing against Go really. Its a tool, just like Rust. But personally I see Rust as being a better tool for large applications that require high performance with a small footprint. I think I'll use Go more once they have Generics and better error handling.
The biggest reason I prefer Rust to Go was only lightly addressed here: program correctness. I feel like Go falls into a lot of the pitfalls of modern languages such as default null values. Though Unit testing is always important, I feel that if your program compiles correctly in Rust your program has a much better chance of being correct than a lot of other languages out there. I'm also a huge fan of RAII which is something that Rust seems to embrace. I really thought with the advent of GCs that RAII would be considered antiquated, but apparently it's making a resurgence and I'm totally fine with that.
Rust is excellent especially for operating systems, high-frequency trading, compilers, etc. I think Go will win in popularity for the exact same reason Java outpaced C then Python outpaced Java in popularity. As individual engineers, beauty lies in the flexibility and control you have over the language. However, unless you're coding for fun you're looking to get paid which means the company you work for has to make a profit. This means they need to outpace, scale, and develop quickly by having a simple code base that can be understood and added to as fast as possible. So seniors need to be able to spin up junior engineers and make them as productive as possible in the least amount of time. Rust is super fast and performant and beautiful as a language but the experience to the end-user is near as makes no difference vs go (except in certain situations as mentioned above). It's Darwinism a company that can scale faster while providing the same performance to the end-user in fewer lines of code or complexity will outpace a similar company with a similar product written in a more complex code base with more lines of code needed to do the same thing.
rust still has its place as firms also aim to reduce costs, especially costs that scale with users. rust can provide less on cpu time and better memory usage for cloud computing & serverless infrastructure thus reducing costs by a factor of its own performance
wrong, rust can do everything that go can, the oppositte is not true. The pick for go is just the learning curve and easy of use, is enough to choose go? Maybe.
They're both modern languages with c-inspired syntax, and they both focus on concurrency. That's pretty much it as far as I can tell, kinda minimal but whatever.
Because they are the newest kids in town. People today compare Javascript to C++, despite the fact that they are both completely different beasts. That's because the comparison is in the difference, like: JS is used in web development while C++ is good for game design and etc. So the goal of the comparison is: Don't use C++ if you want to be a frontend developer. Same goes for Go and Rust: Don't use Rust in backend design, it's not its main purpose. In general, consider it like explaining the use of a hammer and a saw, you don't want to split that plank with you hammer don't you.
Agreed. On a team you can be pretty much 100% certain of the memory safety of others code so long as it compiles and they don’t have any unsafe blocks (the exception here being reference cycles in rare situations). And where they do have unsafe, it’s usually a small section of code you have to review. Same goes for multithreading (with a few exceptions such as dead lock) and type safety which are both even more mind blowing. Bye bye NPE.
tbh the compile time checks of rust are such a huge benefit, I am having a hard time justifying any alternative that doesn't have these features. I think this is something we're going to see adopted in many new technologies, but the old ones certainly will never implement it.
Evaluating a technology based on how fast you can start with it, it's the best way towards a fast failure. Every experienced manager knows that the most expensive part of a software development process is maintenance. That's exactly the reason why Rust is a superior language in terms of costs for whatever medium/long term project. Simply said, Rust DESTROYS maintenance costs. After 20 years of Java/JS/Python/PHP/TS/Go/Whatever, I can affirm that web development in Rust is the most unbelievable programming experience I ever had with my team. Is reviewing code boring? Well, the compiler does 90% of the job for you...
Why? I don't know rust much. How is it possible, that a compiler is able to solve maintenance problems? Is it some multi os compiling features or how can this be explained?
Willem Bielefeld Strong type checking and static analysis is built into rustc. The compiler is strict about preventing issues like using a variable that’s out of scope, having multiple mutable references to a single value at once, prematurely freeing heap memory, etc. Lots of obscure bugs that would cost valuable development time are eliminated, which is useful for maintaining large projects where these kinds of things can cause problems down the road.
@@naomiliu5201 But doesn't other compilers do this aswell? I had issues with the go compiler alot, but i never had issues with my c++ compiler so far. I was always wondering, why some do better than others. I always thought, it depends on the best practices and how you structure your code. That is why i prefer OOP over FP. And i thought, that FP is the problem, why the GO compiler is not working as good as the C++ compiler. Never heard a compiler could handle bad programing
Willem Bielefeld The most that GCC will do is throw an error for unmatched types, warn you about unsafe functions, or fail to parse malformed syntax. Rust’s compiler will analyze the lifetime and ownership of every pointer and variable you initialize, making sure that you’re not coding in such a way that will lead to a race condition or undefined behaviour. FP isn’t a problem, I would argue that it’s more scalable than OOP. Being able to abstract away from the idea of how your data “interacts”, like with nested inheritance chains, random methods, etc is powerful. Of course, proper code structure is important. But having a good compiler is the difference between your bugs popping up at runtime, or at compile-time.
This is a very good unbiased objective comparison, I have not previously worked on either of the two languages but I have learned much about them here. This is high-quality content, keep up the good work. I hope this channel grows.
Quick note, rust depends on libc, so it's not really a statically linked binary, it just links all dependencies except for libc. Go does not depend on this.
The last sentence makes all the argument for me. The best tool for the job. I'm actually using both and I see both of them staying in my toolkit for a long time to come - both have great sides. For us it comes down to the question if it makes sense to write something in Rust or Go (or even another language, but we mostly develop in Go and Rust these days). For me they are not really comparable, despite you CAN write most things in either, Rust and Go, it does not always make sense to actually do so. The biggest problem for me was really getting up to speed in Rust. There are great resources out there - really great ones, but it still took me weeks to get to a level of feeling somehow productive with it. Gets easier over time and the more you learn the more you value Rust, but the first steps are way harder than in Go (where I was feeling productive within a day).
Wait a second, an unbiased comparison in 2020?? Impossible xD! Also, one more advantage I would give Rust, is secure due to it being utilised as a safe language.
Hello fellow programmer. I was directly assigned from the Rust community forums to mark your comment as "Unsafe". This is because you are using a reference to a raw pointer (The year 2020) in your statement. Otherwise I absolutely agree with you. Bon Appétit and cheers! Hehehe
You don't really need to "be careful about memory management in Rust"... As long as you don't use unsafe (and there are no bugs in Rust) it will be 100% memory safe...
You're absolutely right, but my point was slightly different: when I say "be careful about memory management", I mean that you have to actually think about memory management in Rust, whereas in GC languages you (generally) don't. For example, in Rust you can have ~6 different types of references, which means you have to actively think about the best way to handle resource lifetimes when developing (see the "Complexity" paragraph for an example: matklad.github.io/2020/09/20/why-not-rust.html )
Yes, I think the greatest thing Rust offers is this sweet "middle ground", in which you do have to think about memory management by yourself, but in a higher (and less prone to errors) way compared to other low level languages such as C.
Or another way of looking at it: Rust fails fast. So you do have to worry about memory management, as in you have to think about it, but there's not much risk of a bug actually getting into production.
@@davidknipe4113 when someone says "be careful" i think i can do something wrong so that something bad happens. That's not the case. Yes you need to think about it although you don't have to directly think about it but through Ownership which is helpful in more ways than just memory management.
The biggest advantage of Rust isn't the performance, it's safety. Once your Rust program runs... it runs. With Go a lot of debugging hours/days/weeks may follow and at the end Rust was even slightly more productive without annoyed customers.
I dont get why you spend lot of debugging in Go. For me, debugging in Go is the easiest among languages I ever used, easier than previous I used such js, java, C#, or even c++. Go errors are pretty straight-forward, to the point. I mean, weeks? debugging?, I think It's just from inexperienced dev.
@@fathirirhas3609 “It's just from inexperienced dev.“ - But that's the point. There're always new programmers who screw your code and rust stops them from making faults rather than Go which makes you hope a critical error doesn't pop up from a niche situation on product presentation.
@@fathirirhas3609 They say experienced devs don't make mistakes. It's possible only when there's no way you can make a mistake. Using language with poor type system (C#, Java, C++, Go) will inevitably lead to some bugs in the future. On the other hand language with strong type system (Rust, Haskell) will eliminate mistakes by design. It's called `soundness`. You write your strongly typed code and know you won't ever debug it. You know noone ever will misuse it. You won't forget to dispose some resources. Code won't break when you will add new feature. There's no bugs after refactoring. You just code and it just works.
@@Youkakun Go has lower entry barrier and low learning curve for beginner. So beginners have lower chance of screwing code than in Rust. If you read in many testimony from companies who have adopted Go, they admit how Go is friendly to beginners, and also satisfying to experienced ones. Im not sure what kind of beginner of screwing code so bad, there's far more chance he/she will screw in Rust too.
@@mrPsyx0 Experienced Devs do make mistakes, it's lesser in Go. Are you some kind of expert saying those languages have poor type system?, Go is strongly typed languages in every references I read. I never bashed Rust, I know it's great language with great performance. But I'm tired seeing programmers are bashing other language, while he never/rarely used it and also inexperienced with it. From your statement, it's clearly stated that you somewhat never/rarely or even inexperienced dev. How can your program will be buggy, while beginner already creating things and run smoothly in their first tries. No offense, but this clearly come from inexperienced dev.
Go provides simplicity, unparalleled tooling, an excellent standard library, and insanely fast compile times that gives you rapid iterative development experience. The current iteration of the Go GC runs in parallel and the portion that causes pauses can be measured in nanoseconds. I haven't played with Rust yet since getting buy-in is way harder. However from everything I hear Go will get you to the complex errors faster, while Rust would help you resolve those errors faster if and when you reach them.
Took me maybe week to learn rust, and since then I have been working on 2 projects a REST server for a social media website, and a Game server for low latency high player count systems in unity. They have both been a blast to work on and honestly once you understand the language I find I really don't need stack overflow and debugging is minimal in rust compared to even me working in python. Rust is really weird but awesome when it comes to development speed, it honestly feels faster than python which shouldn't be a thing, it feels high level, but i am counting functions in the nano seconds. Id really suggest trying rust, I have used django and flask for REST, and I wont be going back to those after using rust
In the performance comparison at the and, you talk about CPU bound vs IO bound operations without using the name. ;) IO bound applications benefit greatly from some sort of parallelism, so your server doesn't block a whole thread while waiting for a database call or whatever. I'm not here to bash Go in any way, and from what I hear Go's concurrency model is one of the language's strongest suits. But as you say yourself, Rust shines here even more because of its strong compile time guarantees where the compiler catches the most common errors in multi threaded programming before they even get executed. And as everybody can confirm who ever tried to do concurrency in a language like Java, those bugs are among the nastiest you can have, as they happen so erratically. Therefore, I'd take a language as superior in which you can do concurrency in a safe manner - yet you're right, it comes at a cost, which is the learning curve.
Loved the video.. I wanted to learn systems programming improving OS and tweaking libraries and all I was confused wether to choose Rust or Go But after watching this video I’m gonna go with rust
If you jump from one language to another, you aren't really gonna learn either of them. What you need is a project. And who know how long that project may take? By the end of it there might even be a new language built by Ai that's just too good to skip
4:17 Rust compiler doesn't produce static binary by default if it's using libc as target. A lot of crates don't work with MUSL libc as a target, so the claim about producing "static binary" compared to Go does not hold really.
In simpler terms Go is python with rocket boosters and nitro Rust is C without legacy code(C's decades old compatible code) and reduces the ways to mess your program.
Go is by no means similar to Python. I work as a data engineer and I would probably loose my fucking mind over having to work with Go. It's great for web backend or CLI-s but I definitely wouldn't use it in the same contexts as Python. To me it seems more like a smarter version of Pascal than anything else.
@@davidowens9597 nope, Go is very different, it has runtime, has garbage collector, has a little OOP mess around, can't call C directly. Compare to Rust which can use anywhere C exist
@@hailuong9295 Right. That's why I said it was a 21st century version of C. It's like C with modern features like garbage collection added. One of the creators of Go, Ken Thompson, was also a co-creator of the B language, which was expanded to become the C programming language.
Just started go coming from node and love it and it’s take about a week to get around most concepts. That is true. It took days. Hmmmm got me thinking I need to do a personal small project in rust.
@@FedericoTerzi so I am! I’m still gonna help a close family member out with their company site and use go (the built in http library is pretty decent ) with react BUT I’ve been wanting a better way to find TH-cam channels I’m subbed to and gonna build a backend with rust to a fire stick app to organize my yt videos better. Thanks for your channel gonna go thru it on my walk today if I can ever get my pulled hamstring healed lol (I’m on the floor painful morning lol)
I don’t understand why people insist on comparing Rust with Go. They are such wildly different languages, and their performance isn’t even that similar. My guess is that they just happen to be interesting & popular languages that arrived on the scene around the same time. But that doesn’t mean anything in terms of their similarities. If the answer is “they can both be used for writing web servers,” then why not include literally every other language, like Clojure, or Pascal, or C? It’s really not a good criteria for grouping languages IMO.
I definitely agree with you, they are very different languages, designed with different goals in mind. That said, why not compare them? Languages are nothing more than tools, and the more we spread information about their differences (and ideal use cases), the less fights we get over which of them is better than the other. Instead of "which", people should ask themselves "when" to use them :)
Federico Terzi that’s fair, but this is hardly the first comparison between Rust and Go, and it’s clearly a trendy comparison to make. My point isn’t that we shouldn’t compare them, it’s that there is a huge number of people who think of these languages as inhabiting the same space, and it’s genuinely weird. Like it would be weird to act as if Ruby and C are related & worth comparing, aside from them both being languages at all. That’s how I feel about Rust and Go. It’s just apples and oranges...
In web development as long as the main cost is engineers' salaries then languages like Go are the tools to use, when the platform bill overcomes those costs then it is time to switch to a more performant language. As long as the requirements are met nobody cares if your app is a few ms faster.
To say that Rust has manual memory management is not strictly correct. It doesn't by default. It automatically handles memory, but not using garbage collection.
its a tautology with no real information content, and often used to reinforce the idea that all tools have a use. probably some tools are just bad! though i don’t think Go or Rust are bad
@Jack Mott I don't agree with your comment. Yes some tools are just bad and we shouldn't use them, that's why we should use the right tools, not all tools
@@dylanadc4403 I want to know if I should use Rust or Go. Someone tells me "use the right tool for the job". I still don't know what to do. No information is imparted. What tool is right for what job is the question everyone has. And we have no rigorous answers!
@@JackMott I understand what you mean but it depends! It depends of your needs, of your time, of your project... As he said in the video, Go is better for web services and Rust for high performance applications but both tools are good in general. As engineer we need to know these different tools, so we can make choices about it
@@dylanadc4403 you still have no answer for the question. Probably most devs don't know "the right tool for the job". This is just a phrase that people repeat over and over again.
Nowadays with all the code that exist all the problems can be solved by most programming languages. I'd pick rust a thousand times though just because of what it stands for and how comparable it is to both old low level languages and new more abstract ones.
Perfect video and your english is amazing. I'm not a native en speaker, and I usually have problems in order to undestand every word that I hear but you talk perfect. Nice video!
Something that you missed is that the reason Rust is more popular for FE web development is because the Go runtime is a whopping 1.3 MB -- excluding it from many FE usecases outright. Rust on the other hand is closer to 10kb
Rust is cool, I just started developing a new service with it. One thing I didn't like so far is that most tutorials or examples skip the unit testing part or just do very basic unit tests without any mocks. It took me a while to figure out how to unit test my database access stuff.
As an architect, and with Microservices, a team or individual can pick the language and technical stack they want for their problem. As you say, Go is for concurrency and Rust is for system level and performance intensive application. I know Java, Typescript, R and Python3. If you see R programs they are memory intensive but concise whereas python is more descriptive yet faster.
Definitely! In fact, microservices were introduced mostly as an organizational tool, as different teams can work (mostly) independently from each other
Very nice, clear and interesting overview. I'd like to post one question: which language do you evaluate better for industrial automation or embedded devices, where the most important requirement is real time performance, reading inputs from sensors and driving HW outpus? Thanks
Thanks! I don't have any experience in that area, so my opinion doesn't really matter. In that space, probably the good old C, C++, Zig and Rust are the best choices
@@FedericoTerzi C, C++ and Python have well known and longly tested history in this fields. My question is related to some innovative application, as for example in IOT. Anyway: thanks again for your video!
Of course! A garbage collector can be seens as a piece of code that runs on a separate thread and periodically scans the references to free the unused memory. You don't need a VM for any of this :)
I'm trying to decide, I don't want to learn both, but I want a language that is fast for game dev and has a quick compile time. Go's got a garbage collector, which kills runtime performance, but Rust's compiler is so damned slow. I wonder, is it getting quicker? Maybe they could introduce a 'design time' mode that is quicker.
A different choice of words might have been better, with "static binaries" I meant "statically linked binaries", which is the case in Go but not in Rust (by default), which produces dinamically linked binaries instead. Sorry for that :)
I didn't know as well! One of the viewers pointed that out in the comments: doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html
That's true indeed! I think that it mainly has to do with the fact that most programming here is done for enterprises, which are always slow to adapt to new technologies (in fact it's even hard to find something not Java/ C++ or .NET related...). If you move to the startup ecosystem though, things get more interesting :) Also, nowadays remote work is growing pretty strong, which opens up a ton of possibilities (for example, I'm working part-time as a Rust consultant for a foreign company)
lavoravo con java 8 e spring boot, ho cambiato lavoro e adesso sto in ballo con le jsf e java 6, rip me...non è possibile che in italia è solo java/c++, quasi quasi passo a fare front end
@@sharkpyro93 settore web(in Italia) php è ancora fortissimo, tra l'altro vorrei aggiungere che da noi c'è molta confusione e incertezza se puntare o no su nuove tecnologie, non si trovano praticamente nessuna richiesta per rust, go.. a malapena si trovano full stack Javascript.. Come già detto in precedenza dal collega molto meglio lavorare con aziende estere piuttosto che quelle nostrane
Don't waste your time on these time consuming comments!!! Just watch the video it's pretty straight forward. Didn't intended to make who is a winner, but where you should use each of the language. And that's is pretty awesome! Somehow the title of the video is misleading.
All the points you make are not very strong arguments and I’d even say pretty poor. The first problem of your points is that idea that Go is easier to read than Rust. Before stating something like that, you should define the axis you use to quantify “easy to read.” For instance, I find Rust, Haskell and functional programming languages much easier to read than Python, Go or similar languages. My way of seeing it is: “Do I need to learn about the context / other lines of code to understand this line of code?” For that matter, Rust is much simpler and easier to read than Go, especially because Go lacks algebraic types, and the error mechanism is just super hard to “read through” compared to Option / Result from Rust. When you talk about scaling programs in a team, I wonder if you’ve really worked on a big Go project with various and different people of different skills. The compiler doesn’t know as much as what you do as in Rust, especially when it boils down to error management. The way Go makes things work leads to hard to maintain, reason about and read code. On the other side, the entry-bar to understand Rust is hard, but once you understand the language, maintaining a Rust code base scales much much better, especially as the team and project grow. Another problem is when you talk about memory safety. You’re using a fallacious argument stating that Rust’s memory model is “manual”, but that’s not true. No one really allocates memory. The memory in Rust is handled by, mostly, owned data, such as reference counting structure (Rc / Arc), boxed data types (Box / Vec / any collection), etc. Rust has a mechanism a bit akin to RAII (Drop) which is “somewhat” similar to destructors, but more “type-safe”. On the other side, Go has pointers and null pointers. It is _very_ easy to trigger a segfault from a Go program, while, in “safe” Rust, it’s not as easy. You say you have “to be careful when using Rust.” Eh?! Unless you are using unsafe (which you shouldn’t, unless writing a low-level library), using collections from the standard library or even boxed types (which hold data on the heap), there’s no easy way to trigger a double-free, use after free, dangling pointer or anything of that kind. Most of the time, in Rust, we worry more about the number of allocations / the allocation scheme we use rather than safety because, well, rustc already has our back. You can’t say the same thing with Go. The terms you should have used instead of “manual” and “automatic” are “nonmanaged” and “managed.” For the web development, I guess you are right. This is something that has been a big topic in the Rust community and it’s getting better, but I guess I would advise people to use other languages than Rust so far for web development (I personally use servant, a Haskell library, but Go should be okay too).
I appreciate your opinion, even though I don't agree with all your points. I understand that in a couple of instances, a different choice of wording might have been easier, but most of my points were the results of combining various articles and sources, so they are by no means only based on my personal opinion. To answer your points: > The first problem of your points is that idea that Go is easier to read than Rust. Before stating something like that, you should define the axis you use to quantify “easy to read.” For instance, I find Rust, Haskell and functional programming languages much easier to read than Python, Go or similar languages. My way of seeing it is: “Do I need to learn about the context / other lines of code to understand this line of code?” For that matter, Rust is much simpler and easier to read than Go, especially because Go lacks algebraic types, and the error mechanism is just super hard to “read through” compared to Option / Result from Rust. From what I understand, you are an experienced developer, especially used to Functional languages. While I agree on the fact that Rust can be a very expressive language, it's only easy to understand once you grasp the fundamentals. I'm sorry to say this, but I find your argument "Rust and Haskell are much easier to read than Python and Go" highly subjective. Ask a beginner to read a Python program and then a Haskell program, I'm sure he/she won't find the latter easier to understand. My point was that in Go it's easier to get started, as it's easy to read and easy to write, which has nothing to do with your argument. Saying that it's easier to get started in Rust is just plain wrong. > When you talk about scaling programs in a team, I wonder if you’ve really worked on a big Go project with various and different people of different skills. The compiler doesn’t know as much as what you do as in Rust, especially when it boils down to error management. The way Go makes things work leads to hard to maintain, reason about and read code. On the other side, the entry-bar to understand Rust is hard, but once you understand the language, maintaining a Rust code base scales much much better, especially as the team and project grow. Many people argue that "Go is about suppressing complexity at scale", see: kristoff.it/blog/why-go-and-not-rust/ I prefer Rust as well, but I wanted to cover both sides of the argument. > Another problem is when you talk about memory safety. You’re using a fallacious argument stating that Rust’s memory model is “manual”, but that’s not true. No one really allocates memory. The memory in Rust is handled by, mostly, owned data, such as reference counting structure (Rc / Arc), boxed data types (Box / Vec / any collection), etc. Rust has a mechanism a bit akin to RAII (Drop) which is “somewhat” similar to destructors, but more “type-safe”. On the other side, Go has pointers and null pointers. It is very easy to trigger a segfault from a Go program, while, in “safe” Rust, it’s not as easy. You say you have “to be careful when using Rust.” Eh?! Unless you are using unsafe (which you shouldn’t, unless writing a low-level library), using collections from the standard library or even boxed types (which hold data on the heap), there’s no easy way to trigger a double-free, use after free, dangling pointer or anything of that kind. Most of the time, in Rust, we worry more about the number of allocations / the allocation scheme we use rather than safety because, well, rustc already has our back. You can’t say the same thing with Go. The terms you should have used instead of “manual” and “automatic” are “nonmanaged” and “managed.” Here I tend to agree more with you. I received some criticism for my choice of words, and I can understand why. I'll paste my other answer here: Good point, perhaps "manual memory management based on ownership and borrowing" wasn't the best way to describe it. That said, I did my research before making the video, and many developers described the process as manual (see: pcwalton.github.io/2013/03/18/an-overview-of-memory-management-in-rust.html). It really comes down to how you define "manual", do you have to call free() to have a manual memory management system? I could argue that by just deciding where the scope of the variable ends, you decide how long that chunk of data will stay in memory (as you just get an implicit free() call when out of scope), therefore making it manual. Regarding the "be careful when using rust" I'll paste another answer: You're absolutely right, but my point was slightly different: when I say "be careful about memory management", I mean that you have to actually think about memory management in Rust, whereas in GC languages you (generally) don't. For example, in Rust you can have ~6 different types of references, which means you have to actively think about the best way to handle resource lifetimes when developing (see the "Complexity" paragraph for an example: matklad.github.io/2020/09/20/why-not-rust.html ) I understand that "be careful" might not be the best choice, I'm sorry about that. Then, of course, we can have different opinions and still live a happy life :)
Though I think from my experience with actix, flask, Starlette, express and Django. Actix-web and Rocket are mature for their context and are not lacking performance/ features, e.g. HTTP/X support, Data handling, Routing and Integrations (diesel, askama ...). The ecosystem is generally not as mature as Go (overall) but the general things you need e.g. tokio, actix, sodiumoxide or non-std libs are pretty mature and supported.
Love both Go and Rust. I'm mostly a programmer dabber, then a very good one. I just enjoy learning at my pace, just to do the simple things. Jack of all trades, master of none. Only programming language I can say I really know is Lua. But I'm learning Python, C and Javascript. Which Javascript is the second one I can say I'm getting to know very well. I dab in many other's, but I say I'm the strongest of the one's I mention here. Not sure if I'm going to be good at all of them. But I'm going to give it my all for sure.
One does not exclude the other :) You _can_ write a web service in Rust, I just don't think the performance improvements justify the less mature ecosystem and ergonomics compared to Node+Typescript or Go for most systems
Just a correction, rust does not "provenly" guarantee thread safety. It's not proven in a mathematical term, so it's still possible to run into concurrency, dead locks, etc when using rust. It's just harder to get into those when using rust vs other languages.
Indeed! Though one might argue that it's very hard to prove a program runtime "mathematically", as there are a number of assumptions we are making about hardware not failing which are not really provable (even just a cosmic ray could cause a bit flip in a real system)
@@FedericoTerzi I meant a compiler theory point of view. The compiler provenly guarantees syntax correctness for instance, it's impossible to compile if the syntax is wrong. But it's still not proven that any rust program that compiles is thread safe.
@@FedericoTerzi there is still a benefit in rust tough, because if you fall into some edge case where you run into thread safety issues, then the rust compiler team would take it as a bug in the compiler. As opposed to C++ or other languages where you'll be on your own.
Python doesn't traditionally use a garbage collector while it rather uses reference counting internally. It's somewhat similar to if you were to wrap everything into a std::shared_ptr in C++.
Yep, my choice of words there wasn't great... Python use a combination of reference counting (the main mechanism) and garbage collection (to handle circular references)
I like Rust because its biult to be really low lever, but with third party crates you can create robust desktop apps. I made a Geometry Dash macro clickbot that places clicks wherever a macro clicks, then spits out a .wav file. 12 thousand clicks per second, and it only took 1 second to finish. With many crates adding features present in high level languages, its possible to build great things with Rust.
Rust does not have manual memory management by default, the ownership system manages the memory for you. The Rust compiler isn’t “very good at catching memory errors”, it makes it *impossible* to have memory errors or memory-related security vulnerabilities so long as you’re following the ownership rules. There is an area of Rust called unsafe Rust that lets you manage memory by hand, but it’s highly recommended that you avoid using it as much as possible.
Good point, perhaps "manual memory management based on ownership and borrowing" wasn't the best way to describe it. That said, I did my research before making the video, and many developers described the process as manual (see: pcwalton.github.io/2013/03/18/an-overview-of-memory-management-in-rust.html). It really comes down to how you define "manual", do you have to call free() to have a manual memory management system? I could argue that by just deciding where the scope of the variable ends, you decide how long that chunk of data will stay in memory (as you just get an implicit free() call when out of scope), therefore making it manual. Regarding the second part, I always prefer to avoid strong claims such as "impossible", as we live in a complex world :) For example, most of the standard Rust library is built on top of unsafe blocks, so (in very very rare circumstances), you could still get a memory error even if you never used unsafe yourself. Saying that it's impossible to have memory errors is pretty much the same as claiming that a program is completely bug-free, hard to say :)
If you consider memory leak a memory error, then no, Rust still has memory leaks, which are much less frequent with a garbage collector. That said Rust also has race conditions, as documented here: doc.rust-lang.org/nomicon/races.html. The only thing it prevents is memory corruption of a certain specific family, but not all of them.
I would rather compare it to Go because it's also a GCed language and there are a lot of similar concepts (the approaches to syntax are a lot different though) like Goroutines and Kotlin Coroutines. Syntactically Kotlin might be closer to Rust actually but from a usecase POV it's a lot closer to Go. What compiler backend they are using (which is what LLVM is) is basically irrelevant for the end user and just because two languages use LLVM as a backend it doesn't really mean that they have anything in common.
@@meamzcs Java and clojure also do not have anything in common but people still compare those because both have jvm as a backend and can use the same libraries. In the same way, I expected that LLVM should allow sharing libraries between rust and kotlin native.
@@yatsuk Nope. That doesn't work. What the JVM thing would translate to for LLVM is roughly "both compile to x86"... Whether it's using LLVM or something else as the backend is essentially an irrelevant implementation detail. It's basically comparing two programs just because they have one library in common... Which is what LLVM is: a library... LLVM is nothing like the JVM. The JVM is a compilation target that runs software at runtime. LLVM is a library that takes a standardized internal representation and can then transform it to machinecode in all of the ISAs it supports at compile time... It makes sense to compare JVM languages to one another because they all have kind of the same limitations imposed by the JVM and therefore can all be used in roughly the same usecases.
Why every one try to move to new language like Go & Rust When Java can do the same and have good performance (appreciate if someone can explain that and what is the difference between them , I'm beginner ?
Here blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f is a significant deployment originally done in Go, which they are switching to Rust.
Also consider that the Linux kernel developers are considering allowing Rust code to be included. But not Go. Also, this: www.zdnet.com/article/microsoft-why-we-used-programming-language-rust-over-go-for-webassembly-on-kubernetes-app/
Though kubernetes devs had to reinvent objects due to exponentially growing complexity of the system just to ease it a little. Lack of language expression made them suffer a lot. That's the point: easy languages only suitable for easy tasks. Take Python and Go. They are really easy to start. They are hiding a lot of problems from you. It's pleasant to develop small apps when your brain is still capable to grasp all project structure and you remember all caveats. When your project will grow to the size your brain can't handle you will notice some problems appearing.
I never realized this channel is owned by the espanso's developer!! Dude you are awesome!! Edit: I am surprised that you didn’t advocate Rust considering espanso is one of the best of program written in rust.
After sometimes using Go, I realized how unsuitable Go for backend services are. Go is so simple it's lacking. It lacks many language features exist in other languages to power you up writing backend business logic. If you look at many great companies employing Go, they are not employing it for writing their core system or business logic, but instead they're employing it for tooling their infrastructure and devops. Then I ask my self: "Who write business logic in Go?", The more proper usage of Go are in realm of tooling supporting your core system, infra, and devops, it also great for serverless arch, load balancing, and worker, But for the core system/services I prefer Rust over Go now and planning investing in Rust for now.
If you are interested in these topics, you can also follow me on Twitter :) twitter.com/terzi_federico
Rust selling point
1. World's friendliest compiler
2. Challenging and feels good
3. No Garbage Collector
4. Blazingly fast
5. Strongly typed
6. Fantastic documentation
World's unfriendliest compiler rather. Blazing fast is a lie. It's obviously trailing behind Zig or C. For Zig and C you can say blazing fast. Why are rust nerds always showing having garbage collector as a minus. That may be true to Java which creates spikes. Go's GC works differently. In the end it is always up to the developer how to use the language.
@ LOL!
Go is simple and easy to learn, developers can easy adopt and use it in production in a short time, I am now learning Rust and I think the learning curve is very deep even though I have been programming for over 10 years.
Don't give up! Rust takes a while to grasp, but then it's well worth it :)
From personal experience once your Rust project compiles it often runs as expected. You spent less time debugging. Also runtime performance is jaw dropping. I've seen Rust version beating C/C++ by up to 30%
Learning curve for Rust is steep but worth it as you spend much more time using a tool compared to learning how to use it.
bruh even after 10 years of experience it seems hard for you?
@@rendoesmath honestly I could see someone with more experience having even more difficulty shaking off some of the implicit assumptions a lot of other languages make, rusts ownership and borrowing concept are pretty different from most common languages. Beginner programmers are a bit more flexible so can probably pick it up easier. No need to shame.
@@rendoesmath There are different types of programming though. Systems programming for example, where Rust would be a natural fit, isn't going to be an area most web devs are going to be familiar with.
I often think people new to Rust aren't so much confused by Rust itself, it's rather that they aren't really familiar with the domains Rust is used in. Which I get. Sometimes people simply think Rust is like a cool new way to do an API or something.
Rust is a bit like finding an advanced car repair manual in Russian. You might speak fluent Russian, but if you don't understand anything about cars, the manual will still seem confusing.
As a beginner programmer, I've been enjoying Rust a lot. The strict compiler might seem annoying at first, but when stuff goes wrong (which is all the time), it's genuinely helpful unlike any other language I've tried. Writing code being time consuming isn't really a factor for me-I already aim to write verbose and easily readable code as my highest priority. The idea being spending more time writing code now = less time being confused later.
I agree! :)
Rust is not easily readable
You probably are still a student. Write this comment of yours on your resume and good luck finding a job!
Rust has quickly become my favourite language, I found it pretty easy to pick up as well since the docs are decent
After grasping the fundamentals, Rust it's a very enjoyable language :)
I've personally learned the basics of C++ first, then moved to Rust. That really taught me a lot about memory management and low level languages. After C++, moving to Rust was a breeze.
You can also start directly with Rust, that depends on the amount of effort you want to put in :)
Docs.rs is great
C++ 20 and beyond
@Vizman216 at least in comparison to cpp
Go for Rust ;-)
Rust to Go!
@@gcxs that's true. You can use Rust to develop mobile apps for Android and iOS.
that sentence is powered by Go
@@MarkusBurrer how?
i didn't get what are you saying :D
Rust is adding ~14 language features a year. C++ adds about ~10. C adds about ~0.7, and Go about ~2.
To quote Drew DeVault:
“Go is the result of C programmers designing a new programming language, and Rust is the result of C++ programmers designing a new language”
Just used that Drew quote like a couple comments above yours. Oops. Wasn't sure if I was gonna see it down here.
I had initially thought about learning Rust, but then I realized just how insanely fast it's expanding (and how non-uniform the syntax feels), and quickly decided to learn Go instead. I'm really liking that choice so far. Go is an excellent language. Probably gonna replace most of my Python use cases.
Wouldn't it be the opposite???
@@renatosardinhalopes6073 why would it be the opposite
@@friend7120 Rust wants to be the new C from what I recalled. Don't see how C++ fits in here but GO wants to be the new C# (in their respective fronts)
@@renatosardinhalopes6073 I don't think the Rust team has ever said they want to be the new C. One of the 'founders' (forget his name) said that if C++ keeps improving, it'll negate the need for Rust entirely. seems a pretty clear indication that C++, not C, is what Rust is competing with
Go is used in very different areas to C#, so i'm not sure about that comparison
professional C developer and I've recently tried both rust and go. I can't get over how much I love go. it feels like a modern C to me. rust borrow checking and ownership makes sense as a concept but in practice is really rough for me to get right. one of my favorite things about both is they aren't "truly" OO. I think OO just adds so much abstraction and confusion, while things like C are much more straightforward. you have a piece of memory that contains data and you manipulate that data by accessing the memory. that data is not "performing" any actions itself like objects are thought to do. and for the most part both rust and go don't have that overly abstracted OO feeling!
I can't speak for Go, but Rust doesn't feel "OO" because it _isn't_ object-oriented. It's an amalgamation of procedural and functional programming (and, probably, some other aspects I can't name).
Exactly! Go is the new C :)
I used to love C++, and Rust seemed super cool at that time.
But then I switched to C and realized that Go is super cool :)
Take only one week learning to use the rust , wow. I been learning about half year and still going through.
So true lol
Says some one with GOs logo on his profile
@@katarsloto4223 lol
@@katarsloto4223 That explains it all
Ideally Go should be compared with C# or Java and Rust should be compared with C/C++ . At end of the day for embedded systems what counts is how fast a executable runs on hardware. So looks like Rust could be a successor to C/C++ for embedded systems.
You might group these sentences in the wrong way: "Go should be compared with C#" OR "Java and Rust should be compared with C/C++"
I can agree to that. I really like rust, but I'm not totally sure, I should recommend it to beginners. But most languages beginners start with when learning programming, are pretty bad, like Java, C# are just bad languages, C, C++ are too low level, C++, Rust are too complex, and dynamically typed languages like python are difficult to use when wanting to teach about types.
Go also was the first programming language I learnt after learning some application specific programming languages (GML) and some popular ones (Java, C++, Python).
But because of the lack of generics, I didn't continue using it.
@@porky1118 C is not too complex. It's actually very easy to learn, but hard to master
@@guy-dev C is not too complex, but might be too low level for beginners.
But I'd still recommend it instead of Java because of the simplicity.
@@porky1118 being low level makes it *perfect* for beginners, since it teaches you how a computer thinks.
The comparison is unbiased. I can't believe it!
I wanna ask youtube why this video has come in my recommendation list this late?
It's a total life saving and enlightening video.
I like how he mentioned the learning curve and getting your friends to use it, that’s my number one gripe with rust 😢
try zig
I've used Go, Rust, C#, JS, Java and VB so far. Rust is by far the coolest language imo. Go and C# are on second place for different reasons. Go is simple and good for small apps, C# is great for large apps and if you want to do many different things, due to having a vast ecosystem.
I'm building a web application with Rust right now. I chose it due to security and performance. All my benchmarks placed Rust FAR ahead of other languages. And Rust forces you to architect your applications in a safer manner, which is critical for my application, since it's dealing with customer data. :)
I agree with you! :)
Go for small apps? Currently I am seeing lots of complex applications being written in go most notably docker and kubernetes and tons of server backends
@@madanmohatra7190 The creator of Kubernetes said that he would probably have used Rust if he were to rebuild it again. They had to create a lot of workarounds for Go's limited set of features. I think they basically implemented their own hacky version of generics inside of Go.
@@WorstDeveloper 😂 😂 I found this on docker website
Its creator Solomon Hykes cited Go's standard library, concurrency primitives, and ease of deployment as key factors, and said "To put it simply, if Docker had not been written in Go, it would not have been as successful."
Looks like they made some good compromises
@@madanmohatra7190 Well yes, Rust didn't even reach version 1.0 until long after Kubernetes had been released. So Rust was definitely not an option back then.
Btw, I have nothing against Go really. Its a tool, just like Rust. But personally I see Rust as being a better tool for large applications that require high performance with a small footprint. I think I'll use Go more once they have Generics and better error handling.
I rewatched this for the first 12 seconds. :D
Glad you liked it :)
There is a reason Rust always tops the top most loved programming languages in developer surveys every year.
And a reason why nobody is using it for anything big
@@theLowestPointInMyLife They use it in firefox, chrome and test it in the linux kernel.
This is an amazing and mature unbiased comparison. Thank you so much!
Thanks :)
The biggest reason I prefer Rust to Go was only lightly addressed here: program correctness. I feel like Go falls into a lot of the pitfalls of modern languages such as default null values. Though Unit testing is always important, I feel that if your program compiles correctly in Rust your program has a much better chance of being correct than a lot of other languages out there. I'm also a huge fan of RAII which is something that Rust seems to embrace. I really thought with the advent of GCs that RAII would be considered antiquated, but apparently it's making a resurgence and I'm totally fine with that.
Rust is excellent especially for operating systems, high-frequency trading, compilers, etc. I think Go will win in popularity for the exact same reason Java outpaced C then Python outpaced Java in popularity. As individual engineers, beauty lies in the flexibility and control you have over the language. However, unless you're coding for fun you're looking to get paid which means the company you work for has to make a profit. This means they need to outpace, scale, and develop quickly by having a simple code base that can be understood and added to as fast as possible.
So seniors need to be able to spin up junior engineers and make them as productive as possible in the least amount of time. Rust is super fast and performant and beautiful as a language but the experience to the end-user is near as makes no difference vs go (except in certain situations as mentioned above). It's Darwinism a company that can scale faster while providing the same performance to the end-user in fewer lines of code or complexity will outpace a similar company with a similar product written in a more complex code base with more lines of code needed to do the same thing.
rust still has its place as firms also aim to reduce costs, especially costs that scale with users. rust can provide less on cpu time and better memory usage for cloud computing & serverless infrastructure thus reducing costs by a factor of its own performance
Fair, balanced comparison. Thank you!
Thanks :)
Why people keep comparing go and rust??? They are very different languages with different purposes
Exaclty. It's like comparing truck to sports car, which is better. Answer depends on what do you want your car to use it.
wrong, rust can do everything that go can, the oppositte is not true. The pick for go is just the learning curve and easy of use, is enough to choose go? Maybe.
Because they have the same level of hype
They're both modern languages with c-inspired syntax, and they both focus on concurrency. That's pretty much it as far as I can tell, kinda minimal but whatever.
Because they are the newest kids in town. People today compare Javascript to C++, despite the fact that they are both completely different beasts. That's because the comparison is in the difference, like: JS is used in web development while C++ is good for game design and etc. So the goal of the comparison is: Don't use C++ if you want to be a frontend developer.
Same goes for Go and Rust: Don't use Rust in backend design, it's not its main purpose.
In general, consider it like explaining the use of a hammer and a saw, you don't want to split that plank with you hammer don't you.
It doesn't sound like he grasped the real power of rust in his memory management section.
Agreed. On a team you can be pretty much 100% certain of the memory safety of others code so long as it compiles and they don’t have any unsafe blocks (the exception here being reference cycles in rare situations).
And where they do have unsafe, it’s usually a small section of code you have to review.
Same goes for multithreading (with a few exceptions such as dead lock) and type safety which are both even more mind blowing. Bye bye NPE.
About the memory management, unlike C/C++ it doesn't require any manual memory management it is build within the language itself.
tbh the compile time checks of rust are such a huge benefit, I am having a hard time justifying any alternative that doesn't have these features. I think this is something we're going to see adopted in many new technologies, but the old ones certainly will never implement it.
Evaluating a technology based on how fast you can start with it, it's the best way towards a fast failure.
Every experienced manager knows that the most expensive part of a software development process is maintenance. That's exactly the reason why Rust is a superior language in terms of costs for whatever medium/long term project. Simply said, Rust DESTROYS maintenance costs.
After 20 years of Java/JS/Python/PHP/TS/Go/Whatever, I can affirm that web development in Rust is the most unbelievable programming experience I ever had with my team.
Is reviewing code boring? Well, the compiler does 90% of the job for you...
Thanks for the useful insight!
Why? I don't know rust much. How is it possible, that a compiler is able to solve maintenance problems? Is it some multi os compiling features or how can this be explained?
Willem Bielefeld Strong type checking and static analysis is built into rustc. The compiler is strict about preventing issues like using a variable that’s out of scope, having multiple mutable references to a single value at once, prematurely freeing heap memory, etc. Lots of obscure bugs that would cost valuable development time are eliminated, which is useful for maintaining large projects where these kinds of things can cause problems down the road.
@@naomiliu5201 But doesn't other compilers do this aswell? I had issues with the go compiler alot, but i never had issues with my c++ compiler so far. I was always wondering, why some do better than others.
I always thought, it depends on the best practices and how you structure your code. That is why i prefer OOP over FP. And i thought, that FP is the problem, why the GO compiler is not working as good as the C++ compiler.
Never heard a compiler could handle bad programing
Willem Bielefeld The most that GCC will do is throw an error for unmatched types, warn you about unsafe functions, or fail to parse malformed syntax.
Rust’s compiler will analyze the lifetime and ownership of every pointer and variable you initialize, making sure that you’re not coding in such a way that will lead to a race condition or undefined behaviour.
FP isn’t a problem, I would argue that it’s more scalable than OOP. Being able to abstract away from the idea of how your data “interacts”, like with nested inheritance chains, random methods, etc is powerful.
Of course, proper code structure is important. But having a good compiler is the difference between your bugs popping up at runtime, or at compile-time.
This is a very good unbiased objective comparison, I have not previously worked on either of the two languages but I have learned much about them here. This is high-quality content, keep up the good work. I hope this channel grows.
Thanks :)
Quick note, rust depends on libc, so it's not really a statically linked binary, it just links all dependencies except for libc. Go does not depend on this.
And Go still has smaller binaries!
The last sentence makes all the argument for me. The best tool for the job. I'm actually using both and I see both of them staying in my toolkit for a long time to come - both have great sides. For us it comes down to the question if it makes sense to write something in Rust or Go (or even another language, but we mostly develop in Go and Rust these days). For me they are not really comparable, despite you CAN write most things in either, Rust and Go, it does not always make sense to actually do so.
The biggest problem for me was really getting up to speed in Rust. There are great resources out there - really great ones, but it still took me weeks to get to a level of feeling somehow productive with it. Gets easier over time and the more you learn the more you value Rust, but the first steps are way harder than in Go (where I was feeling productive within a day).
Same here man…
Wait a second, an unbiased comparison in 2020?? Impossible xD!
Also, one more advantage I would give Rust, is secure due to it being utilised as a safe language.
Hello fellow programmer.
I was directly assigned from the Rust community forums to mark your comment as "Unsafe". This is because you are using a reference to a raw pointer (The year 2020) in your statement. Otherwise I absolutely agree with you.
Bon Appétit and cheers!
Hehehe
You don't really need to "be careful about memory management in Rust"... As long as you don't use unsafe (and there are no bugs in Rust) it will be 100% memory safe...
You're absolutely right, but my point was slightly different: when I say "be careful about memory management", I mean that you have to actually think about memory management in Rust, whereas in GC languages you (generally) don't. For example, in Rust you can have ~6 different types of references, which means you have to actively think about the best way to handle resource lifetimes when developing (see the "Complexity" paragraph for an example: matklad.github.io/2020/09/20/why-not-rust.html )
@@FedericoTerziYes that's true in a way. Although i think memory management is only one aspect of what ownership and borrowing do.
Yes, I think the greatest thing Rust offers is this sweet "middle ground", in which you do have to think about memory management by yourself, but in a higher (and less prone to errors) way compared to other low level languages such as C.
Or another way of looking at it: Rust fails fast. So you do have to worry about memory management, as in you have to think about it, but there's not much risk of a bug actually getting into production.
@@davidknipe4113 when someone says "be careful" i think i can do something wrong so that something bad happens. That's not the case. Yes you need to think about it although you don't have to directly think about it but through Ownership which is helpful in more ways than just memory management.
The biggest advantage of Rust isn't the performance, it's safety. Once your Rust program runs... it runs.
With Go a lot of debugging hours/days/weeks may follow and at the end Rust was even slightly more productive without annoyed customers.
I dont get why you spend lot of debugging in Go. For me, debugging in Go is the easiest among languages I ever used, easier than previous I used such js, java, C#, or even c++. Go errors are pretty straight-forward, to the point. I mean, weeks? debugging?, I think It's just from inexperienced dev.
@@fathirirhas3609 “It's just from inexperienced dev.“ - But that's the point. There're always new programmers who screw your code and rust stops them from making faults rather than Go which makes you hope a critical error doesn't pop up from a niche situation on product presentation.
@@fathirirhas3609 They say experienced devs don't make mistakes. It's possible only when there's no way you can make a mistake. Using language with poor type system (C#, Java, C++, Go) will inevitably lead to some bugs in the future. On the other hand language with strong type system (Rust, Haskell) will eliminate mistakes by design. It's called `soundness`. You write your strongly typed code and know you won't ever debug it. You know noone ever will misuse it. You won't forget to dispose some resources. Code won't break when you will add new feature. There's no bugs after refactoring. You just code and it just works.
@@Youkakun Go has lower entry barrier and low learning curve for beginner. So beginners have lower chance of screwing code than in Rust. If you read in many testimony from companies who have adopted Go, they admit how Go is friendly to beginners, and also satisfying to experienced ones. Im not sure what kind of beginner of screwing code so bad, there's far more chance he/she will screw in Rust too.
@@mrPsyx0 Experienced Devs do make mistakes, it's lesser in Go. Are you some kind of expert saying those languages have poor type system?, Go is strongly typed languages in every references I read. I never bashed Rust, I know it's great language with great performance. But I'm tired seeing programmers are bashing other language, while he never/rarely used it and also inexperienced with it. From your statement, it's clearly stated that you somewhat never/rarely or even inexperienced dev. How can your program will be buggy, while beginner already creating things and run smoothly in their first tries. No offense, but this clearly come from inexperienced dev.
This is an excellent summary of both languages.
Thanks!
Go provides simplicity, unparalleled tooling, an excellent standard library, and insanely fast compile times that gives you rapid iterative development experience. The current iteration of the Go GC runs in parallel and the portion that causes pauses can be measured in nanoseconds.
I haven't played with Rust yet since getting buy-in is way harder. However from everything I hear Go will get you to the complex errors faster, while Rust would help you resolve those errors faster if and when you reach them.
Took me maybe week to learn rust, and since then I have been working on 2 projects a REST server for a social media website, and a Game server for low latency high player count systems in unity. They have both been a blast to work on and honestly once you understand the language I find I really don't need stack overflow and debugging is minimal in rust compared to even me working in python. Rust is really weird but awesome when it comes to development speed, it honestly feels faster than python which shouldn't be a thing, it feels high level, but i am counting functions in the nano seconds. Id really suggest trying rust, I have used django and flask for REST, and I wont be going back to those after using rust
I definitely agree with you!
Can you share your repo?
In the performance comparison at the and, you talk about CPU bound vs IO bound operations without using the name. ;)
IO bound applications benefit greatly from some sort of parallelism, so your server doesn't block a whole thread while waiting for a database call or whatever. I'm not here to bash Go in any way, and from what I hear Go's concurrency model is one of the language's strongest suits. But as you say yourself, Rust shines here even more because of its strong compile time guarantees where the compiler catches the most common errors in multi threaded programming before they even get executed. And as everybody can confirm who ever tried to do concurrency in a language like Java, those bugs are among the nastiest you can have, as they happen so erratically.
Therefore, I'd take a language as superior in which you can do concurrency in a safe manner - yet you're right, it comes at a cost, which is the learning curve.
Agree! :)
You get a thumbs up just for the awesome intro. Love Your Work
Thanks :)
Loved the video..
I wanted to learn systems programming improving OS and tweaking libraries and all I was confused wether to choose Rust or Go
But after watching this video I’m gonna go with rust
For that use-case, Rust is definitely the best choice :)
Loved this summary. Thank you so much!!!
I see go as a great language and a warmup for my transition from py/js to rust
By the way, I use C++
i use nasm, normie
@@ahsan_a Well said
poor you
@ozone o3 what has UI to do with OOP?
What's your problem with Dependency injection?
Wow, I really like the quality of content. Subscribed :D Topic is really nice presented.
Thank you :)
Learning Go right now but will definitely be learning Rust next.
If you jump from one language to another, you aren't really gonna learn either of them. What you need is a project. And who know how long that project may take? By the end of it there might even be a new language built by Ai that's just too good to skip
Hey I had that same robot when I was a child the one on the left. Do you maybe know how can I buy it? :D
Here we go :) wowwee.com/robosapien-x
Very helpful. It helped me take a very educated decision and stick to JavaScript.
The bad ending
4:17 Rust compiler doesn't produce static binary by default if it's using libc as target. A lot of crates don't work with MUSL libc as a target, so the claim about producing "static binary" compared to Go does not hold really.
You're definitely right! thank you for pointing that out :)
In simpler terms
Go is python with rocket boosters and nitro
Rust is C without legacy code(C's decades old compatible code) and reduces the ways to mess your program.
and then you have kotlin native, which takes the cake
Go is by no means similar to Python. I work as a data engineer and I would probably loose my fucking mind over having to work with Go. It's great for web backend or CLI-s but I definitely wouldn't use it in the same contexts as Python. To me it seems more like a smarter version of Pascal than anything else.
I would say that Go is like a 21st century version of C.
@@davidowens9597 nope, Go is very different, it has runtime, has garbage collector, has a little OOP mess around, can't call C directly. Compare to Rust which can use anywhere C exist
@@hailuong9295 Right. That's why I said it was a 21st century version of C. It's like C with modern features like garbage collection added.
One of the creators of Go, Ken Thompson, was also a co-creator of the B language, which was expanded to become the C programming language.
Not to mention, Rust can be programmed on bare metal embedded systems such as STM32 microcontrollers.
both
Just started go coming from node and love it and it’s take about a week to get around most concepts. That is true. It took days.
Hmmmm got me thinking I need to do a personal small project in rust.
You will not regret it :) also, rust is great to write native node modules
@@FedericoTerzi so I am! I’m still gonna help a close family member out with their company site and use go (the built in http library is pretty decent ) with react
BUT I’ve been wanting a better way to find TH-cam channels I’m subbed to and gonna build a backend with rust to a fire stick app to organize my yt videos better.
Thanks for your channel gonna go thru it on my walk today if I can ever get my pulled hamstring healed lol (I’m on the floor painful morning lol)
Sounds great! Good luck with your recovery :)
that intro was the best thing I've seen in 2021
Glad you liked it :)
I don’t understand why people insist on comparing Rust with Go. They are such wildly different languages, and their performance isn’t even that similar. My guess is that they just happen to be interesting & popular languages that arrived on the scene around the same time. But that doesn’t mean anything in terms of their similarities.
If the answer is “they can both be used for writing web servers,” then why not include literally every other language, like Clojure, or Pascal, or C? It’s really not a good criteria for grouping languages IMO.
I definitely agree with you, they are very different languages, designed with different goals in mind. That said, why not compare them? Languages are nothing more than tools, and the more we spread information about their differences (and ideal use cases), the less fights we get over which of them is better than the other. Instead of "which", people should ask themselves "when" to use them :)
Federico Terzi that’s fair, but this is hardly the first comparison between Rust and Go, and it’s clearly a trendy comparison to make. My point isn’t that we shouldn’t compare them, it’s that there is a huge number of people who think of these languages as inhabiting the same space, and it’s genuinely weird.
Like it would be weird to act as if Ruby and C are related & worth comparing, aside from them both being languages at all. That’s how I feel about Rust and Go. It’s just apples and oranges...
To be fair, the difference is obvious only once you document yourself :)
Federico Terzi to be fair, at least you’re being fair ;)
In web development as long as the main cost is engineers' salaries then languages like Go are the tools to use, when the platform bill overcomes those costs then it is time to switch to a more performant language. As long as the requirements are met nobody cares if your app is a few ms faster.
To say that Rust has manual memory management is not strictly correct. It doesn't by default. It automatically handles memory, but not using garbage collection.
For backend for a Flutter mobile application, Will you prefer Go vs Node js ?
Node + Typescript is usually a safe bet :)
You deserved the like just for the intro.
Thanks! Glad you liked it :)
Debugging and interop support with c/c++. Would good to know.
As far as my experience goes, the debugging situation is pretty good on Linux, less on Windows
Hi!
For shellscripting, is Golang better at that?
"Always use the right tools for the job" perfect conclusion
its a tautology with no real information content, and often used to reinforce the idea that all tools have a use. probably some tools are just bad! though i don’t think Go or Rust are bad
@Jack Mott I don't agree with your comment. Yes some tools are just bad and we shouldn't use them, that's why we should use the right tools, not all tools
@@dylanadc4403 I want to know if I should use Rust or Go. Someone tells me "use the right tool for the job". I still don't know what to do. No information is imparted. What tool is right for what job is the question everyone has. And we have no rigorous answers!
@@JackMott I understand what you mean but it depends! It depends of your needs, of your time, of your project... As he said in the video, Go is better for web services and Rust for high performance applications but both tools are good in general. As engineer we need to know these different tools, so we can make choices about it
@@dylanadc4403 you still have no answer for the question. Probably most devs don't know "the right tool for the job". This is just a phrase that people repeat over and over again.
Nowadays with all the code that exist all the problems can be solved by most programming languages. I'd pick rust a thousand times though just because of what it stands for and how comparable it is to both old low level languages and new more abstract ones.
I think there's a typo at 1:45. It should be
let sublist = list.filter(x => x % 2 == 0)
Perfect video and your english is amazing. I'm not a native en speaker, and I usually have problems in order to undestand every word that I hear but you talk perfect. Nice video!
Thanks! :)
Something that you missed is that the reason Rust is more popular for FE web development is because the Go runtime is a whopping 1.3 MB -- excluding it from many FE usecases outright. Rust on the other hand is closer to 10kb
Not to mention the Go GC, while fantastic for most cases, can conflict with the JS GC and cause a lot of trouble
Rust is cool, I just started developing a new service with it. One thing I didn't like so far is that most tutorials or examples skip the unit testing part or just do very basic unit tests without any mocks. It took me a while to figure out how to unit test my database access stuff.
If you want to know more about that subject, everyone recommends the "Zero to Production" book, which deeply covers this subject :)
Top Quality Opening Intro
As an architect, and with Microservices, a team or individual can pick the language and technical stack they want for their problem. As you say, Go is for concurrency and Rust is for system level and performance intensive application. I know Java, Typescript, R and Python3. If you see R programs they are memory intensive but concise whereas python is more descriptive yet faster.
Definitely! In fact, microservices were introduced mostly as an organizational tool, as different teams can work (mostly) independently from each other
Very nice, clear and interesting overview. I'd like to post one question: which language do you evaluate better for industrial automation or embedded devices, where the most important requirement is real time performance, reading inputs from sensors and driving HW outpus? Thanks
Thanks! I don't have any experience in that area, so my opinion doesn't really matter. In that space, probably the good old C, C++, Zig and Rust are the best choices
@@FedericoTerzi C, C++ and Python have well known and longly tested history in this fields. My question is related to some innovative application, as for example in IOT. Anyway: thanks again for your video!
How is ist possible to have a garbage collector without Running in a VM? Is it possible to staticly add all the Code For GC at Compile time?
Of course! A garbage collector can be seens as a piece of code that runs on a separate thread and periodically scans the references to free the unused memory. You don't need a VM for any of this :)
I'm trying to decide, I don't want to learn both, but I want a language that is fast for game dev and has a quick compile time. Go's got a garbage collector, which kills runtime performance, but Rust's compiler is so damned slow. I wonder, is it getting quicker? Maybe they could introduce a 'design time' mode that is quicker.
In the deployment part, did you mean "ahead of time" in the place of "static"?
A different choice of words might have been better, with "static binaries" I meant "statically linked binaries", which is the case in Go but not in Rust (by default), which produces dinamically linked binaries instead. Sorry for that :)
@@FedericoTerzi Hmm, I didn't know rust used shared libraries by default. Thanks for that.
I didn't know as well! One of the viewers pointed that out in the comments: doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html
i'm finding alot of people with the same name as me holy shit
Thank you handsome prpgramming mam, keep it up.
I enjoyed your easy-going, hospitable demeanor
Thanks!
Really interesting! Thank you!
Thanks :)
THis man deserves a subscritber
In Italy both of these language are not popular yet.. is very hard to find a company that use go, even harder for rust!
That's true indeed! I think that it mainly has to do with the fact that most programming here is done for enterprises, which are always slow to adapt to new technologies (in fact it's even hard to find something not Java/ C++ or .NET related...). If you move to the startup ecosystem though, things get more interesting :)
Also, nowadays remote work is growing pretty strong, which opens up a ton of possibilities (for example, I'm working part-time as a Rust consultant for a foreign company)
@@FedericoTerzi yes I agree. The only way is to work with foreign companies expecially the american ones.
@@superzazzaful Agree, that would be the ideal situation! Hopefully as time goes by this will be easier and easier
lavoravo con java 8 e spring boot, ho cambiato lavoro e adesso sto in ballo con le jsf e java 6, rip me...non è possibile che in italia è solo java/c++, quasi quasi passo a fare front end
@@sharkpyro93 settore web(in Italia) php è ancora fortissimo, tra l'altro vorrei aggiungere che da noi c'è molta confusione e incertezza se puntare o no su nuove tecnologie, non si trovano praticamente nessuna richiesta per rust, go.. a malapena si trovano full stack Javascript.. Come già detto in precedenza dal collega molto meglio lavorare con aziende estere piuttosto che quelle nostrane
Don't waste your time on these time consuming comments!!! Just watch the video it's pretty straight forward. Didn't intended to make who is a winner, but where you should use each of the language. And that's is pretty awesome! Somehow the title of the video is misleading.
Great comparison Federico! Esp. funny intro xD
Thanks :)
He Federico. Hope all is well. Is Terzi an Italian word? We have it in Turkish, too. Maybe it's a loan word from Italian. It means tailor.
Hey, yes "Terzi" in italian means "thirds", like with fractions :)
@@FedericoTerzi thanks for replying. It makes sense to me :) have a good day.
Which one is better for os kernel development..?
Definitely Rust, and there are some efforts to bring the language to the linux kernel project: lwn.net/Articles/829858/
Does your robosapien still work?
Kind of :D
All the points you make are not very strong arguments and I’d even say pretty poor.
The first problem of your points is that idea that Go is easier to read than Rust. Before stating something like that, you should define the axis you use to quantify “easy to read.” For instance, I find Rust, Haskell and functional programming languages much easier to read than Python, Go or similar languages. My way of seeing it is: “Do I need to learn about the context / other lines of code to understand this line of code?” For that matter, Rust is much simpler and easier to read than Go, especially because Go lacks algebraic types, and the error mechanism is just super hard to “read through” compared to Option / Result from Rust.
When you talk about scaling programs in a team, I wonder if you’ve really worked on a big Go project with various and different people of different skills. The compiler doesn’t know as much as what you do as in Rust, especially when it boils down to error management. The way Go makes things work leads to hard to maintain, reason about and read code. On the other side, the entry-bar to understand Rust is hard, but once you understand the language, maintaining a Rust code base scales much much better, especially as the team and project grow.
Another problem is when you talk about memory safety. You’re using a fallacious argument stating that Rust’s memory model is “manual”, but that’s not true. No one really allocates memory. The memory in Rust is handled by, mostly, owned data, such as reference counting structure (Rc / Arc), boxed data types (Box / Vec / any collection), etc. Rust has a mechanism a bit akin to RAII (Drop) which is “somewhat” similar to destructors, but more “type-safe”. On the other side, Go has pointers and null pointers. It is _very_ easy to trigger a segfault from a Go program, while, in “safe” Rust, it’s not as easy. You say you have “to be careful when using Rust.” Eh?! Unless you are using unsafe (which you shouldn’t, unless writing a low-level library), using collections from the standard library or even boxed types (which hold data on the heap), there’s no easy way to trigger a double-free, use after free, dangling pointer or anything of that kind. Most of the time, in Rust, we worry more about the number of allocations / the allocation scheme we use rather than safety because, well, rustc already has our back. You can’t say the same thing with Go. The terms you should have used instead of “manual” and “automatic” are “nonmanaged” and “managed.”
For the web development, I guess you are right. This is something that has been a big topic in the Rust community and it’s getting better, but I guess I would advise people to use other languages than Rust so far for web development (I personally use servant, a Haskell library, but Go should be okay too).
Thanks
I appreciate your opinion, even though I don't agree with all your points. I understand that in a couple of instances, a different choice of wording might have been easier, but most of my points were the results of combining various articles and sources, so they are by no means only based on my personal opinion. To answer your points:
> The first problem of your points is that idea that Go is easier to read than Rust. Before stating something like that, you should define the axis you use to quantify “easy to read.” For instance, I find Rust, Haskell and functional programming languages much easier to read than Python, Go or similar languages. My way of seeing it is: “Do I need to learn about the context / other lines of code to understand this line of code?” For that matter, Rust is much simpler and easier to read than Go, especially because Go lacks algebraic types, and the error mechanism is just super hard to “read through” compared to Option / Result from Rust.
From what I understand, you are an experienced developer, especially used to Functional languages. While I agree on the fact that Rust can be a very expressive language, it's only easy to understand once you grasp the fundamentals. I'm sorry to say this, but I find your argument "Rust and Haskell are much easier to read than Python and Go" highly subjective. Ask a beginner to read a Python program and then a Haskell program, I'm sure he/she won't find the latter easier to understand.
My point was that in Go it's easier to get started, as it's easy to read and easy to write, which has nothing to do with your argument. Saying that it's easier to get started in Rust is just plain wrong.
> When you talk about scaling programs in a team, I wonder if you’ve really worked on a big Go project with various and different people of different skills. The compiler doesn’t know as much as what you do as in Rust, especially when it boils down to error management. The way Go makes things work leads to hard to maintain, reason about and read code. On the other side, the entry-bar to understand Rust is hard, but once you understand the language, maintaining a Rust code base scales much much better, especially as the team and project grow.
Many people argue that "Go is about suppressing complexity at scale", see: kristoff.it/blog/why-go-and-not-rust/
I prefer Rust as well, but I wanted to cover both sides of the argument.
> Another problem is when you talk about memory safety. You’re using a fallacious argument stating that Rust’s memory model is “manual”, but that’s not true. No one really allocates memory. The memory in Rust is handled by, mostly, owned data, such as reference counting structure (Rc / Arc), boxed data types (Box / Vec / any collection), etc. Rust has a mechanism a bit akin to RAII (Drop) which is “somewhat” similar to destructors, but more “type-safe”. On the other side, Go has pointers and null pointers. It is very easy to trigger a segfault from a Go program, while, in “safe” Rust, it’s not as easy. You say you have “to be careful when using Rust.” Eh?! Unless you are using unsafe (which you shouldn’t, unless writing a low-level library), using collections from the standard library or even boxed types (which hold data on the heap), there’s no easy way to trigger a double-free, use after free, dangling pointer or anything of that kind. Most of the time, in Rust, we worry more about the number of allocations / the allocation scheme we use rather than safety because, well, rustc already has our back. You can’t say the same thing with Go. The terms you should have used instead of “manual” and “automatic” are “nonmanaged” and “managed.”
Here I tend to agree more with you. I received some criticism for my choice of words, and I can understand why. I'll paste my other answer here:
Good point, perhaps "manual memory management based on ownership and borrowing" wasn't the best way to describe it. That said, I did my research before making the video, and many developers described the process as manual (see: pcwalton.github.io/2013/03/18/an-overview-of-memory-management-in-rust.html).
It really comes down to how you define "manual", do you have to call free() to have a manual memory management system? I could argue that by just deciding where the scope of the variable ends, you decide how long that chunk of data will stay in memory (as you just get an implicit free() call when out of scope), therefore making it manual.
Regarding the "be careful when using rust" I'll paste another answer:
You're absolutely right, but my point was slightly different: when I say "be careful about memory management", I mean that you have to actually think about memory management in Rust, whereas in GC languages you (generally) don't. For example, in Rust you can have ~6 different types of references, which means you have to actively think about the best way to handle resource lifetimes when developing (see the "Complexity" paragraph for an example: matklad.github.io/2020/09/20/why-not-rust.html )
I understand that "be careful" might not be the best choice, I'm sorry about that.
Then, of course, we can have different opinions and still live a happy life :)
Though I think from my experience with actix, flask, Starlette, express and Django. Actix-web and Rocket are mature for their context and are not lacking performance/ features, e.g. HTTP/X support, Data handling, Routing and Integrations (diesel, askama ...).
The ecosystem is generally not as mature as Go (overall) but the general things you need e.g. tokio, actix, sodiumoxide or non-std libs are pretty mature and supported.
Rust is not a functional programming language , it does have characteristics from a functional programming language.
Love both Go and Rust. I'm mostly a programmer dabber, then a very good one. I just enjoy learning at my pace, just to do the simple things. Jack of all trades, master of none. Only programming language I can say I really know is Lua. But I'm learning Python, C and Javascript. Which Javascript is the second one I can say I'm getting to know very well. I dab in many other's, but I say I'm the strongest of the one's I mention here. Not sure if I'm going to be good at all of them. But I'm going to give it my all for sure.
when u said go is a good solution for web service, so why with rust we have actix or axum ?
One does not exclude the other :) You _can_ write a web service in Rust, I just don't think the performance improvements justify the less mature ecosystem and ergonomics compared to Node+Typescript or Go for most systems
@@FedericoTerzi so to build a better web server must to use go (gin) instead of rust (axum, actix..etc) ?? i am try to understand more your opinion
Correct: Go was designed to replace C++. Per Rob Pike. C++ developers didn't bite however.
which is better, a dishwasher or a washing machine?
A dishwashing maschine 👍
Just a correction, rust does not "provenly" guarantee thread safety. It's not proven in a mathematical term, so it's still possible to run into concurrency, dead locks, etc when using rust. It's just harder to get into those when using rust vs other languages.
Indeed! Though one might argue that it's very hard to prove a program runtime "mathematically", as there are a number of assumptions we are making about hardware not failing which are not really provable (even just a cosmic ray could cause a bit flip in a real system)
@@FedericoTerzi I meant a compiler theory point of view. The compiler provenly guarantees syntax correctness for instance, it's impossible to compile if the syntax is wrong. But it's still not proven that any rust program that compiles is thread safe.
Interesting, thanks for sharing!
@@FedericoTerzi there is still a benefit in rust tough, because if you fall into some edge case where you run into thread safety issues, then the rust compiler team would take it as a bug in the compiler. As opposed to C++ or other languages where you'll be on your own.
thank you! very nice and neat video!
Thanks! :)
Low key if you turned those cutouts in the intro into stickers, I would buy it.
Nice idea! Will look into it :D
Thanks for sharing. Very informative
Thank you!
Python doesn't traditionally use a garbage collector while it rather uses reference counting internally. It's somewhat similar to if you were to wrap everything into a std::shared_ptr in C++.
Yep, my choice of words there wasn't great... Python use a combination of reference counting (the main mechanism) and garbage collection (to handle circular references)
I like Rust because its biult to be really low lever, but with third party crates you can create robust desktop apps. I made a Geometry Dash macro clickbot that places clicks wherever a macro clicks, then spits out a .wav file. 12 thousand clicks per second, and it only took 1 second to finish. With many crates adding features present in high level languages, its possible to build great things with Rust.
Rust does not have manual memory management by default, the ownership system manages the memory for you. The Rust compiler isn’t “very good at catching memory errors”, it makes it *impossible* to have memory errors or memory-related security vulnerabilities so long as you’re following the ownership rules.
There is an area of Rust called unsafe Rust that lets you manage memory by hand, but it’s highly recommended that you avoid using it as much as possible.
Good point, perhaps "manual memory management based on ownership and borrowing" wasn't the best way to describe it. That said, I did my research before making the video, and many developers described the process as manual (see: pcwalton.github.io/2013/03/18/an-overview-of-memory-management-in-rust.html).
It really comes down to how you define "manual", do you have to call free() to have a manual memory management system? I could argue that by just deciding where the scope of the variable ends, you decide how long that chunk of data will stay in memory (as you just get an implicit free() call when out of scope), therefore making it manual.
Regarding the second part, I always prefer to avoid strong claims such as "impossible", as we live in a complex world :)
For example, most of the standard Rust library is built on top of unsafe blocks, so (in very very rare circumstances), you could still get a memory error even if you never used unsafe yourself.
Saying that it's impossible to have memory errors is pretty much the same as claiming that a program is completely bug-free, hard to say :)
If you consider memory leak a memory error, then no, Rust still has memory leaks, which are much less frequent with a garbage collector. That said Rust also has race conditions, as documented here: doc.rust-lang.org/nomicon/races.html. The only thing it prevents is memory corruption of a certain specific family, but not all of them.
@@FedericoTerzi "you just get an implicit free() call"
That's pretty much what garbage collector or reference counting does.
Could someone compare Kotlin native vs Rust? As I understand both use LLVM.
I would rather compare it to Go because it's also a GCed language and there are a lot of similar concepts (the approaches to syntax are a lot different though) like Goroutines and Kotlin Coroutines. Syntactically Kotlin might be closer to Rust actually but from a usecase POV it's a lot closer to Go.
What compiler backend they are using (which is what LLVM is) is basically irrelevant for the end user and just because two languages use LLVM as a backend it doesn't really mean that they have anything in common.
@@meamzcs Java and clojure also do not have anything in common but people still compare those because both have jvm as a backend and can use the same libraries. In the same way, I expected that LLVM should allow sharing libraries between rust and kotlin native.
@@meamzcs agree
@@yatsuk Nope. That doesn't work. What the JVM thing would translate to for LLVM is roughly "both compile to x86"... Whether it's using LLVM or something else as the backend is essentially an irrelevant implementation detail. It's basically comparing two programs just because they have one library in common... Which is what LLVM is: a library...
LLVM is nothing like the JVM. The JVM is a compilation target that runs software at runtime. LLVM is a library that takes a standardized internal representation and can then transform it to machinecode in all of the ISAs it supports at compile time...
It makes sense to compare JVM languages to one another because they all have kind of the same limitations imposed by the JVM and therefore can all be used in roughly the same usecases.
Why every one try to move to new language like Go & Rust When Java can do the same and have good performance (appreciate if someone can explain that and what is the difference between them , I'm beginner ?
Very good video
Awesome comparision. Subbed 🥰
Thanks :)
both docker and kubernetes are written in go. i wouldn't call those simple or small apps/services
Fair point!
Here blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f is a significant deployment originally done in Go, which they are switching to Rust.
@@lawrencedoliveiro9104 rare case. The exception confirms the rule. He does not deny it.
Also consider that the Linux kernel developers are considering allowing Rust code to be included. But not Go.
Also, this: www.zdnet.com/article/microsoft-why-we-used-programming-language-rust-over-go-for-webassembly-on-kubernetes-app/
Though kubernetes devs had to reinvent objects due to exponentially growing complexity of the system just to ease it a little. Lack of language expression made them suffer a lot.
That's the point: easy languages only suitable for easy tasks. Take Python and Go. They are really easy to start. They are hiding a lot of problems from you. It's pleasant to develop small apps when your brain is still capable to grasp all project structure and you remember all caveats. When your project will grow to the size your brain can't handle you will notice some problems appearing.
I never realized this channel is owned by the espanso's developer!! Dude you are awesome!!
Edit: I am surprised that you didn’t advocate Rust considering espanso is one of the best of program written in rust.
Thanks! :) Well, I wanted to keep the video as fair as possible, even though I prefer Rust :)
After sometimes using Go, I realized how unsuitable Go for backend services are. Go is so simple it's lacking. It lacks many language features exist in other languages to power you up writing backend business logic. If you look at many great companies employing Go, they are not employing it for writing their core system or business logic, but instead they're employing it for tooling their infrastructure and devops. Then I ask my self: "Who write business logic in Go?", The more proper usage of Go are in realm of tooling supporting your core system, infra, and devops, it also great for serverless arch, load balancing, and worker, But for the core system/services I prefer Rust over Go now and planning investing in Rust for now.
and how did it pay off?
Hi bro. how is it going?
its been 2 years i wonder how is the comment in rust for web api
Is there some proper dependency management yet for Go?
The compiler itself already done that, so...
@@hailuong9295 I don't think so
I’m surprised you didn’t share your thoughts on the security of code in both languages.
I want to stick those on my laptop on each side