Personally, I've never met anyone who can ensure memory safety in their C/C++ without onerous restrictions even more severe than those rust imposes, but maybe you're superhuman.

I've done professional c++ for a couple decades. My pipelines usually were conan with some dependencies that were not. The used clang tidy and format, san, cppcheck, coverity and tested release and debug builds with clang and gcc. Coverage was sometimes just clang. But sometimes gcc as well. Tests were usually google test. The team standard IDE was vscode.

Rust has rustfmt which is one standard. It has clippy which in addition to actual defects it forces commin idioms so code looks familiar. It has san and llvm coverage. It has miri. It supports aflop for fuzzing. And it has a single tool for package management and build. Edit: IDE is still vscode and it works great.

The only tooling missing for rust would be formal analysis, which is in work (and which isn't that great a story on c++ either) and gcc. A gcc front end is in work, and there is mrustc to generate c from rust, but yes, gcc front end support would be nice to get all those extra targets without the extra work.

But of course there are use cases where you need memory safety guarantees and bare metal performance. In those cases, sacrificing some memory safety by using Rust is an acceptable tradeoff I think.

All memory-safe languages are built on an unsafe foundation. The Java HotSpot VM is very unsafe C++. That's just how computers work.

You aren't meaningfully sacrificing memory safety by using Rust because the unsafe sections are clearly marked out. That's similar to unsafe C#, Python with ctypes, and many other memory-safe languages.

No, it doesn't. What's interesting isn't so much that random HN posters believe this sort of thing, because hey, who needs to know anything about a topic to post their opinion on a forum right? No, what's fascinating is that this applies to people like Herb Sutter in his "cpp2" language, here's Herb:

> I don’t like monolithic "unsafe" that turns off checking for all rules

Nobody does that. It's possible Herb knows that and is being deceitful but honestly I think it's more likely that without investigating at all Herb has just decided everybody else is an idiot...

    fn trust_me_i_dont_need_a_borrow_checker<'a, 'b> (x: &'a mut u32) -> &'b mut u32 {
        unsafe { core::mem::transmute(x) }
    }

    fn main() {
        let mut owned = vec![40, 2];

        let mut_1 = trust_me_i_dont_need_a_borrow_checker(&mut owned[0]);
        let mut_2 = trust_me_i_dont_need_a_borrow_checker(&mut owned[1]);

        drop(owned);

        let undefined = *mut_1 + *mut_2;
        println!("The answer is {undefined}");
    }

The exact same code, without the transmute (just returning x directly from an unsafe block), fails a type check related to borrowing. Specifically, the compiler can't see why (without a transmute) it should believe that the reference x now has a different lifetime 'b instead of 'a. Which is fair because it doesn't.

The transmute is you claiming it does, and since transmute is an unsafe function that's entirely on you to make sure you're right about that. So, lying has the expected effect.

The borrow checks aren't magic, they can't look into your soul - but they are running inside unsafe code too.

* Edited to make explicit that the alternative is still marked unsafe and yet doesn't work

I think that’s an unusual way frame that requirement.

All programs need to handle memory _correctly_. Very few seg fault as part of expected operation.

Is that better?

That, and the borrowing/safety aspects of Rust also shake out into threading/concurrency, where the compiler does a pretty good job of forcing you to adopt better practices in regards to state sharing, locking, concurrency.

Cargo, though... I am coming around to thinking isn't great -- workspace support remains half-assed, especially... and crates.io is amateur-hour for reasons many people have pointed out elsewhere on this post. I have been tempted to switch my personal projects to bazel, with 3rd-party deps checked in/submoduled.

And it offers those things along with a fantastic type system, and great tooling.