Comment by usamoi
1 day ago
They are not rejecting Safe C++; they are rejecting memory safety. Majority of them believes that memory safety is just hype, and minority of them knows it's a problem, but doesn't want to restrict themselves about coding. If code runs, it is fine. If it does not, coder running is fine too.
The principles document that was accepted feels very targeted at Safe C++ specifically. It’s fair to say they rejected it.
I work on a Swift/iOS app that wraps a C++ library
90+% of our crashes are from hard-to-diagnose cpp crashes. Our engineers are smart and hardworking but they throw their hands up at this.
Please tell me my options aren’t limited to “please be better at programming”…?
Does iOS let you run it in another process? That's a common technique to isolate your app from crashy 3rd party components. This can work if you don't pass it untrusted data. If there's untrusted data coming in and you give it to a crashy c++ component, you're just asking to be pwned.
For containing legacy C++ codebases https://news.ycombinator.com/item?id=45133938 .. but currently doesn't support iOS.
> Our engineers are smart and hardworking but they throw their hands up at this.
Since you don't think this is a skill issue, shouldn't you support Safe C++, which eliminates unsafety rather than just turning a blind eye to it?
> Please tell me my options aren’t limited to “please be better at programming”…?
You can only use Valgrind/ASan, stress testing, and rewriting in other languages to pay off the technical debt. Even if a god points out every bug in your code, you'd still need to put in great effort to fix them. If you don't pay for it while coding, then you must pay for it after coding. There are no shortcuts.
Have you tried enabling asan? It’s not really the same kind of language guarantees but it does catch a lot of the same errors.
In general I think static analysis is a crutch for C++ to claim safety but it is still a very useful tool that devs should use in development.
Sorry, but yes, when your app crashes there could be two issues. The C++ library that you use is shit, or your engineers don't understand the underlying concept of allocating/deallocating things because for Swift they had never to learn them. With Rust the code just wouldn't compile at all, that the only difference.