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.
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.
Or is your point just "see? Rust doesn't prevent all stupid errors!".
And yes, *sshhole is a C language problem, even if you technically can achieve it in Rust just like you technically can still write memory vulnerabilities in any memory safe language if you try hard enough. The point is that any more modern language has learned that there are several behaviors where the easy way that's typically taught should be fail-safe. Enforcing error handling is one of these. Zig didn't get on the memory safety train, but it absolutely did on get to error unions. Basically every language that's trying to be a C successor in any way is doing that. Because it turns out the "standard" C error handling and the ways that posix and libraries have traditionally done just sucks and results in idiocy like this. Even languages like Java at least realized that with try/catch there needs to be some way to enforce error handling downstream (not to say there aren't other languages that don't promote that! You won't find me defending JS on this issue for instance)
Now, can you do errors better in C? Sure you can! It may be a bit more cumbersome, generate a lot more code, and be a bit of a pain in the ass to do, but you absolutely could if you wanted to. Do you know any large popular C codebase that does though? I don't. Returning NULL or errno or -1 is what's commonly done and what most learning materials about C will tell you to do. It's the UNIX convention. Using a sentinel value for errors is just what's done in C and yes, it works just fine most of the time.
But as the post says: this is the issue. C as a language, as a set of standards, as community around them, just treats all of this a skill issue, ignoring that it is possible to increase the safety by making it more convenient to write safe code, because it's not possible to magically get rid of all issues away so why should we bother at all.*
If you actually wanted an answer to any of the others, and maybe if you can calm down a little, I'd be happy to tell you my thoughts.
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.