Golang vs. Rust: Which is Better?
Vložit
- čas přidán 8. 12. 2022
- Only one programming language shall take the throne as the best language to rule them all! Jokes aside, today we'll compare Golang and Rust in various categories including market, productivity, safety, performance and ecosystem.
![Eminem - Houdini [Official Music Video]](http://i.ytimg.com/vi/22tVWwmTie8/mqdefault.jpg)
One of the things that makes your videos my favorite is unlike a lot of the trend programming channels you don't just push the "how to get a job" and "what do you need to learn next" and instead you approach talking about programming from different angles and the topics you cover actually appeal to those of us who are passionate about programming itself and arent just riding the next hype train looking for a trend
Hah, I appreciate that. I’m still kinda figuring out which style to stick to and topics to talk about. It’s a work in progress.
except that. he produces to make money of hybes. its clear that he never used both languages not to mention adressed big complex real world problems with one of those. therefor total wasted time. just learn and see it yourself.
@@crono102 With the amount of subs/views I get, it’ll be years before I’m able to monetize this channel. If you’ve seen my other videos, you’d know that literally all I do is talk about real world problems! 😂
@@codewithryan current style is what we die for
"Do i get a job with this language... "LOL , a clear sign of a mediocre developer "is there jobs for rust" ... you dont have to worry about it... because as,c,c++ devs are doing the rust work, when needed...
companies dont hire "language developers" , they hire software engineers.
I'm rust + go backend developer. I really liked the video and I liked your analysis. There are two criticisms i have here . Firstly about productivity. As you said, writing a (for example) controller probably takes longer in rust than in go. However we are not always trying to write business logic functions. We have to write a lot of tests to ensure that we got things right. Now, in rust we can use the type system to let the compiler do those things for use. Essentially we will only need the absolute logic tests and integration tests in rust. In go, type system is smaller, so we cannot rely on the type system as much. Another similar criticism goes to the collaboration. Yes rust takes time to learn. But in practice once learned, the explicit nature and the compiler + #[reject()] macros let you force those coworkers that think of themselves as 10x developers to slow down and write an actually decent code with you having to stand over their heads.
Another thing to mention is that go is just breath to deploy. It gives easy access to statically compiled libraries while Rust does not yet do as well. This, particularly, caused me a lot of headaches when working with docker images.
Other than this, I have nothing but respect for an actually great comparison. Practical criteras that actually matter with good definition for each.
Those are great points!
i wanna learn Rust after reading these points, thanks man
I'm confused, you try to make a point about rust being slower and how that could be misguided. Only to say that it's slower but its a good thing because it forces them to write good code?
I'm sure Rust is fine and dandy, but let's be real. Golang is just where it's at if you're a backend developer. Writing rust code for backend is feasible but it will hold you back in development speed. No way around that. Then as a product owner or engineering manager, you have to decide if that speed gain you get will be worth it against Golang and its already fast speed plus concurrency model.
@@alexandrep4913 now, I have been the sole backend software engineer in an startup and have developed in both rust and go. And compared my own productivity in both rust and go. The thing about go's productivity when compared to rust is that if you want to have the same amount of guarantee as the Go product, you actually can do, using a looser error handling like anyways which is more similar to go's and cloning stuff. But rust offers a lot more to be done, which means that you can do much better, and that takes a bit more at the first two months of the project. But later on in the project, if you had taken the time and built a solid foundation in rust, you are much more productive because of the vast amount of robust abstractions that you have written earlier. Go takes a more constant approach. Which is that you are as productive in the beginning as you are in the middle and in the end. Which is still awesome when you compare it with a nodejs or python backend. And it is very much intentional. The whole idea of readability and clarity is because of this. You need to come back times and times again in Go. And that's more than fine. But for rust, I can confidently say that when I'm satisfied with a function, and call it stable, I am 90% sure that I will not need anything more than the function signature any more. My last project had 125 end points , all in go. It was really hard to handle all the little changes and bugs that came up. Seeing that for each bug i had to navigate a huge amount of abstractions and boiler plate codes and ... In rust I made a prototype for myself on the weekends with less than half of the time and with half of backend engineers and managed to write 90% of controllers.
I hope it helped.
i watched some channel yesterday, the guy explained the big gaps in rust, why it feels super confusing.
borrowing ,lifetimes,referendes.. and special pointers ...
now it doesnt feel any different than any other language.
he gave good advice to new people who want to learn rust as well... dont do any references at all... rust is x80 faster than python, its unlikely you have performance issues
clone/copy everything.. later you will slowly learn references etc and it will be easier...
As a hobbyist programmer, mostly making games and dumb stuff, rust really helped me. The "freedom" most languages give you, like Go's "handle safety through good practice and patterns", without actually giving you a hint on how it's done, is really hard to grasp as a beginner. I'd often get caught on **how** I should write / structure a project, and rust was quite straightforward for me. I could even read other people's libraries (the source code, I mean) and understand them, something I'd struggle with before. It just feels like everyone is on the same page? I don't know how to explain 😅.
I didn’t think about it from a beginner standpoint, but that’s a good point. Rust does provide more explicit guidelines than other languages, like best practices are “built into” Rust.
3:55 Even though you have to worry about a value going out of scope in rust, the compiler will always tell you that happens and wouldn't actually compile, so yeah compile-time safety is there. Also like Go, Rust can also be used to do high level stuff like backend development(in actix), game engines(bevy) and also webgl.
I enjoy how you've kept it real with a decent, all-round analysis, and communicated it clearly and correctly. Thank you for the video.
I see two mindsets.
1. Get it to market asap
2. Get it right the first time
I’m more the latter…
Boom! You understand.
As someone who has decided to abandon Go for Rust, I find myself completely agreeing with you at 4:10 -- I didn't leave Go because Rust was easier, but because Go was limited in capabilities. I'll still probably use it for middleware or other systems programming that isn't long running / performant, but my focus is now on Rust. I use Kotlin and Swift in my work currently, so I may be biased to functional languages.
I actually abandoned Go for the lack of capabilities as well. Gave Rust a try and was blown. I don't need a huge amount of performance for the apps we're building (CLI tools) but the compiler capabilities and the advanced safety features of the language convinced me. I'll probably still use go for minor pieces of work but anything that requires some real code written i'll stick to Rust
@@SM-sb4tr lack of capabilities ? Which ones ?
@@michelvandermeiren8661 no spring boot, no django, no micronaut, no ktor.
Golang lacks a good backend framework
@@darthvader8144 That's what i heard from very experienced programmers (8-15 yoe). They say that go is too easy and if u want to do harder more advanced stuff it's impossible, or you need to use some hax to do it.
@@RaZziaN1 There are reasons not to use Go (for example, it's not the right language to write operating systems or device drivers, it was not designed to do such things), but "it's too easy and not advanced enough" is not a reason in itself.
On Go's official website:
« Go is a programming language designed by Google to help solve Google's problems, and Google has big problems. The hardware is big and the software is big. There are many millions of lines of software, with servers mostly in C++ and lots of Java and Python for the other pieces. Thousands of engineers work on the code, at the "head" of a single tree comprising all the software, so from day to day there are significant changes to all levels of the tree. A large custom-designed distributed build system makes development at this scale feasible, but it's still big. And of course, all this software runs on zillions of machines, which are treated as a modest number of independent, networked compute clusters. »
You can see that their reasoning was not "We have big problems, thousands of engineers, many millions of lines of code running on zillions of machines, lots of changes everywhere all the time. Therefore, we need something super powerful, like Rust."
Great video and very helpful. I'm a Scrum Master and have done a lot of coordinating with our senior architects. They use Rust, and I just switch to a different group as who work on our microservices and use Go. This really helped me understand the language selection for both use cases in my company.
You deserved a thumbs up in the first minute for your structured approach to answering this question. After watching the full video, I'm able to make a confident decision. Thanks!!
Fantastically explained which no one did as of now on CZcams. Please do more videos on GO. Like generics, frameworks, advance concepts.
Well done, subscribed. Your topic points were very relevant. I didn't feel like you wasted any time with filler. Keep it up man
I have been working with Go for 4 years and with Rust for 4 years.
After the initial 6-8 months, you will become as productive, if not more, with Rust than Go.
The reason is you don't need to write longwinded code because you have macros and a very flexible type system.
After you get good at Rust, there is absolutely no technical reason to use Go.
I guess, the only reason is if you can't actually find a job with Rust.
But it looks like that is changing.
yeah, if you are writing small peace of software, but microservices and corporate stuff, rust is a pain
You have a pretty interesting background. Have your experiences been the same for writing concurrent and distributed systems?
@@raianmr2843 yes. Rust is better in every way. The penalty is developers need to have higher expertise.
@@donateus6743 I can have a microservice running in less than 20 lines of code, in Rust. What are you referring to?
Heyo! Wanted to point out a couple things from Rust side. A lot of times people try to write Java/Go/etc in Rust, which obviously bogs you down. Often times, I found I should change my approach a bit in how I write the code. In fact, porting some Go code into Rust was one of my first "serious" things to learn Rust! And I needed multiple passes of refactoring to really make it look like Rust.
Also, this is likely mostly for a demo purpose, but writing in case, code like the nested structs example (or the error handling example too) can have neater ways to write! But it does take a while to get there, or to explain.
I work with Rust on web apis among other things too, and it can be pretty neat! All the strict typing helps enforce your input as well! Plus serde is nice.
I feel like Rust is generally high level and gives you a lot of abstractions, while not hiding the details when needed.
Good comparison! The purpose of each language has become clearer. Thank you! 👍
Awesome!!! Please keep this channel running. Trust me this comes naturally to you and millions will love to learn from you.
Great content bro tks a lot ... best video of comparison of these two languages I ever saw
wonderful comparison, objective and unbiased. very well-done!
I've written a lot of Go both professionally and as a hobby and on the point of safety I do agree that the language falls short of what Rust offers out of the box, but following the principles of Effective Go and having a requirement for code being linted eliminates most of that class of bugs: you can't forget to check for an error when your IDE is underlining it and errcheck is refusing to let your CI pipeline proceed to the build step.
javascript can be linted and checked at CI step.
I hate javascript
@@CuriousSpypractically everyone who has coded in more than 10 languages hates JavaScript, and many also hate Typescript because of the issues involved with transpiling it to JavaScript and the debugging. Go, on the other hand, is like a breath of fresh air. The mere fact of surface similarities in potential CI/CD strategies says very little about the developer experience.
@@k98killer you missed the point
@@CuriousSpy looks like it. What was your point?
@@k98killer having CI linting in GO doesn't make it closer to Rust safety
Excellent video! I'm a JS dev with ~2 yrs experience exploring different languages and technologies. I would love to see more comparison videos of tools you're familiar with because these kinds of decisions are difficult to make when you're a noob in the tech world.
Something to note with ecosystem is the common licenses of available packages.
Turns out some languages tend to use permissive licenses like MIT and Apache 2.0, and some tend to use e.g. GPL.
This never really occurred to me because I use a language that has 3rd party packages that are largely MIT licensed, but the company I work for acquired another company that used another language and when we integrated all our tooling into their repos we found that they were extremely reliant on GPL libraries.
_"Things get complicated when you start to use references..."_
I think this is a poor use a structs and references, making for a poor example of using borrowed references in Rust, as whilst it's an option, and can be useful in the case of examples such as mutable and immutable iterators, on the whole, it's something which I personally aim to avoid, for two reasons, just off the top of my head:
1. Yes, it introduces syntactic complexity, as you mentioned, but also,
2. It couples the state of structs together... by doing this, it means any methods requiring a mutable reference, can't be called on the struct being referenced for the lifetimes of any struct holding references to the first struct...
In invoking this restriction, these structs now need to justify holding these references as one of their fields, rather than taking them contextually... for example:
* If you need a reference to value in a method, why can't it be passed as a parameter when the method is called?
* Does the struct encapsulate other data which is useful for informing behaviour for accessing the fields of the referenced struct? For example, mutable and immutable iterators.
* If the struct is holding a mutable reference to another struct, and they both go out of scope at the same time, if the second struct will hold exclusive access to the data of the first, why doesn't the second struct take ownership of the first, instead of holding an immutable reference?
Yes, this may demonstrate an example of complexity, but when encountering the sharp edges in Rusts language design, it's often because a designs current direction conflicts with the rules around safety which Rust enforces, and should serves as a suggestion to reconsider this design, and whether there's a more suitable option which doesn't do so...
This is one of the best prog language comparison videos I've ever seen. You go into all the practical reasons to use one or other, without getting caught up in all the "tribalism" for each. You've earned a subscriber!
Edit: And you don't delve into the performance differences too much, like a lot of other people do, when it's not even relevant for most people's use case.
Good video, wish you luck on youtube path :) Started to learn both, gonna choose Go, cause I can relate to making backends, in Rust I'm stuck with what to make, as tooling doesn't intrest me and backend in Rust is just , I dunno.
I have a small gripe about the productivity calculation because I think there is a missed angle of not just how much time it takes you to create working project but when you can "complete" the project, by complete I mean iron out the bugs that pop up when actual users start using the software, I feel it's faster to complete a project in rust after understanding the complete toolset that the rust compiler gives you to check yourself and find where problems originate. Also the idea of extending the language with macros though a bit confusing if the documentation is lacking is still a surprisingly powerful tool in the hands of talented library developers.
Hey Man, thanks for the video. One tip: You might want to lower the gain on your mic or move a bit further away, sometimes your audio gets scratchy because you are too loud for the recording settings of the mic. you should also see your audio level go into the red in whatever recording software you use when that happens.
hmm, I didn't notice that
He doesn't need to lower his gain, but he does need to use or tweak a noise compression filter to handle this
Having used both professionally and enjoy working in both of them:
Go is a race condition factory with an inconsistent language design and a community that tends to be quite dogmatic. However with its incredible standard library, cross compilation and statically linked binaries - Go is a fantastic language for writing CLI tools.
Rust's borrow checker is easy to understand but they added it to an alien language that appeals to C++ developers making it difficult to understand for anyone who comes from an application development background. However its ownership-enforced safety guarantees allow you to write multi-threaded applications without risking race conditions.
Personally, I think someone needs to create a language that is TypeScript with the Rust borrow checker and Goroutines - targeting people who want to write normal applications.
Thanks bro, the explanation is easy to understand. Keep posting the video
Also, if I wanted to start learning to code towards getting rudimentary experience with both, so I can better speak to these folks I love at my company, what would your learning path be and where would you start.
As a note:
* I have a boot camp of UI training (html, css, JavaScript)
* I have a boot camp of C# training.
* Both were going on 3 years ago.
Awesome video. Please, keep up the good work.
Rust isn't garbage collected because It does not need to be. But you DON'T have to worry about it going out of scope because Rust uses a couple of techniques for keeping track of that. One of which is reference counting. So you don't have to monitor your references manually. Rust does that tout of the box.
Fantastic comparison. Thanks
Nice sum up dude!
I liked. I shared. I subscribed.
Great video. By sheer chance I just happened to look up how the two languages compared so this video couldn't have been timed better, had I made the search an hour ago I would have missed it.
☘
Glad the video was helpful and thanks for supporting the channel!
Funnily enough, when I saw the title of your video, I thought "But what measurement could someone use to determine which language is better. Surely there are pros and cons to each." Then that was pretty much the first thing you said :)
😂
3:53 - Learning Rust is like learning playing chess... It's easy to pick up basics but then combining it all together is a bit challenging. Learning how the pieces move takes minutes, but mastering strategy is whole another level. Cheers 👍
Excellent video, but I think in the market section you could have taken WebAssembly into consideration. Rust is the go to language for WASM, and while that might not be relevant in a search of the current job market, it could be huge in a few years.
Another issue I find with rust if being too dependent with 3rd party crates.
They have the good ideology of utilizing dependencies but the recent issue with gorilla mux in Go highlighted the bad side of 3rd party dependency.
Go's approach on using sub repositories for an extended library support without it becoming a part of STD is great and my ideal solution.
Come one man, this is a great video! Thanks for it!
Would Go be a good choice to start building applications in to become a full stack or backend developer?
I'm currently a data engineer using mostly SQL and Python. I'm learning JavaScript, HTML, CSS as well.
I hear a lot of people say learn C#, Java, or Node Js instead of Go. I was hoping to get the pros and cons of learning Go for Backend/Full-stack development from some experienced Go developers like yourself.
Think in terms of ecosystems instead of languages if you're programming purely for progressing your career. Given that you're working as a data engineer, you've probably already explored Python's backend scene. If not, freecodecamp has a pretty good course on building backends with Python and FastAPI. I think you should cross this stage before delving into Go because Go's a bit of an overkill and a sludge if all you're doing is building simple crud apis.
For full-stack dev, it's important to narrow down your goals. If I'm not mistaken, most full-stack devs are freelancers or people still in the early phase of their careers doing odd jobs. For these use cases, learning a language made specifically for massively concurrent and performant servers doesn't make much sense. If you're trying to move to a more backend-focused role then yeah, Go is definitely worth the investment. But again, it's super rare to find a position where they're looking for people who've only made some simple rest apis or other beginner projects in Go. So, my personal suggestion is, explore Python's backend ecosystem first if you haven't and only then move on to Go and see what it has to offer.
This is very helpful. The parameter are clear, communication is clear, pro and const is clear. Thank you
I work in the automotive sector, where the concept of the Software Defined Vehicle is really starting to take off (pioneered by Tesla). Rust developers, IMO, are going to become much more in demand over the next few years.
Superb comparison.
One of the few channels where all the factors are consider in programing languages comparisons.
When it comes to productivity, I'm trying to teach myself every day in my spare time writing tutorials & practical projects that are easy to understand as if I'm new to programming, and I hope Rust gets more popular any time soon -- probably as popular as Java when it comes to complexity & scalability
This is absolute perfect comparision. Go and Rust can't even be compared as there use case is different. If you want to develop servers or want to be a backend engineer then go for Golang. If you want to Develop or work where you have to create OS or low level stuffs that is where you can use Rust. So in short, Golang is alternative of Java and Rust is alternative of C/C++
Performance being ignored is how we got newest Photoshop be slower on modern hardware than old Photoshop version on old hardwsre
thx man. usefull info, especially for junior Dev as me.
Useful video - thank you!
Glad it was helpful!
Subscribed. This is quality
I like the way you describe all that stuff and a bit sense of humor you provide. Cheers! Bye!
Very good and comfortable video, I like the conclusion at the end that "these languages are not really competing each other "
Great content. How about doing a Go vs Java video?
It is very pleasant to listen to your voice.
Amazing video! I agree with most of the points, except productivity. I think this one is very subjective.
It depends on a lot of factors: experience, feature richness, feature ergonomics (Java, for example, does support FFI, but it's a nightmare to work with), the software purpose (if you want to make a Linux driver, Go will not be more productive than Rust), etc, etc.
I can even give you an example based on your own provided code: if you use the “Thing struct” concurrently on Go, you are exposed to a race condition because “value” is not atomic, and “value++” internally (on the CPU) works by “reading value into register, incrementing the register value, writing from the register into the memory”. Whereas Rust will not allow you to share this data structure between multiple threads.
This means that you save some time on Go by avoiding the strictness of Rust, but if you're not careful, you may create a tough problem to solve. Data races are extremely hard to reproduce, debug and track down the root cause. You can very easily spend days just trying to reproduce the problem (and what makes it worse is that it's not reliable). In my 14YoE, Data Races and Race Conditions are the worst problems to deal with.
The point is, IMO it's not possible to define which one is more productive in a general sense as the entire picture may drastically change depending on the other elements involved.
I have a say when comparing Go vs Rust:
Go: It makes the...
EASY -> EASYER
HARD -> HARDER
Rust: It makes the...
EASY -> HARDER
HARD -> EASYER
Hey! Awesome comparison! Subscribed 🤘🏻.
Could you enlighten me about Elixir, when compared to Go?
Thanks for the sub! Sorry, I’ve never used Elixir
@@codewithryan No worries! Do you know any reliable channel so that I can find out about the similarities between these 2 langs?
I enjoyed the video, but I disagree in that most tooling is written in Go ( like Docker and K8s ) and databases are also written in Go. It's just a question of how you like to code and what headache you'd rather avoid. Do you want to have to really on your developer's you handle errors and and write tests - how important is memory safety provability to you?
Great video Bravo Thanks bro
To safety: There's unwrap(), and the ? question mark operator in Rust. You still can panic or exit your process at any time.
I enjoyed watching your video 😂 Thanks Ryan
I fr wanna be like you as I advance in my career… You’re hats off inspirational
You have some good points, but maybe there are more to consider:
_ Productivity does not come from time alone. Go and a lot of other languages are like "I got the feature ready" only to have some null-pointers and other exceptions fixed later on. Rust is like "I got the feature ready" and it's ... ready. I never encountered a language where I finished something without a need of tweaking it again after a couple of days. That is why I'd say that this should be a tie.
_ Ecosystem - I really see packages or even std libs that offer 100s of line of documentation for a single function or even line of code - rust does. Most of the std stuff is documented with an explanation, examples and even tests. But of course not every crate creator does this the same way, so I agree on the tie here.
_ UseCase - Rust is capable of being a C-alternative. But with rocket, Axum etc. starting up a small micro service is just as easy as using spring boot. And when you stay on that level, you hardly find a need to go "deep down" to the bits and bytes itself. I mean, if you switch spring for rust, you still operate on the same level.
_ I dunno Go, but I would have loved a comparison on testing since I absolutely adore the possibility on testing private functions and methods in rust. Even the standard of writing the tests in the same file (or even in the documentation itself) is absolutely a game-changer for me. Seeing all this terrible test setups in other languages makes me shiver.
I personally feel like I can really deepen my understanding of software development itself with rust, something I really lack with java. That's why I fully agree on your view on the market - but oh boy do I hope this will change soon...
Go makes testing super easy
@@RandomShowerThoughts Rust makes testing super easy
Both have testing ready on board. Rust uses attributes, and Go uses a certain function signature to separate tests from production code. That's all you need. But I would say that Rust has a small advantage with "integration testing", while Go has super-nice benchmarking and supports fuzz tests as well.
One of the best, concise, balanced perspectives
Plz go down the rust rabbit hole, I would love to hear your programmer experience!
"simplicity" in Go is an illusion. Yes, on paper and when learning the language it's somewhat easier, but computer software problems are hard. Go just moves that complexity elsewhere. Case in point: Go does not have ADT (Algebraic Data Types, such as enum). You get a "simpler" approximation of an enum by using a type alias for an int, and define some constants for the enum's variants. Simpler? Probably, but the complexity moves down the line to every time you, for example, add a new variant to the enum and have to make sure that _everywhere_ else in the codebase this is accounted for, rather than having the compiler warn you in places you're not checking for all the cases.
Another example: error handling. Sure, it's "simpler" to just return a tuple, but what if you forget to check for an error, or leave yourself a //TODO? Golang will happily insert a default value into your variable and the problem will then manifest at runtime (under specific circumstances), making it much more complex to track down and debug.
Simplicity of Go is not an advantage, it's a tradeoff.
Great points. Thanks for providing specific examples!
I personally like Go a lot more than Rust, I took a basic course on both of them about conditionals, variables, formatting, loops, and I felt like Go was what I wanted it made me feel like if I continued with it I would have a better learning and use experience, I love a language that's fast but keeps a simple friendly syntax and that's why I love Go, Rust just isn't for me so I believe whether people learn Rust or Go has a lot to do with developer preference, what someone likes in a language, because some like Java, and others hate it, so I believe that developer preference and what one is looking for in a language has a lot to do with their bias in Go or Rust. At the end of the day there is no better language both Go and Rust have their ups and downs, and I think we should just learn to co-live with two amazing languages.
Thanks @codewithryan for the great summary-comparison video, and thanks @wolffwolfie3166 for the comment - between the two of you, I think I just answered my question as to which of {Go, Rust} to use for my next project. Answer: Both!
I think I want to either integrate Rust subroutines into a Go main program, or else integrate Go subroutines into a Rust main program. Anybody know if either of the latter is preferable over the other (or can point to articles shedding light on that question)? My idea is, regardless of which is the top-level main program, to be able to (at any point) call Rust from Go or call Go from Rust (or the easy/obvious call Go from Go or call Rust from Rust) depending on which is apropos to the task. My point is that, in some cases there are tricky safety issues and these routines might best be done in Rust, whereas in other cases there are no big safety issues yet the algorithms used therein are a bit tricky such that they might be better described in the simpler Go language so as to enable understanding the code by the team. I presume (that is, hope) that both Go and Rust have call-out mechanisms to other languages (hopefully without having to go through Java since getting away from Java was a motivator point to look at Go and Rust in the first place).
Fair and balanced! :-D One thing I might want to tweak about the Rust examples is when you have Thing and OtherThing, there a bunch of different ways it might make sense to represent that:
- Thing contains an OtherThing (i.e. just by value)
- Thing contains a &mut OtherThing (the example in the video)
- Thing contains a Box
- each of those agaon, but with Option
I think seeing all these options reinforces several points at the same time. Rust is definitely more complicated than Go, and even super basic concepts like "this thing holds another thing" come with extra complexity. But on the other hand, that complexity is an accurate reflection of what's going on under the hood. Is the other thing optional, or is it required? Do we own the other thing, or are we just borrowing it? Are we going to do heap allocation here or not? Each of those approaches can make sense in different situations, and being explicit about what your requirements are is a big benefit for correctness, even in high-level code where fine-grained control isn't as important.
great comparison :)
3:50 I think the thing here is short vs ling term productivity. Most people I've seen accept Rust is more initially complicated but argue it's certainties and typing make it easier to work on long term
Good general overview
"Compiler wil beat you into submission until your code is correct."
---
LMAO You made my day...
I don't like go in term of productivity cause it lacks even simple methods to work with arrays and other stuff. For everything, even filterting or mapping you gotta write your own code with a for loop, and it's completely annoying. Even thou it doesn't have any other built-in structures instead of arrays and maps so you gotta implement every single structure by ur own. So, once you start writing not just a hello world in Go, it becomes a hell of that you gotta write everything on ur own
In Rust there're plenty of built-in pretty fine methods and structures so you just take all you need and use it. Simple
That’s a valid point. Go doesn’t include any map/filter/reduce functionality out of the box like JS/Python/Rust. You can always implement it yourself (especially now with generics in Go). But yeah it’s inconvenient.
@@codewithryan btw, as for generics, it's a pretty good thing but go core team didn't wanna add it into language cause of making the lang harder and cause go has the fastest compiler that outperforms others in times and it's that fast cause of the language syntax simplicity, so adding an extra thing into a lang that will make code analysis and compilation significantly slower and that's what was stopping them for so long. Well, the simpler the technology the smaller amount of built-in stuff u can use and it's always a problem of choice, and it's IMHO the most clear difference between the most simple lang - Go, and like the most complex and hard - Rust
they're slowly adding some of those things last i checked, the api looks ugly af tho. shouldnt have read your comment now i feel like ditching go lmao
Some of your points can be argued about, like performance wins for Rust, eh, in some instances Go makes performant code trivial while Rust doesn't, mostly its in situations where the Go runtime pulls tricks in concurrent programs.
But one thing where I don't agree with your stance at all is mostly collaboration and also somewhat related productivity.
Yeah. Rust makes you any anyone that wants to collaborate learn A LOT more than Go. But afterwards there is an mostly uniform way to solve the particular issue, and if you forget it the Compiler will remind you. This means that you can express how to use your code by using the type system. This means that others have at least a much harder time abusing your code in an unexpected way, and the reverse.
The same also applies to libraries, which is where the productivity argument comes in. If I consume a Rust library I'm usually fairly unfazed, I can just go ahead and write whatever and it'll probably work. If I use libraries in other languages tho I very often get stuck on now knowing whether I'm using something the intended way, and having a hard time finding resources describing what to do.
So that makes me more productive in some instances. I don't think this makes Rust win, but it's more complicated and not a straight win for Go.
With collaboration meanwhile, if you're in a team above... Let's say 3 competent people, then I'll HUGELY prefer Rust over a language like Go. There's a reason a lot of large companies start to adopt Rust for their large projects after they used it for smaller ones, they see that collaboration effect, which makes scaling teams a LOT more efficient.
It is really easy to take someone, let's say, a Python dev (because you don't have enough engineers in your team) that haven't seen Go in his entire life and make him write Go code that is performant enough and looks like any other Go code in your project, written by other, more senior devs that worked in Go for years
I am only starting learning Rust but I see how it would be way more difficult to pull off the same with Rust. Especially if you have deadlines and your project is not merely a hobby
I have 17 years of C++ experience.
Tried Go, didn't like it.
Tried Rust, will never leave it.
I use both Go and Rust, depending on the problem that needs to be solved. Simple APIs, servers that aren't on super enterprise level scale, etc, are all good use cases for Go.
I use Rust for all my decentralized applications, IPC background services, and desktop applications that need as small as a resource foot print as possible.
I think it's a little silly that people try and compare Rust and Go, when truly I think they can easily co-exist.
great video. subscribed.
Rust is very difficult to learn and I have been learning it for three years and still can't use it in production, any tips?
Great video 👍
You got me at `there is one that's gotta be better than the other' :D
Trust me, performance should never be overlooked. I worked at a hosting company and i saw so many examples where in 2 same spec servers, you could run only 4 nodejs servers, where on another you could literaly run 15 apache, go, or any other more performant servers
Your channel is refreshing, you look at things from a very chill point of view, so tired of the infinite number of zealots in the field...I'm 6 years in and I'm ready for retirement and to grow potatoes or something
If all you do is a presentation screen with a little square top right, why bother with 2-4k?
which framework or toolkit you used for backend development in go?
Gin (server) is the closest thing to a framework that I use. As for libraries, I use pgx for the Postgres client and gRPC for microservice communication. Everything else can mostly be implemented via the Go standard library.
well done, thanks.
I feel like separating productivity and safety is a bit is a bit of a mistake because... writing incorrect code quickly is still writing incorrect code. Yes, most projects aren't rocket firmware or airbags and can ship with some bugs and not the end of the world, but in the end, the more bugs you write, the more you have to fix and that takes time away from, y'know, writing code. Safety as a category can stand alone from productivity, but productivity has to take safety into account. There's a reason everybody likes TypeScript more than JavaScript and type annotations in Python for things used more than once.
It'll be difficult to compare because you need large projects to see the trade-offs between safety and speed of writing initially, but I wouldn't be so quick to say "Rust is slow to write." Because yes, I'll admit that while it's very fun to write, it's definitely going to be slower than some other languages, but that doesn't mean it's less productive over all.
That said, Rust's memory model is definitely a speed for complexity trade-off, not a safety for complexity trade-off, so it'd be interesting to see a language with Rust-style safety (including must-check errors, etc) but also a garbage collector. (And yes, I'm aware that functional languages have many of these features, but what I want is Rust with a garbage collector, not a functional programming language lol)
I would also disagree that Rust is somehow inherently a lower level language. It's a modern language with all the nice features of a high level language. The question is whether the increased difficulty of writing is worth the safety and performance and while the trade off can go either way, the latter two are a big plus anywhere.
Lots of its safety guarantees are nice when writing a website with WASM or doing networking or whatever. Like, a server is one of those cases where safety is paramount because if your server has a bug and crashes, this is a Big Problem. It's not quite as important as airbags or a rocket, but it's pretty damn safety critical too, so the fact that Rust ensures you never forget to handle an error and all the other things it can check for you is very nice.
Plus Rust's macro system is extremely powerful, and the ability to derive traits for your structs (like deep copy or debug printing or serialization) is a very powerful tool. And crates like Leptos are pretty mind-blowing in that you can write HTML straight in your Rust with a macro, invoking Rust objects directly as necessary, and it'll all be type-checked for you. Or the sqlx crate, which can execute dummy database queries at compile time to make sure they're structured correctly and not just syntactically correct.
Eventually I will learn both
For backend for a Flutter application, will you prefer GO or Node js ?
literally doesnt matter
Honestly, I'm moving from python/ts to rust and go is like a happy median that can also get a job
I think especially the “Productivity” part is a little misleading. While it is true that one can pick up Go on a long weekend and just start doing stuff, the time spent at tracking down nullpointers, race conditions and other little errors that occurs because of the high level of abstraction Go offers, will probably be more than the time spent to get your program to compile in rust and then be done with it 🦀
not really in my opinion. The panic System and stack trace of go makes it really easy to see what your issue was if you really get to that point. But the most time you won't really get the problem if you just read the docs of a function your using. The functions normally tell you in which cases they are throwing a panic (that is normally something like giving invalid inputs into a function). All expected errors are returned (like I/O). You have to explicitly ignore that error in most cases. I agree that race conditions can be an issue, but that normally doesn't have to do with shared memory but instead logical race condition in event-based systems which will be an issue in Rust too.
actually a great and fair comparison unlike other hype ideos
i dont see a lot of major companies 10x c programmers switching to rust. new linux kernel is in rust though. go easily compiles for multi platform btw. dont know about rust.. great video 👍
10:43 I liked the video but you could choose a better analogy: "If I want to write a server, I'm not gonna do that in C". Literally, the most popular servers are written in C.
For me, both of them are on my top priority
Go and rust is a great combo!
different languages for different purposes . Like why ppl asking it😭
Go is like driving car with some training.
Rust is like driving car while doing crankshaft,gearbox calculation in your head.
The only proper answer to "Which one is better?" is YES.
Surprisingly enough, Rust is a very good solution for web development with web assembly. There are frameworks like axium-web for the backend and Yew for the frontend.
Nice, I’ll have to check those out 👍
Reminding people that Go is blazing fast, even if not as fast as Rust. Also, few weeks will get you going in Go, as with everything, it takes time to master a craft. Go is really fun to program with. I am learning Rust, but i will use Go for a long time to come.
In my experience Rust can replace Golang when mature enought. If you want to make a tool what enhance your experience, Rust have a chance but i dont see that happening. I think what every system language can be whatever language ... why not ? just making libs or frameworks and tadaahh. Mutex, channels, pointers, memory management, cloning, using/preventing race conditions for get every advantage, awesome ! Sometimes we need that (always hehe). I think people believe that things are difficult because they are sold that way and not because they really are.
Personally thinking, rust is better in some aspects of collaboration due to its FFI feature. Although rust is not mature so do its features, it will be pretty stable at some point.
This is actually a bigger point than most people like to imagine. If you look up the histories of the languages, there's like a specific point where their fates were decided. Rust used to have green threads and reflection by default, and a gc before the borrow checker came into being. They had to drop all these ideas because these simply get in the way of performant systems programming. On the other hand, Go has several implementations: the one we use today, one based on gcc, and one based on llvm. The latter two showed immense potential to land Go in the systems programming map, but at the cost of less performant green thread implementation. That's why Go's maintainers choose to go with their own implementation specifically geared towards concurrency at the cost of subpar FFI.