- Rust isn’t totally guaranteed safe since folks can and do use unsafe code.
- Exact same situation in Swift
- Go has escape hatches like it you race, but not only.
So most “safe” things are really “safe enough” for some definition of “enough”.
- Rust isn’t totally guaranteed safe since folks can and do use unsafe code.
- Exact same situation in Swift
- Go has escape hatches like it you race, but not only.
So most “safe” things are really “safe enough” for some definition of “enough”.
Profiles do not, even for code that is 100% using profiles, guarantee safety.
So, no matter what safe language we talk about, "safety" always has its caveats.
Can you be specific about what missing safety feature of profiles leads you to be so negative about them?
It’s not about specifics, it’s about the stated goals of profiles. They do not claim to prove memory safety even with all of them turned on.
An entire program ported to Rust will call into unsafe APIs in at least a few places, somewhere down the call stacks.
But you'll still have swathes of code that doesn't ultimately end up calling an unsafe API, which can be trivially considered memory safe.
It does not guarantee that code in any function being called within that block is free of it, but it does guarantee this block of code is.
Profiles don't give you that.
Rust does a pretty good job formalizing what the safety guarantees are and when you can assume them. Other languages don't, but they also don't support safety concepts that C++ nominally does like safety critical systems. "Good enough" can be perfectly fine for a web service like Go while being grossly inadequate for HPC or safety critical.