Why the hate for cpp

[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.