Hacker News new | past | comments | ask | show | jobs | submit login

A full 70% of security vulnerabilities are caused by memory safety issues. As professionals we need to get serious and have memory safety as a baseline requirement.



So we shouldn't use Rust at all, since Rust is not completely memory safe since it let's you disable the borrow checker. We should be serious as professionals and use safe languages like Java, JS, Python, etc.

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.


> Rust is not completely memory safe since it let's you disable the borrow checker.

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}");
    }


If unsafe disabled the borrow checker, you wouldn't have needed that transmute. But it doesn't, so you needed the unsafe transmute to make this work.


I don't consider myself a Rust expert, but this feels like a semantic argument? You can use `unsafe` to erase lifetimes, right? I'm not saying it's a good practice, and it's not globally disabling the borrow checker or anything like that, but in theory it's possible to produce unbounded lifetimes that are incorrect. In practice it probably doesn't happen very often. Certainly less often than UB in C or C++


I don't consider this a semantic argument.

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


Ah, I forgot I was on Hacker News.

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.


Marking code unsafe lets you write memory-safe code that the borrow checker can't verify. That increases the risk of bugs but it is not the same as disabling memory safety. It is a subtle distinction.


Don't forget safety from data races. Rust's borrow checking provides much stronger protection against those than java, go, c# etc. So we shouldn't use them either.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: