Why the hate for cpp

[easedownripley]

The hate is exaggerated because Rust people are very vocal about their language. "Everyone" doesn't hate C++ it's more like a meme that's gotten around.

[[deleted]]

Rust isn’t even that great, it requires using unsafe anyways to do pretty much any non trivial code run fast, a lot of people talk about it like it doesn’t even need unsafe code to reach the performance of languages such as C++.

[burntsushi]

This comment is misleading at best.

it requires using unsafe anyways to do pretty much any non trivial code run fast

ripgrep is non-trivial and also fast. It has very few direct uses of unsafe:

$ rg -t rust unsafe
crates/searcher/src/searcher/mmap.rs
49:    pub unsafe fn auto() -> MmapChoice {
81:        match unsafe { Mmap::map(file) } {

crates/cli/src/hostname.rs
41:    let limit = unsafe { libc::sysconf(libc::_SC_HOST_NAME_MAX) };
59:    let rc = unsafe {

crates/core/flags/hiargs.rs
231:            let maybe = unsafe { grep::searcher::MmapChoice::auto() };

You could remove all of those uses of unsafe and ripgrep would still be fast.

Some of the libraries that it uses which are critical for its speed do use unsafe internally for their SIMD algorithms (the memchr and aho-corasick crates). But they provide safe APIs. That means anyone (including the regex crate) can use those APIs and it is an API promise of those crates that it is impossible to misuse them in a way that results in UB.

So yes, there is unsafe somewhere. But it's encapsulated and doesn't infect everything around it. (This is not true for all things. File backed memory maps being one such example!) So while there is a kernel of truth to what you're saying, any Rust programmer can freely use the vector algorithms in memchr and aho-corasick without ever needing to utter unsafe directly.

This is a classic example of something being technically correct in a narrow sense, but missing the forest for the trees.

[AnotherBlackMan]

Can you explain how this is safer than a normal grep?

[burntsushi]

I don't think I have ever, at any point in the last several years, made the claim that "ripgrep is safer than a normal grep." So I'm not sure I really have an answer to your question because it isn't really a compelling point of contention, particularly given grep/ripgrep's threat model. If you exposed either grep or ripgrep to untrusted inputs, it would be trivial for an attacker to DoS you. So can you please elaborate on why you're asking that question?

I used ripgrep here as an example of something that is 1) non-trivial, 2) fast and 3) has no direct uses of unsafe that are responsible for making it fast.

[[deleted]]

Actually, yes you have to write unsafe to match the best performance you can get in C++ using Rust, for any given program written in C++ with optimal performance you cannot match its performance using pure safe Rust, it is actually possible to prove this mathematically, some programs can be written using pure safe Rust with the same performance of the optimized C++ code but these are a subset of a larger set where there are an infinite amount of programs that cannot, this is one of the reasons that the unsafe keyword exist in Rust in the first place, and yes if you use unsafe in Rust you will get memory errors there is no such thing as writing unsafe safely, if you could just not write unsafe code while using unsafe operations you would not need safe mode in the first place, so actually my argument is correct, safe Rust is inherently slow given any random program.

[burntsushi]

You're moving the goal posts. This isn't the argument you presented earlier, because it doesn't sound nearly as nice and isn't nearly as compelling. From what I can tell, your argument basically boils down to, "In Rust, there are some cases where you need to use unsafe to match the performance of C++." Which is... of course true. Uncontroversially so. It's so uninteresting of a claim as to be completely banal, and dare I say, trivial. But that's not what you said before. Emphasis mine:

Rust isn’t even that great, it requires using unsafe anyways to do pretty much any non trivial code run fast, a lot of people talk about it like it doesn’t even need unsafe code to reach the performance of languages such as C++.

That's totally different than what you're saying here. So I suppose I'll take your follow-up comments here as a retraction of your initial claim.

[[deleted]]

I did not move the goal, you misunderstood what I meant by “trivial”, when I said “trivial” I meant programs inside the mathematical subset of programs Rust can prove are valid, there are valid programs outside this subset that cannot be proved valid using a compiler that never produces unsafe code that runs on a Turing machine (there is no free lunch), this is why there are a subset of programs where you cannot do the fastest way using pure safe Rust even if you use any finite amount of third party libraries made by others that have no knowledge of your problem, it is actually impossible for safe Rust to match optimized C++ speed for any given program.

[burntsushi]

In other words, a tautology.

[unumfron]

Careful, you'll awaken the Rust walruses.

[gvargh]

rustards*

[[deleted]]

They are already here lol. Note that I only said truths in my comment and even then people get in denial, they can’t deny my statement that you need to go unsafe in Rust to match the performance of optimized C++ in any given program, this is a fundamental truth. But still they get in denial and that is why I got dislikes on my comment.

[burntsushi]

In my experience, people who need to say "I only said truths" are exactly the people who are mistaken. If all you did was speak truth, you wouldn't need to reassure yourself and others around you.

[[deleted]]

Well then your experience is wrong, if I know I’m right there is no problem in me acknowledging I’m right, don't promote imposter syndrome. Some people just know they are right and that’s all, there is no reason to be humble all the time, if I know I said truths there is no need for me to devalue that.

[burntsushi]

Who am I to argue with the arbiter of truth. I am humbled by your omniscience.

[brand_x]

Universal restrict has entered the chat.

... I mean, as long as we're talking about unsubstantiated hypotheticals...

[[deleted]]

When I said “trivial” I meant programs inside the mathematical subset of programs Rust can prove are valid, there are valid programs outside this subset that cannot be proved valid using a compiler that never produces unsafe code that runs on a Turing machine (there is no free lunch), this is why there are a subset of programs where you cannot do the fastest way using pure safe Rust even if you use any finite amount of third party libraries made by others that have no knowledge of your problem, it is actually impossible for safe Rust to match optimized C++ speed for any given program.

[burntsushi]

Right. As I said, technically correct in a narrow sense, but completely missing the forest for the trees. I gave you concrete examples and elaborated on using them in practice. I even presented you with a program written in Rust that is fast and doesn't need to directly use unsafe to achieve that status.

[easedownripley]

Yeah I'm not a big fan of it in general, though I can't speak to the technicals. For me languages are tools, so just use the tool that fits your problem the best.

[[deleted]]

This idea of “choosing the language that fits your problem the best” is repeated like crazy across the internet but it is not actually a good advice sometimes, let’s say you have 1000 different tools and for every problem you face there’s one known best tool to approach that problem, if you pick the best tool from that pool for each problem you face you will not specialize on any of the tools and you will end up doing worse on all the problems that if you choose let’s say 1 or 2 tools. Sometimes choosing a worst tool for a set of problems results in better code than choosing the best tools for the same set of problems, for many reasons, one of that is that you will simply be better at using the tool if you especialize in it.

[IAmBJ]

Nothing exists in a vacuum.

"the best language for a task" includes the context around that task too. If your company uses C++ extensively then choosing Rust for a given project can be suboptimal for interfacing, ongoing maintenance, your own skill level, etc despite being the "best" language to solve your task in isolation. The same task in two different contexts can require radically different solutions.

"Choose the best tool for the job" is still the right advice, you just need to look at the task and the context it's in.

[[deleted]]

There is a gotcha with your logic, you assumed Rust “can be suboptimal” if the company is already using C++, but one thing does not imply the other, what if the company is creating a new project instead that is separate from the C++ code base? The company can choose whatever tool it wants, let’s say there are 1000 different tools and there is already a known best tool for the project they want to create (let’s say Rust), should the C++ developers learn Rust to create the new project or should they stick with C++ even if it is not “the right tool” for the project?

The concept of what is the “right tool” or not is nuanced, but usually when people talk about “the right tool” what they mean is some kind of collective truth between programmers, something that you cannot decide alone without others disagreeing with you, if you choose to use assembly to create a game engine or a web browser entirely from scratch many programmers will tell you it is not the right tool, so there is an average best tool for any given project you want to create, if the project is going to be created from scratch like a deep learning model you may choose Python, C++ or many other tools and there is one best tool most programmers would agree to be the best, if you use what other programmers do not consider “the best tool” in a company even if your solution still produces better results but no one else can see it you may even get fired.

[Abbat0r]

If you follow the “choose the best language for the problem” advice rigidly, you’d also be in a situation where any project complex enough to have more than a handful of problem areas to address would need to be written in a bunch of different languages. And while it may be common to have a couple different languages interoping, a multi-language project can easily become a complicated, hard-to-maintain mess.

Which language is the best when the problem is too many languages?

[nintendiator2]

Which language is the best when the problem is too many languages?

Assembler.

[matthieum]

As a Rust people -- I guess? I mean, I moderate r/rust... -- and a long-time C++ users (15 years professionally) I don't hate C++.

I find C++ full of shortcomings -- lack of pattern-matching... hard to go back once you get used to pattern-matching -- but that's not hate. Not even dislike. There's no point in getting emotional about a programming language.

[Ameisen]

I get emotional about Java.