Rust Language, and Why C/C++ Will Never Die (2015)
1–10 of 66 posts
Re: Rust Language, and Why C/C++ Will Never Die (2015)
#2(2015)
Re: Rust Language, and Why C/C++ Will Never Die (2015)
#3Per HN guidelines, this article should have its publication year of 2015 in the title (the article itself seems to not include a date, but one can find the various submissions on Reddit where this was originally discussed). In fact, it's old enough that it even predates the Rust 1.0 release. I haven't gone ahead and read it in full again this time, since the irony of a company selling C++ static analysis software denouncing the utility of Rust is not lost on me, but it would be interesting to see someone with time on their hands go through and see how things have changed in the past four years. In my skimming I noticed it criticizing Rust's results on the benchmarks game, which indeed have improved to C++ levels since then.
Re: Rust Language, and Why C/C++ Will Never Die (2015)
#4I'm reluctant to comment because the first iteration of this 'series' was fraught with blatant errors, from what I recall.
> Rewriting it is way, way too expensive, risky, and, honestly, doesn't seem to make sense except in the heads of the most frantic Rust fans.
I've met hundreds of rust developers at this point and at no point in conversation has anyone ever expressed that we should be working to rewrite every C++ project in Rust.
> for example Vala, Cyclone, Limbo, BitC. How many of you have even heard of these languages?
I'm aware of Cyclone and Vala, not the other two. Vala isn't even a little memory safe, so not sure why it's mentioned. Cyclone was a research project from my understanding, and that's it.
> By the way, most of the critics have never seen C++ code in production.
Not true.
> Rust is safe indeed but, unfortunately, far from fast. By the moment of writing this article, it is comparable to Java, Go, and Haskell regarding performance:
Old benchmarks, no discussion of why those benchmarks are the way they are. Benchmarks without analysis are just meaningless charts. Old benchmarks are even worse.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Here's the up to date benchmarks.
> or if it is automatically doomed to be twice slower than C/C++ because of the constant checks for array overruns, safe wraps of bindings to C-libraries, and other stuff like that.
There are a lot of really interesting reasons why Rust is slower in some benchmarks, like lack of constexpr or int generics, which at least one C++ benchmark uses heavily.
> But these are actually two dialects of one language, which doesn't look much different from the "Java + C" or "Go + C" combos.
Practically, there is a world of difference, given the lack of 0-cost FFI in eithe rof the mentioned languages.
The rest of the article is just disconnected conjecture, I stopped reading. If anyone thinks there's value to finish it though, let me know, I'll circle back.
edit: It occurs to me that I'm not reading "The next in a series" but actually an extremely dated article that wasn't accurate in 2015 and isn't accurate now.
Re: Rust Language, and Why C/C++ Will Never Die (2015)
#5Wow that's a long article, I tried summarizing the main points. I think some of them have merit, but for the "technical reasons", I don't think I agree on most.
Here are the points:
1 - there's a ton of existing c++ programs
2 - other have tried replacing c++ and failed (D for instance)
3 - no one will use Rust until it has cool IDE stuff and production ready libraries: a chicken and egg problem that Go was able to solve with Google support.
Technical reasons:
4 - rust is not that fast
5 - c++ has all these static and dynamic sanitizers which makes rust not that safer compared to c++
6 - if 90%/10% rule true, you could write most of your code in Go/Java and the hot parts in C, instead of most code in Rust and hot parts in unsafe Rust.
7 - premature optimization "rant"?
8 - language verbosity complains around pointers (Box Rc, Arc)
9 - a few more reasons in conclusion, including issues with cargo pulling out code from git repos
Re: Rust Language, and Why C/C++ Will Never Die (2015)
#6The Rust - C++ speed comparison is sadly quite bad. On a modern machine, some of the benchmarks from the benchmarks game ran faster in Rust than in C++. It usually depends on the explicit / implicit vectorisation support, and a lot of it is taken care of by LLVM.
Also if you look at the C code, the multi-threaded optimizations are quite hard to write in C, while Rust has Rayon (which is not yet used in the Benchmarks game examples).
Re: Rust Language, and Why C/C++ Will Never Die (2015)
#7Per HN guidelines, this article should have its publication year of 2015 in the title (the article itself seems to not include a date, but one can find the various submissions on Reddit where this was originally discussed). In fact, it's old enough that it even predates the Rust 1.0 release. I haven't gone ahead and read it in full again this time, since the irony of a company selling C++ static analysis software den…
benchmars game is great, but sadly not well maintained anymore. Rust has it's flaws, but it's not runtime speed (much more compilation speed, IDE support, distributed compilation support).
Re: Rust Language, and Why C/C++ Will Never Die (2015)
#8Wow that's a long article, I tried summarizing the main points. I think some of them have merit, but for the "technical reasons", I don't think I agree on most. Here are the points: 1 - there's a ton of existing c++ programs 2 - other have tried replacing c++ and failed (D for instance) 3 - no one will use Rust until it has cool IDE stuff and production ready libraries: a chicken and egg problem that Go was able to s…
D hasn't failed.
Although personally I don't think being a better C++ is the direction D should be going for (I'd rather see it going in the direction of lower level Java/C#).
Re: Rust Language, and Why C/C++ Will Never Die (2015)
#9Wow that's a long article, I tried summarizing the main points. I think some of them have merit, but for the "technical reasons", I don't think I agree on most. Here are the points: 1 - there's a ton of existing c++ programs 2 - other have tried replacing c++ and failed (D for instance) 3 - no one will use Rust until it has cool IDE stuff and production ready libraries: a chicken and egg problem that Go was able to s…
My biggest disagreement would be:
The first 2 points are really bad arguments in my opinion, it's easy to see by imagining people saying this at the peak year of Fortran: "there's a ton of existing Fortran programs, other have tried to replace Fortran and failed" edit: (forgot to finish sentence) therefore, this new C language will never succeed
3 - I agree that community backing is very important, but in this case: Mozilla use of rust, and Google writing an entire OS in rust seems to prove that rust has a chance.
4 - this one chart used as evidence isn't very conclusive
5 - a language with that safety built-in the compiler itself is better in my opinion. I've read mixed reviews on the effectiveness of the c++ analysers.
6 - first I didn't think that unsafe Rust was there for that hypothetical 90%/10% rule, but more for interacting with unsafe libraries in C/C++?
Second, even if that was true a mix of 2 languages completely ignores the marshalling needed between the two languages?
7 - ?? Not sure what the point was here
8 - one could complain similarly about verbosity in c++ templates. It would be sure nice to have some tooling support to refactor code if in such a situation of using the wrong pointers, but: do people really end up in a situation of 'Vec>>>' ?
Also, how's it different from making mistakes with "const" keywords in c++ and having to change the const qualifiers everywhere. Programmers mistakes will happen in any language, the more strongly typed , the less forgiving the compiler will be.
9 - cargo concerns could be valid, but c++ doesn't even have a cargo equivalent yet?
Re: Rust Language, and Why C/C++ Will Never Die (2015)
#10I do not like Rust, but the argument about the lack of a big corporation to back the new language does not seem to hold water.