Rust vs. Go(bitfieldconsulting.com)
bitfieldconsulting.com
Rust vs. Go
https://bitfieldconsulting.com/golang/rust-vs-go
16 comments
Honestly, that's exactly what I found valuable and refreshing. We're so obsessed with supremism in all things, it's nice to hear a detailed explanation of "they're both great". And this has motivated me to give Go a longer look once I'm a bit farther up the Rust learning curve. I appreciate the take that there's value to knowing both.
Well, the point is that which language you choose depends on what you want to do with it, and it's impossible to say objectively that one language is "better" than another. If you ask me which one I _like_ more, that's a totally different question, but no one cares what the answer is.
I like both languages. In my mind they fill different niches:
- Rust is a better C++
- Go is a better Python
YMMV.
Some will argue we don't need a better Python or Go isn't a better Python. These are both entirely reasonable positions. My take is:
1. Go is statically typed (even with an interface{} catch-all and no generics; which honestly I personally don't really care about but I understand if you do; it's certainly no worse than the Python equivalent).
2. Python still has the issue of requiring it to be installed as well as the compatibility of that installed environment (ie what virtualenv does). Java has this issue too. Standalone executables are just more convenient;
3. Loading your runtime environment has a greater cost in Python;
4. I actually don't like where Python 3 has gone where almost every point release at this point seems to add to the language itself. Python 3 really was a change in philosophy vs Python 2.
- Rust is a better C++
- Go is a better Python
YMMV.
Some will argue we don't need a better Python or Go isn't a better Python. These are both entirely reasonable positions. My take is:
1. Go is statically typed (even with an interface{} catch-all and no generics; which honestly I personally don't really care about but I understand if you do; it's certainly no worse than the Python equivalent).
2. Python still has the issue of requiring it to be installed as well as the compatibility of that installed environment (ie what virtualenv does). Java has this issue too. Standalone executables are just more convenient;
3. Loading your runtime environment has a greater cost in Python;
4. I actually don't like where Python 3 has gone where almost every point release at this point seems to add to the language itself. Python 3 really was a change in philosophy vs Python 2.
You might enjoy this companion piece! https://bitfieldconsulting.com/golang/go-vs-python
I've been using Go since 2013 and have 200K+ lines under my belt. Probably the same amount of work with JS/TS.
My business is APP development (marketplace, fintech, social networks and saas) ... in the past 3-4 years NEVER ONCE have I regretted choosing Go and in fact the opposite. My team is super comfortable with it, and new members joining can pick up the stack in a day. It's cheap & efficient on the servers and require minimal overhead.
Rust has its perk and usefulness, but for very particular, niche, software applications. It's not a productivity gain in backend app development in my line of business. In my opinion, Rust for app development is "extreme premature optimization"!
Deep down, I really hope Go's generics do NOT happen so the language stays simple and readable. The new propositions are worrying my team and we'll probably ban it in our dev process.
My business is APP development (marketplace, fintech, social networks and saas) ... in the past 3-4 years NEVER ONCE have I regretted choosing Go and in fact the opposite. My team is super comfortable with it, and new members joining can pick up the stack in a day. It's cheap & efficient on the servers and require minimal overhead.
Rust has its perk and usefulness, but for very particular, niche, software applications. It's not a productivity gain in backend app development in my line of business. In my opinion, Rust for app development is "extreme premature optimization"!
Deep down, I really hope Go's generics do NOT happen so the language stays simple and readable. The new propositions are worrying my team and we'll probably ban it in our dev process.
[deleted]
I don't think Go is really a Systems Programming Language per say. In fact, that claim was removed from the homepage a couple of years ago.
> When we first announced Go we called it a systems programming language, and I slightly regret that because people assumed it was an operating systems writing language, what we should have called it was a server writing language ... and it started becoming more generally useful than that - Rob Pike
Rust however by general consensus is a true systems programming language
> When we first announced Go we called it a systems programming language, and I slightly regret that because people assumed it was an operating systems writing language, what we should have called it was a server writing language ... and it started becoming more generally useful than that - Rob Pike
Rust however by general consensus is a true systems programming language
Quote: "It's become clear over many decades of using older languages such as C and C++ that one of the biggest causes of bugs and security vulnerabilities is accessing memory unsafely or incorrectly"
Wanna bet you can write applications that have security vulnerabilities in Rust and Go just the same?
Also searching on Upwork for jobs on Rust - results 47 jobs. Searching for in Go - results 213. Searching for jobs in C/C++ - results 1139. Searching for jobs in Java - results 4262.
Wanna bet you can write applications that have security vulnerabilities in Rust and Go just the same?
Also searching on Upwork for jobs on Rust - results 47 jobs. Searching for in Go - results 213. Searching for jobs in C/C++ - results 1139. Searching for jobs in Java - results 4262.
Well, no one is claiming that it's impossible to write Rust or Go programs that have security vulnerabilities—that would be a very silly thing to claim, wouldn't it?
A more useful way to think about it might be to ask whether such languages make vulnerabilities less likely, and for certain types of vulnerability (buffer overflows, for example), they absolutely do.
A more useful way to think about it might be to ask whether such languages make vulnerabilities less likely, and for certain types of vulnerability (buffer overflows, for example), they absolutely do.
Wanna bet you can do buffer overflows in Rust/Go too?
Hey my friend, don't be like that :) Everyone here wanna have great conversations and learn more about stuff... These kind of comments creates tons of unnecessary noise.
However I will bite the bait, please show to us how :)
However I will bite the bait, please show to us how :)
Security isn't all or nothing, though.
Fun semi-random trivia fact: Upwork ran a TV ad mentioning Rust earlier this year https://www.youtube.com/watch?v=h3yFOf6hIjQ
> Wanna bet you can write applications that have security vulnerabilities in Rust and Go just the same?
While it's still early enough that this is an interesting bet, the data we do have shows that you'd be likely to lose that bet. Several of the largest tech companies on the planet have data showing that roughly 70% of security vulnerabilities are caused by memory unsafety. Both Rust and Go are significantly more memory safe than C and C++.
Nobody would claim that either language completely eliminates security issues, but that doesn't mean that they can't help mitigate many of them.
> Wanna bet you can write applications that have security vulnerabilities in Rust and Go just the same?
While it's still early enough that this is an interesting bet, the data we do have shows that you'd be likely to lose that bet. Several of the largest tech companies on the planet have data showing that roughly 70% of security vulnerabilities are caused by memory unsafety. Both Rust and Go are significantly more memory safe than C and C++.
Nobody would claim that either language completely eliminates security issues, but that doesn't mean that they can't help mitigate many of them.
here we go again
> Fast, compact executables
Fast - perhaps. Compact - hardly.
Fast - perhaps. Compact - hardly.
> In this article, I'll try to give a brief overview of where I think Go is the ideal choice, and where I think Rust is a better alternative. Ideally, though, you should have a working familiarity with both languages.
Isn't this pretty difficult with Rust, considering the complexity, different paradigms and the fact that the language is still evolving? I could be wrong but Rust doesn't seem like a part-time every-once-in-a-while kind of language.
Isn't this pretty difficult with Rust, considering the complexity, different paradigms and the fact that the language is still evolving? I could be wrong but Rust doesn't seem like a part-time every-once-in-a-while kind of language.
I'm an on-again off-again with Rust who uses Go more often. The Rust language has been stable for a while. It was moving faster a few years ago but is quite stable today. Reminds me of C++, where most of what is added to the language is methods that make things a bit more convenient, like char::from_u32, etc.
I would say that the hard thing about Rust programming at the moment is that a number of libraries that you'd want to use are just a bit too clever for their own good, so it can require research to find a library that makes more reasonable / sane tradeoffs.
I would say that the hard thing about Rust programming at the moment is that a number of libraries that you'd want to use are just a bit too clever for their own good, so it can require research to find a library that makes more reasonable / sane tradeoffs.
Yes Go is more mature, both by design and because it is also slightly older. In the other hand the two languages also solve different kinds of problems in very different ways.
Substantial things are being written in the Rust language for different fitting use-cases. Rust has quite a lot of reach as you can sneak it into large ecosystems to optimize parts of your application: Browsers, Nodejs and PHP (soon more) via WASM, JVM via JNI.
It is also a language that attracts big shops like Amazon and Microsoft, which typically is a good sign for a young language.
The reason you typically don't see Rust as a _primary_ (rather than supporting) language for (Web-)application code is that it is better suited to solve hard problems (mainly performance but also internal correctness) than it is to do generic data manipulation and plumbing, which is typical for applications.
That said I personally don't subscribe to the idea of the author that the two languages are like a match made in heaven. I'm very attracted to Go and I think it is a fantastic language. But as a freelancer who works alone or in small teams I never find a reason to choose it over the other ones in my tool-belt.
For example Clojure plus Rust is a much more fitting duo. They can both target browsers, Nodejs and the JVM and their use-cases are more diverged/distinct.
Comming back to your point. It would be rather unpragmatic however to invest in any of the mentioned languages without already being proficient in some of the mainstream languages I think.
Substantial things are being written in the Rust language for different fitting use-cases. Rust has quite a lot of reach as you can sneak it into large ecosystems to optimize parts of your application: Browsers, Nodejs and PHP (soon more) via WASM, JVM via JNI.
It is also a language that attracts big shops like Amazon and Microsoft, which typically is a good sign for a young language.
The reason you typically don't see Rust as a _primary_ (rather than supporting) language for (Web-)application code is that it is better suited to solve hard problems (mainly performance but also internal correctness) than it is to do generic data manipulation and plumbing, which is typical for applications.
That said I personally don't subscribe to the idea of the author that the two languages are like a match made in heaven. I'm very attracted to Go and I think it is a fantastic language. But as a freelancer who works alone or in small teams I never find a reason to choose it over the other ones in my tool-belt.
For example Clojure plus Rust is a much more fitting duo. They can both target browsers, Nodejs and the JVM and their use-cases are more diverged/distinct.
Comming back to your point. It would be rather unpragmatic however to invest in any of the mentioned languages without already being proficient in some of the mainstream languages I think.
are we still comparing programming languages like this in 2020? that's why I am starting to grow sick of this industry - so much folklore, so little engineering
meta: i am so tired to see articles jammed with buzzwords and keywords whole purpose is to just rank high in google yet providing little to no substance. come on HN!
meta: i am so tired to see articles jammed with buzzwords and keywords whole purpose is to just rank high in google yet providing little to no substance. come on HN!
> that's why I am starting to grow sick of this industry, so much folklore so little engineering
That's pointless complaint when it's under a folklore article. It's like complaining about not enough heavy metal under a Taylor Swift song. There's plenty of engineering going on too and you can read about that instead.
That's pointless complaint when it's under a folklore article. It's like complaining about not enough heavy metal under a Taylor Swift song. There's plenty of engineering going on too and you can read about that instead.
Not sure what you mean by 'folklore' in this context. There's a lot of discussion in the piece about memory safety, garbage collection, build performance, and so forth. Don't you think that's engineering, or at least engineering-adjacent?
frontpage material right there
It probably started like that. Both tried to be a better system programming language, but they diverged quite much.
Having done a bit of C++ back in high school, I just spent the past several weeks getting somewhat familiar with modern C++. No idea if it's worth it or if I'm wasting my time and should have picked Go/Rust instead.
With languages as complex as modern C++, I always tend to hunt for a subset of features that makes me happy and productive, and effectively discard the rest. Compared to that, I think there is relatively little in Go that one may want to disregard, and I'd argue it's due to the fact that it's a relatively tight featureset with practicality in mind, and is therefore easy to learn. With Rust, I'd say the experience is more subjective, but it's still not as sprawling as C++.
I know it's an unpopular opinion, but I believe personal fit in a programming language is just as important as its fitness for a purpose. I always like to check out new languages and features, but in the end I'm very likely to stick with what feels productive for me personally. If that means dropping half of a language's features, I'll do that, too. Chasing "modernity" or buzzword fads is a recipe for unhappiness in my opinion.
If C++ (modern or reduced) feels good and productive to you, I'd say there is nothing wrong in sticking with it.
I know it's an unpopular opinion, but I believe personal fit in a programming language is just as important as its fitness for a purpose. I always like to check out new languages and features, but in the end I'm very likely to stick with what feels productive for me personally. If that means dropping half of a language's features, I'll do that, too. Chasing "modernity" or buzzword fads is a recipe for unhappiness in my opinion.
If C++ (modern or reduced) feels good and productive to you, I'd say there is nothing wrong in sticking with it.
>With languages as complex as modern C++, I always tend to hunt for a subset of features that makes me happy and productive, and effectively discard the rest.
Perhaps you are in a position to make such choices, but it's not a realistic option for most developers most of the time.
Not all projects are greenfield. Not all projects can restrict their choice of libraries to the ones that conform to some preferred style or language subset. Not everyone is self employed and working alone. You cannot know in advance what subset of the language any particular employer or client prefers.
So my advice to a young developer would be to learn all of C++ or steer clear of it altogether. Learning C++ well enough to not be dangerous is a major undertaking.
Perhaps you are in a position to make such choices, but it's not a realistic option for most developers most of the time.
Not all projects are greenfield. Not all projects can restrict their choice of libraries to the ones that conform to some preferred style or language subset. Not everyone is self employed and working alone. You cannot know in advance what subset of the language any particular employer or client prefers.
So my advice to a young developer would be to learn all of C++ or steer clear of it altogether. Learning C++ well enough to not be dangerous is a major undertaking.
> Perhaps you are in a position to make such choices, but it's not a realistic option for most developers most of the time.
You're implying a context that was not really part of my post or the post I was replying to. I didn't get the feeling that the OP was frantically trying to catch up on C++ because their workplace demands it. Rather, they seem to be a person trying to gauge what languages they should pursue in addition or instead of C++, of their own volition.
> Not everyone is self employed and working alone.
I'm not asserting otherwise.
> So my advice to a young developer would be to learn all of C++ or steer clear of it altogether. Learning C++ well enough to not be dangerous is a major undertaking.
My advice would be: it depends on what you're going to do with it. What kind of projects are you involved in? Are you programming for yourself or in a team? If you're in a team, these decisions all get made for you. If you're programming for yourself, it may not be a problem to "be dangerous" while you're learning.
It's also worth considering what "learn all of C++" means. In my post, I didn't mean to imply that people should refuse knowledge of features. What I meant to say is, they should make informed decisions about the features they'll use. All of which applies of course only, as you so clearly stated, to people who actually have control over their usage of the language.
You're implying a context that was not really part of my post or the post I was replying to. I didn't get the feeling that the OP was frantically trying to catch up on C++ because their workplace demands it. Rather, they seem to be a person trying to gauge what languages they should pursue in addition or instead of C++, of their own volition.
> Not everyone is self employed and working alone.
I'm not asserting otherwise.
> So my advice to a young developer would be to learn all of C++ or steer clear of it altogether. Learning C++ well enough to not be dangerous is a major undertaking.
My advice would be: it depends on what you're going to do with it. What kind of projects are you involved in? Are you programming for yourself or in a team? If you're in a team, these decisions all get made for you. If you're programming for yourself, it may not be a problem to "be dangerous" while you're learning.
It's also worth considering what "learn all of C++" means. In my post, I didn't mean to imply that people should refuse knowledge of features. What I meant to say is, they should make informed decisions about the features they'll use. All of which applies of course only, as you so clearly stated, to people who actually have control over their usage of the language.
Depends on what your goals are and how long ago high school is for you.
If your goal is to get a job in a field or at a company where you will be expected to write C++, then learn modern C++. If you are interested in using software that interoperates with C++ well, like the Unreal engine, then use C++. If you are interested in embedded programming for small systems, C++ is a reasonable choice.
If you just want to get stuff done, C++ can introduce additional complexity and get in the way. C++ is more difficult to learn and it is more difficult to reason about programs in C++ compared to languages like Go or Rust. C++ programs often suffer from memory errors, even if you have world-class programmers on your team, and debugging memory errors can be both challenging and time-consuming.
If your goal is to get a job in a field or at a company where you will be expected to write C++, then learn modern C++. If you are interested in using software that interoperates with C++ well, like the Unreal engine, then use C++. If you are interested in embedded programming for small systems, C++ is a reasonable choice.
If you just want to get stuff done, C++ can introduce additional complexity and get in the way. C++ is more difficult to learn and it is more difficult to reason about programs in C++ compared to languages like Go or Rust. C++ programs often suffer from memory errors, even if you have world-class programmers on your team, and debugging memory errors can be both challenging and time-consuming.
This comparison doesn't really make that much sense.
Rust is a systems programming language and should be compared vs C++, C, D.
Go should be compared against Java, C#, Scala and the likes as all of them had similar design goals - productivity for complex systems.
"Compiles to binary" is rather a poor way to group languages.
Rust is a systems programming language and should be compared vs C++, C, D.
Go should be compared against Java, C#, Scala and the likes as all of them had similar design goals - productivity for complex systems.
"Compiles to binary" is rather a poor way to group languages.
Well, the problem with that is that not everyone would agree on that way of classifying languages _either_! And people do want to know what the differences are between Go and Rust, as they're so often mentioned in the same breath. I think the comparison is valid (whether you agree with it is another question).
Fair enough. I like to pick my tools based on the problem I am trying to solve.
Me too! You'll have noticed that that's exactly the structure of my article: which problems is Rust a better choice for, and which problems suit Go. It's intended to help people just like you, who want to pick a tool based on the problem they're trying to solve, rather than tribalism.
Is it me (with Firefox Focus) or are the styles on this page set to have the section titles in smaller fonts than the actual section text/paragraphs?
@bitfield author & submitter: please take a look at this. I found it difficult to scan and get the broad picture of the comparison.
@bitfield author & submitter: please take a look at this. I found it difficult to scan and get the broad picture of the comparison.
Could you provide a screenshot showing what you mean?
I use Rust and Go.
I think missing from this is a discussion about which projects might be more enjoyable to write in Go or Rust.
Nearly all the automation and web services I do is in Go. In Go it's easy to pull in libraries to work with other services. Everything from pushing Route 53 changes to making automated changes to HTML documents in a web server. Build pipelines that require orchestrating other processes. Development servers.
I sometimes reach for Rust when there's some more intense central algorithm or data structure I want to work with. This could be something like image manipulation or writing a compiler or parser. Writing a parser in Rust is a joy.
I'm going to make an unfair generalization: Go is more likely to get the job done, Rust is more likely to do the job well. Just my feelings on the matter.
As an illustration... if you are spawning a process, you don't really care about how efficient you are constructing the strings for the argument list. If you are writing a compiler, you do care about how efficient your string manipulation is.
I think missing from this is a discussion about which projects might be more enjoyable to write in Go or Rust.
Nearly all the automation and web services I do is in Go. In Go it's easy to pull in libraries to work with other services. Everything from pushing Route 53 changes to making automated changes to HTML documents in a web server. Build pipelines that require orchestrating other processes. Development servers.
I sometimes reach for Rust when there's some more intense central algorithm or data structure I want to work with. This could be something like image manipulation or writing a compiler or parser. Writing a parser in Rust is a joy.
I'm going to make an unfair generalization: Go is more likely to get the job done, Rust is more likely to do the job well. Just my feelings on the matter.
As an illustration... if you are spawning a process, you don't really care about how efficient you are constructing the strings for the argument list. If you are writing a compiler, you do care about how efficient your string manipulation is.
> I'm going to make an unfair generalization: Go is more likely to get the job done, Rust is more likely to do the job well.
Which job though? You said yourself that you use them for completely different things. Is Rust really more likely to do the job well (however we define that) if the job is to write services or orchestrate processes?
Which job though? You said yourself that you use them for completely different things. Is Rust really more likely to do the job well (however we define that) if the job is to write services or orchestrate processes?
Bite-size generalizations fall apart if you look at them too closely.
For example, if you dissect "Go To Statement Considered Harmful" as a statement you'll find it very lacking, but that's okay, it's just the title for a paper and you can go read the actual paper if you want more details.
For example, if you dissect "Go To Statement Considered Harmful" as a statement you'll find it very lacking, but that's okay, it's just the title for a paper and you can go read the actual paper if you want more details.
The generalization made sense to me.
> Go is more likely to get the job done, Rust is more likely to do the job well
That's surprisingly close to what one of my contributors wrote in the piece:
> My take: Go for the code that has to ship tomorrow, Rust for the code that has to keep running untouched for the next five years.
That's surprisingly close to what one of my contributors wrote in the piece:
> My take: Go for the code that has to ship tomorrow, Rust for the code that has to keep running untouched for the next five years.
However, I do find it a bit frustrating when someone writes a 10 page article and concludes with "you can use either". It's actually not helpful to the reader, because they do have differences, which you've talked about extensively in the preceding 10 pages. If they were identical, you wouldn't need the article, and OBVIOUSLY you can use either.
Indeed, in the post above he made valid points such as Go may be thought to prioritise speed of development over speed to execution when compared to Rust.
It's absolutely fine to state an opinion at the end of an article which is clearly on a subjective passage.