this post was submitted on 19 Mar 2024
145 points (92.9% liked)
Programming
17540 readers
71 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You can do that in basically any language. Rust even has the ability to break out of its safeguards and write unsafe Rust code.
"Memory safety" in this context is more about the defaults and how easy it is to write unsafe code accidentally.
Unsafe Rust really just let's you play with pointers
This is the entirety of what Unsafe Rust allows
And what does that exclude that C or C++ has that's memory unsafe? I suppose use after free?
Dereference a pointer without a bounds check is the major problem when we're talking about memory safety.
Accessing a union that's in an invalid state is also a big problem.
Use after free... Maybe?
Thread safe code isn't the issue otherwise Java, Python, etc would all be on the list of languages to run from.
Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn't using range-based loops).
A lot of these issues can be avoided in C++ by just using existing types like
std::variant,std::unique_ptr,std::shared_ptr,std::array, andstd::vector(with theatbased accessor) instead of lower level constructs.What Rust provides is statically guaranteed memory safety. Some C++ types will prevent memory issues however the language itself is unsafe. Playing with raw pointers is just as valid as using
std::unique_ptr. In Rust however you must sign a contact (usingunsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it's illegal to write UB and your program will break (and it's your fault) but enforced through a special type of blockWhich is what I said, this is about the default.
My issue is not that I don't understand Rust provides static guarantees. My issue is that you raised a comparison between unsafe Rust and C++ code. In that comparison, you're basically saying "writing an entire program in a rust unsafe block would be better than writing an entire program in C++" and I think that is very wrong.
Rust unsafe is not better than normal C++ while following best practices for maintaining memory safety.
I wouldn’t be so sure myself. Even unsafe Rust still uses the borrow checker, for instance. And you still get stricter checks around overflows and such as well. What unsafe does is that it unlocks the ability to use raw pointers and call other unsafe functions (among a few other things), but importantly it doesn’t disable the safety features that Rust has built-in. While unsafe Rust does indeed have some gotchas on its own, I think in general you’re still better off even with unsafe Rust than with C++.