3 ms·
I don't really like these comparisons looking at these languages through the lens of commonality. The only thing the two have in common is that they're systems
by junon 4y ago
I don't really like these comparisons looking at these languages through the lens of commonality. The only thing the two have in common is that they're systems languages.
C++ is a bloated mess that does exactly zero checking beyond type checking. Rust is a language that favors safety over build times and its serious users understand that.
Rust is also developed completely in the open. C++'s Standards committee is rife with resignation letters, accusations of misconduct, and walled gardens - not to mention years between standards updates, each costing a ton of money to even look at.
Yes, I understand. Rust has no standard. It has no stable ABI yet. Depending on who you are or what you're doing these may or may not be issues for you.
Alas, comparing these two as though one should outperform the other is nonsense to me. Of course Rust is slower than C++. C++ has had decades of maturity and has enjoyed many contributors to its tooling. Rust has not, and its feature set (as in, the things the compiler needs to do) is much broader than any C++ compiler is specified to do.
The end result here is this will only work to fuel more language wars and be used as a cheap weapon in further language debates. In my opinion, anyone who argued about which language is better than which other language has completely missed the point of computer science and programming.
- charcircuit 4y ago>only work to fuel more language wars Iteration time is an important part of the developer experience. The trade off of slower iteration time for improved safety is a real point that needs to be considered when choosing between C++ or Rust. This isn't something silly like curly braces vs whitespace.
- vegerot 4y agoAgreed! …but while we’re at it curly gang all day
- strager 4y ago> I don't really like these comparisons looking at these languages through the lens of commonality. The only thing the two have in common is that they're systems languages. > > [...] In my opinion, anyone who argued about which language is better than which other language has completely missed the point of computer science and programming. When I start a new programming project, I need to choose a language. For this project, three years ago, I had three serious choices: * C * C++ * Rust I rejected C because I wanted the productivity boost from C++ or Rust. I rejected Rust because Rust was new to me (thus risky) but I was very familiar with C++. I don't see why it's a bad idea to compare languages—especially along specific dimensions, like run-time perf or build time or safety—when that's what us software engineers do whenever we start a new project.
- strager 4y ago> Of course Rust is slower than C++. C++ has had decades of maturity and has enjoyed many contributors to its tooling. Rust has not, and its feature set (as in, the things the compiler needs to do) is much broader than any C++ compiler is specified to do. My thinking was the opposite. Because Rust is newer, it doesn't have the bloaty baggage that C++ and its compilers have. And Rust's module system is (in theory) far better for build times than C++'s #include-based module system. But instead of speculating, I put the time in to figure out the answer.
- zabzonk 4y ago> C++ is a bloated mess ... any one who argued (sic) about which language is better ... has completely missed the point of computer science and programming. See something a little out of whack here?
- dgb23 4y ago> The end result here is this will only work to fuel more language wars and be used as a cheap weapon in further language debates (...) Quite the contrary. The article is as objective and specific as it gets and makes no value judgements but uses well reasoned measurements. The encouraged response to an article like this would not be "language wars" but doing related measurements, perhaps comparing the compilation speeds of idiomatic rewrites of existing tools, discussing the reasons for (slow) compilation speeds, and future improvements thereof.