upvote
I agree about Rust gaining ground but using the argument that it got 10% faster due to Rust is not really that useful.

If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal.

reply
> If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal.

This speculation has been offered every time. It's not crazy to think this might be true, but it's also not crazy to think that if C++ keeps leaving performance on the table and Rust doesn't that adds up for real projects.

When Titus wrote "ABI: Now or Never" in 2020 he estimated 5-10% aggregate loss. Things that you could fix, if you started over, but C++ refuses to do that because of ABI and so it doesn't have these fixes, whereas in most cases† Rust does. So I can well believe that a blow-for-blow port could get you 10% perf win.

† One of the examples Titus cites is the "Small String Optimization". Rust deliberately doesn't do SSO for its standard library collection String, but several really nice SSO optimised types are available, including ColdString and CompactString, which are way better than what's provided in C++ if that's what you need.

reply
I think the difference in languages that allows for faster performance is that Rust does a good job of surfacing expensive operations and it makes defensive programming less of a requirement.
reply
> but Rust is pushing into domains where C and C++ dominated in the past.

I think it's also a big sign that the linux kernel adopted rust and not c++. (only for small parts but still)

reply
A not inconsiderable part of why is that Rust for Linux did the work.

When C++ people say they think there should be C++ in Linux, their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software. This doesn't work because C isn't just "C++ but old", and they rapidly lose interest.

Which of course also feeds into Linus' semi-fair claim that not allowing C++ keeps out the low effort wannabes who would plague such a project. This makes C++ developers very angry, but part of the reason why is that it's true, C++ does attract these people.

The Rust for Linux people wrote a lot of code, a lot of documentation, they did Q&As, they worked very hard to actually deliver the idea to the kernel community, it's a totally different approach, it's a lot more work but some people thought it was worth the work.

reply
C++'s module system, introduced in large part by Gabriel Dos Reis, was not a success, and many was critical of it even when he first proposed it. Rust does miles better on that general topic. Perhaps Gabriel was trash at doing good designs, or perhaps he made a mess on purpose.

C++ also does not have pattern matching, which is wildly popular in Rust.

Ladybird in the past used Swift apart from C++, but abandoned it. Swift has some peculiar issues, some of which might not be fixed over time. Ladybird's LLM-based conversion to Rust is interesting. I don't know much much unsafe the converted code has.

reply
Knowing little about cpp modules and nothing about Gabriel Dos Reis, I expect a more design-by-committee type explanation for the result: the module system was probably a victim of having to be backwards compatible, abi stable, idiomatic, zero cost abstraction, be compatible with all weird cpp features, not hurt compile time, etc etc etc

I don't think its fair to attribute it to lack of skills or bad intent, unless there's some proof to any of it.

reply
Nice try, Gabriel.
reply
Yep I agree C++ lacks many features Rust has solid support for. But the real issue with C++ is the development process, almost all the people involved in the Module system are rather old and worked for Microsoft once. They are just in their own bubble and not having an open RFC-process blocks experts in that field.
reply
deleted
reply
>"are kind of losing out to Rust right now"

On publicity side / propaganda / some specific areas you might have a point. Practically amount of C++ code being in active development (I wat to stress this particular point) dwarfs that of Rust despite all that high profile pressure.

Personally I consider languages as just a tool and do not get hung up when client prefers this or that and I have developed all kinds of software in many languages.

If asked for my own opinion - for general development I consider Rust very restrictive and poor expression-wise comparatively to C++, I think it is a case when developer become servant of a tool.

P.S. last sentence edited

reply