5 ms·

I'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 expe

I'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/which-programs-are-fast.html 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.

deleted 8y ago
[deleted]
yholio 8y ago
> 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. So the reason Rust is slow is because C++ has features that allow programmers to write faster implementations of the same algorithms? I think that's the point he is making.
- staticassertion 8y ago
  Not really, no. His point was that fundamentally Rust will have overhead by being safe, and that it's necessary to drop into unsafe to match the performance of C++. He takes this further, stating that if you're going to drop into unsafe for hot code, why not just use Java/Go and FFI into C++. This is misleading or incorrect for a few reasons. * Rust isn't considerably slower than C++ (again, the benchmarks are total nonsense and way out of date) * The performance differences are not a matter of safety features (such as bounds checking array accesses), but separate features like constexpr, int generics, and SIMD. * His statement on Go/Java ignores that Go and Java will pay a significant cost for calling out to C/C++ for the "hot code" As an aside, Rust now has explicit SIMD, and there's progress being made on `const fn` (the contexpr equivalent) and int generics.
- achamayou 8y ago
  Rust has const fn, which are very similar to constexpr (although the limitations aren’t quite the same).

deleted 8y ago

[deleted]

yholio 8y ago

> 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. So the reason Rust is slow is because C++ has features that allow programmers to write faster implementations of the same algorithms? I think that's the point he is making.

staticassertion 8y ago
Not really, no. His point was that fundamentally Rust will have overhead by being safe, and that it's necessary to drop into unsafe to match the performance of C++. He takes this further, stating that if you're going to drop into unsafe for hot code, why not just use Java/Go and FFI into C++. This is misleading or incorrect for a few reasons. * Rust isn't considerably slower than C++ (again, the benchmarks are total nonsense and way out of date) * The performance differences are not a matter of safety features (such as bounds checking array accesses), but separate features like constexpr, int generics, and SIMD. * His statement on Go/Java ignores that Go and Java will pay a significant cost for calling out to C/C++ for the "hot code" As an aside, Rust now has explicit SIMD, and there's progress being made on `const fn` (the contexpr equivalent) and int generics.
achamayou 8y ago
Rust has const fn, which are very similar to constexpr (although the limitations aren’t quite the same).