Good to know that CPPs safety issues were solved 13 years ago with C++11, and all of the safety bugs that happened anyway over the last decade were just a mass hallucination.
Boring. This 1 minute "article" is a bad attempt at selling "new" C++ features as the saviour that will make Rust obsolete. Nothing new or of value is written either.
The attitude of the author is blatently revealed in the last line:
> So, thank you, Rust, for providing such valuable insights. Now, you can take your leave.
I have no dog in the race (disliking both C++ and Rust - which are more similar to each other than both fanclubs might want to admit), but rarely have I seen a more low-effort post.
When you look at the other "C++ vs Rust" article on the site (about thread priorities) it becomes pretty clear that the author doesn't have much programming knowledge, let alone knowledge of C++ or Rust. I actually wonder if this is some sort of Turing Test experiment.
I'm afraid to touch C++. It's so complex. And I'm speaking as a person who wrote C++ for money 15 years ago. Can't imagine how much one would need to learn modern C++ from zero today.
Rust is absolutely accessible, IMO. Not the easiest language, for sure, but you can learn it in a reasonable timeframe.
"Cannot" implies features that C++ has that Rust cannot offer. The article merely lists improvements to (modern) C++ that also solve issues within C++, that rust solved.
There may very well be things in C++ that rust cannot do, but the article doesn't go into them. As such, the title is not covering the content at all. And the tone of the article sounds very much like someone who is personally affronted by rust somehow.
> So, thank you, Rust, for providing such valuable insights. Now, you can take your leave.
I've fallen into this trap too often myself too, but if I feel personally attacked when someone really attacks technology that I "merely" use, it's a clear sign I'm far too much invested in what should really be "just some tools".
I am also a very avid C++ avoider but if I am in a meeting with this author and they tell me we need to use C++ for something, I'll take it.
Because I trust pain more than smarts. And I do agree that we are coming to a point there will be a better compiled language. Rust actually broke the untouchable status of C/C++. In my opinion the final popularity blow will come from something else. I wish I knew what it was.
I'm not a big fan of all the complexity of Rust (often just to be different), but this is pure flame-bait.
I'm also not a fan of all the design decisions in Carbon/Cpp2, but progress is being made since paradigms keep evolving.
Memory safety and unique ownership being built into the language seems to be inevitably required in anything that will be used in the future, and honestly I don't think we've reached a stable point yet with anything we have.
If your language only supports adding more complexity and never simplifies syntax, it's inevitably going to be replaced. The same thing will happen with Rust in 20 years, it's just how things go.
> If your language only supports adding more complexity and never simplifies syntax, it's inevitably going to be replaced. The same thing will happen with Rust in 20 years, it's just how things go.
I feel like this won't necessarily happen with Rust, because Rust isn't locked down by any standard, breaking changes can happen and there are also Rust editions which help with the whole process of updating the language. The "better Rust" might just be another revised edition of Rust
While this is true now, I expect this to be the case since it's a reasonably fresh language, and most maintainers of Rust projects are enthusiasts that are fine with breaking changes.
Once you get those 10 year old legacy Rust projects that's when you'll be in a different situation.
There's also a potential paradigm changes (like OOP -> functional pattern) that require a complete redesign of the language, since incremental changes can only get you so far.
Python barely managed to pull of v2 to 3, so I guess the future is open to all options.
Nope, editions cover that use case nicely: Rust breaks things every three years -- without breaking existing code.
Basically you have to opt in your project to the new normal. All your projects dependencies can opt in, too, whenever they want to make the jump. Nobody has to opt in though.
Maybe C++ can do something similar eventually once modules are used everywhere. Those have a much cleaner separation of code between individual project parts than you can have with headers.
The complexity ratchet is an interesting problem. I wonder if (or how much) Rust's "edition" system will help. Or if some other mechanisms are needed, and what ideas there are for that.
I suppose eventually you need a bridge to escape to another language. C to Rust bridge is easy. C++ to Rust is a bit harder. I wonder what the Rust to Next Big Language bridge will be like.
While I agree I'm not that keen on the rewrite in rust as an advert, there can be good reason to do so. A higher degree of memory safety is desirable for all those little tools.
> Why should I use Rust instead of C++?
You don't have to. But you also don't need to tie your identity or opinions to a language. Maybe you'd like rust, maybe not... Maybe you'd like it in a particular context. I don't know. Personally I've found it very approachable for a type of programming that I previously didn't touch where C and C++ ruled.
24 comments
[ 2.6 ms ] story [ 66.8 ms ] threadThe attitude of the author is blatently revealed in the last line:
> So, thank you, Rust, for providing such valuable insights. Now, you can take your leave.
A tweet would have done too.
Rust is absolutely accessible, IMO. Not the easiest language, for sure, but you can learn it in a reasonable timeframe.
You don't have to learn it all. Just enough to do your job.
There may very well be things in C++ that rust cannot do, but the article doesn't go into them. As such, the title is not covering the content at all. And the tone of the article sounds very much like someone who is personally affronted by rust somehow.
> So, thank you, Rust, for providing such valuable insights. Now, you can take your leave.
I've fallen into this trap too often myself too, but if I feel personally attacked when someone really attacks technology that I "merely" use, it's a clear sign I'm far too much invested in what should really be "just some tools".
https://wordsandbuttons.online/the_real_cpp_killers.html
Because I trust pain more than smarts. And I do agree that we are coming to a point there will be a better compiled language. Rust actually broke the untouchable status of C/C++. In my opinion the final popularity blow will come from something else. I wish I knew what it was.
I'm also not a fan of all the design decisions in Carbon/Cpp2, but progress is being made since paradigms keep evolving.
Memory safety and unique ownership being built into the language seems to be inevitably required in anything that will be used in the future, and honestly I don't think we've reached a stable point yet with anything we have.
If your language only supports adding more complexity and never simplifies syntax, it's inevitably going to be replaced. The same thing will happen with Rust in 20 years, it's just how things go.
I feel like this won't necessarily happen with Rust, because Rust isn't locked down by any standard, breaking changes can happen and there are also Rust editions which help with the whole process of updating the language. The "better Rust" might just be another revised edition of Rust
Once you get those 10 year old legacy Rust projects that's when you'll be in a different situation.
There's also a potential paradigm changes (like OOP -> functional pattern) that require a complete redesign of the language, since incremental changes can only get you so far.
Python barely managed to pull of v2 to 3, so I guess the future is open to all options.
Basically you have to opt in your project to the new normal. All your projects dependencies can opt in, too, whenever they want to make the jump. Nobody has to opt in though.
Maybe C++ can do something similar eventually once modules are used everywhere. Those have a much cleaner separation of code between individual project parts than you can have with headers.
Change proposals that cause churn are regularly shot down.
I suppose eventually you need a bridge to escape to another language. C to Rust bridge is easy. C++ to Rust is a bit harder. I wonder what the Rust to Next Big Language bridge will be like.
> Why should I use Rust instead of C++?
You don't have to. But you also don't need to tie your identity or opinions to a language. Maybe you'd like rust, maybe not... Maybe you'd like it in a particular context. I don't know. Personally I've found it very approachable for a type of programming that I previously didn't touch where C and C++ ruled.