Any situation where C would segfault immediately, Rust would also segfault immediately. The only difference is that Rust references are an alternative to C pointers that provide stronger safety guarantees at the cost of restricting what is possible (in other words, the same tradeoff that all static analyses make, including every type system). You can also use C-style pointers in Rust, but you can get away with just using references the vast majority of the time, which gives you better memory safety guarantees at no runtime cost since references are just pointers at runtime (and they're often automatically marked as restrict pointers at that). You're not going to get Heartbleed in Rust by using references.
> Any situation where C would segfault immediately, Rust would also segfault immediately.
For equivalent code, yes.
The borrow checker can however compel you to write code that would not immediately panic in Rust, when the C code you would have written has at least a chance of segfaulting immediately or being detected with valgrind.
The example that kicked off this discussion, replacing references or pointers with array indices, is presumably one example you're thinking of?
The problem with using that example to make this argument is that it is the equivalent code. Jonathan Blow's argument was not that the borrow checker forces people to use a worse pattern - he uses basically the same pattern in C - but that the borrow checker doesn't help you with that pattern, and so the borrow checker is extra friction.
Now, Catherine West's argument in the keynote video was that the borrow checker pushes people toward this better design, albeit without helping solve the use-after-"free" aspect, while Jonathan Blow says he would just start there as an experienced game developer, so he doesn't need to be pushed.
There's also the fact that the borrow checker isn't completely gone, and still applies to any references you put in the array or temporarily take to the array or that don't involve the array at all; as well as the fact that Rust also helps with things like parallelism, which definitely applies to games and doesn't need to be "bypassed."
I'm afraid I don't follow. Can you give me an example of the borrow checker compelling one to write such a piece of code? I admit I can't think of an example of Rust code that would fail to panic when the equivalent C code would tend to segfault.
The issue isn't the equivalent of Rust code in C, it's C code without an equivalent in Rust.
Rust should prevent the typical UAF bug in C, but if the programmer unwisely insists on using the same pattern in which they fail to track object lifetimes correctly, they can still implement it by using array indexes instead of pointers. Which can also be done in C (as was the case in Heartbleed), but it isn't as common, and is potentially worse than the usual C UAF because it produces a consistent successful out of bounds access rather than at least the possibility for a segfault.
It's possible to prevent someone from doing something bad and have that cause them to do something worse. "Nothing is foolproof to a sufficiently talented fool" etc. Safer tools are not a replacement for competence.
> The issue isn't the equivalent of Rust code in C, it's C code without an equivalent in Rust.
I'm afraid I still don't follow; Rust also has C-style pointers, they just require one to use the `unsafe` keyword to dereference. I can't think of any C code that can't be expressed in Rust in this way.
> Rust should prevent the typical UAF bug in C, but if the programmer unwisely insists on using the same pattern in which they fail to track object lifetimes correctly, they can still implement it by using array indexes instead of pointers.
I don't see how this shows that Rust is any more dangerous than C; a C programmer is no less capable of mistracking object lifetimes. Furthermore, array access are checked by default in Rust; even in the degenerate case of using the `get_unchecked` method (which requires the `unsafe` keyword as well), that's no more dangerous than every C array access.
> Safer tools are not a replacement for competence.
Why can't we as an industry have both safe tools and competent programmers? These are not mutually exclusive.
> I'm afraid I still don't follow; Rust also has C-style pointers, they just require one to use the `unsafe` keyword to dereference. I can't think of any C code that can't be expressed in Rust in this way.
What I mean is without an equivalent in Rust that doesn't require unsafe, which people are correctly admonished to avoid using whenever possible.
> I don't see how this shows that Rust is any more dangerous than C; a C programmer is no less capable of mistracking object lifetimes. Furthermore, array access are checked by default in Rust; even in the degenerate case of using the `get_unchecked` method (which requires the `unsafe` keyword as well), that's no more dangerous than every C array access.
The equivalent things are equivalent. The issue is that if you call one dangerous thing unsafe but not another thing that is as or more dangerous, the naive programmer assumes that not having to use unsafe means whatever they're doing is safe.
And it's little help to bounds check the array because that wasn't the problem. The data the programmer was expecting to be at that index isn't there anymore but the array itself still is and there is now some other data there.
> Why can't we as an industry have both safe tools and competent programmers? These are not mutually exclusive.
It's not that we can't have both, it's that we should have both.
Whenever we get better tools, people are tempted to hire worse programmers, because better programmers are more expensive and worse programmers with better software should be as good as better programmers, right?
This is obviously at odds with the ideal of using the new tools to create better software, and doesn't actually work, because a smoke detector can't save you if you don't know what to do when it warns of low battery.
