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
10 месяцев назад
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 :)
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 :)
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
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.
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.
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.
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.
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.
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
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.
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).
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.
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...
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
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.
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.
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
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.
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.
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
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.
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
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.
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
@@dylanaudic4403 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
@@dylanaudic4403 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.
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.
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.
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.
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.
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!
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.
Stick to C++ for system level tasks & Go for networking & or concurrency (as it's super easy). Most of the comments here are from frontend developers that have a superficial understanding of Rust & zero experience or knowledge of system level programming or Unix.
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 RU-vid 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)
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.
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.
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.
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
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.
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.
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!
An option not usually discussed is that Go’s GC can be turned off. Use stack memory via escape analysis and disable GC should allow Go to have very similar behavior. I have used Go for 7 yrs and love it. I have also used Rust but it is extremely annoying for more complex apps. I am not a Rust hater. I hope they make Rust better as well and get a real corporate sponsor. No substitute for having an army of devs to ensure success.
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.
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
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.
I go C# for high level and Rust whenever I need something lower, they’re both dealing with WASM very often so they’ll both be very relevant in the future
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.
Go's Powerful coroutine support can make it fast also and In Go a simple program can be fast you don't need heavy optimization and there are services like cockroach db dgraph docker and kubernetes are made in Go
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)
You don't need generic thank to go interface. Thus said generic is supported in Go since version 1.8 and it works pretty well even though is not recommended to use in production.
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 ?
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.
Your stuff was interesting, based on your comments on how programming in rust is a very pleasant experience, I've decided to learn it. You're doing a lot of cuts while you're moving your hands. I usually don't notice when video creator cut the pauses out of their video but it was enough to distract me with this one.
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 found Nim to be better than both. Let's talk about this again in 2021-22. Nim v1 was released in 2019. So, let's wait a few more years and I would love to see this discussion again. Plus JavaScript backend comes out of the box and just works. Anyways, sorry for being out of context. Out of the two. I will choose Rust over Go personally. Cargo and C ABI is something I love. Plus it has so many less runtime errors! But yeah. It is more verbose and hard to learn!
I heard good things about Nim as well! As you said, it's probably too early to make any conclusion about its future, but we'll stay tuned :) I prefer Rust over Go as well, but it mainly depends on what you have to do... Cheers :)
@@FedericoTerzi There are so many choices today. It makes everyone confused! I am also in future gonna give you one in this case. Lol. working on something called ekscript.com (Shameless Plug!) BTW Your videos are awesome. I recommend every Rust beginner to your channel. Keep up the good work!
@@himujjalupadhyaya4296 That's impressive! Great work, seems very promising :) > BTW Your videos are awesome. I recommend every Rust beginner to your channel. Thank you :)
@@meamzcs GC is the default. You can opt out of GC and get manual if you want. Also there is the option of opting into an implementation of ARC that also handles Cyclic references. I found cyclic referencing a mess in Rust due to my Rust inexperience.
