Posted by hasheddan 23 hours ago
http://cakecc.org/playground.html?code=I2luY2x1ZGUgPHN0ZGlvL...
Most of the problems described in Rust manuals as things C cannot prevent, such as memory leaks, double frees, and use-after-free, can be detected at compile time in Cake with very few annotations.
Sure, Rust's std::result can make it harder to dumb, but dumb can always find a way.
> You can very well write a Rust function that returns "*" if the password is too long. But the big difference between C and Rust in this regard is that the norms of the Rust community do not allow that.
Taking a different perspective, there are two intertwined thoughts in the original article and in most comments: 1) language safety, 2) community safety.
Each needs to assessed on its own.
Even though it's been beaten to death, I think there are still interesting discussions to be had about the problems in C, possible solutions to those, and which ones Rust provides at what cost. Really, I wish we had a few more options in the "memory safe languages without a garbage collector" space. However, junior evangelists who make themselves feel safer by finger pointing aren't likely to add much value to the conversation.
This particular post is unusual, because it's not even about a flaw in C. Appealing to Rust's culture and norms isn't compelling to me, and it will be insufferable if the newbies start regularly trotting out this nonsense.
I pasted that link to show that Rust doesn't save you from logic errors. I think the best way to get better at programming is to keep doing it while learning from mistakes. I think the best way to proselytize Rust is to finish and deliver good software with it.
I think you might want to look up my body of work, and also lay off on the baseless accusations of sockpuppetry.
> This is not a memory safety vulnerability; rather, it is one of those issues that, people often say, languages with better type systems won’t save you from. This is true! You can very well write a Rust function that returns "" if the password is too long. But the big difference between C and Rust in this regard is that the norms of the Rust community do not allow that.*
It's like blaming poor driving on one's tracksuit.
I love K&R as much as the next guy but special magic ASCII chars multiply defined by convention over 40 years is exactly the sort of rubbish a good type system can protect against (if used).
Consider how much easier it is in rust to do tagged unions that won't have the same pitfalls as C's, how much more likely you are to use a rust map from std rather than custom / imported dependency to do that in C, how much more likely you are to do real Unicode processing in rust vs treating strings as opaque bytes and hoping for the best in C. These are things that happen all the time. We can improve design and engineering a lot by simply providing an easy way to get it implemented.
The first time you need a string map in an existing C code, it's often "an event". Do you spend time rolling your own? Do you include a library? How big - are you pulling the whole glib? Do the strings need fancy locale aware comparison? Do you simplify, take a performance hit, and just scan an array instead?
A lot of the time when there's a logic bug and people comment "that's not a memory safety issue, Rust wouldn't protect from it", it's true, but I also think: "but this issue wouldn't exist because enum/type matching would stop it".
"It's a shame, but what can we do? There really isn't anything we can do to prevent memory safety vulnerabilities from happening if the programmer doesn't want to write their code in a robust manner"
It’s called pay attention and f*king upgrade your packages.