Comment by nickpsecurity | Hacker News Reader

Comment by nickpsecurity | Hacker News Reader

Parent Full thread

"E.g. Rust gives you memory safety through ownership, but you can't even make a doubly-linked list while staying within the ownership system."

Your otherwise good comment presents this like all-or-nothing when comparing it to C. To start with, C and Rust are equivalent for anything it cant borrow-check. Then, it's better than C in safety or expressiveness from there. Second, C developers use plenty external libraries to supplement the language's capabilities, including with ASM breaking abstraction gap. Likewise, whatever Rust cant handle can be proven safe with external tool, wrapped in safe interface, and used from there. This has been done in languages from C to Haskell.

So, there's different design points for sure but doubly-linked-list isnt an example of unfit for purpose vs C. If anything, that it's equal or better in safety making it a better instance in that design space. Likewise for Clay which was more C-like and used in device drivers.

But at the end of the day, I wouldn’t call it a categorical improvement over C because you still have to drop down to what is basically C to handle essential tasks like declaring circular data structures. Instead, it makes a special (but common) case of tree-like data structures safer to handle. This is no fault of Rust—it is a theoretical limitation. There is no single model that let’s you express arbitrary data structures, gives you memory safety, and doesn’t require runtime heap walking.

Again, that sounds more limited or narrow than what people are actually building in safe Rust. The ecosystem has piles of software that would've been in C. Likewise, that it cant handle a few primitives doesnt matter if I can prove them separately using a VCC-like tool for a subset of unsafe Rust, one that generates Rust, or one that does assembly. That these situations are fairly uncommon is suggested from fact that people always bring up the same examples which C does no better on by itself. Whereas, all the rest of the code outside those components will be safer and more maintainable than C. So, it beats it on a number of dimensions at language level despite remaining unsafety.

Whereas, if we count tooling, C is still safer than Rust given there's more verification tools available plus certifying compilers. You have to use many of them with a subset of C easy to analyze, though.

The biggest difference is that in C, 100% of the code is unsafe and possibly UB, while in other system languages with unsafe code blocks those low level tricks are pretty easy to track down.

Many seem to have the illusion that if you use unsafe in Rust, bad things can only happen in the unsafe blocks.

This is wrong. If your unsafe block fails to maintain the required safety guarantees (I personally don't know what they are), then the safe code could break terribly as well. And figuring out which unsafe block is the culprit can be really hard too.

I don't have that illusion.

Logic errors are always bound to happen in any language.

Problem in C is that every single line of code is either unsafe or potentially UB, specially at -O3.

And yeah everyone can always assert it doesn't happen to them, but that assertion does not hold when working in teams or using third party code.

So it is already a big security improved if the attack space is largely reduced.

Also unsafe blocks aren't nothing specific to Rust. A few system programming languages since the 60's have them.

Reply on news.ycombinator.com