I'm thinking of things like "the system page size isn't what we thought it was" or "the condition for the conditionally-present tail-allocated bits was wrong and we didn't notice because we threw the load away until it ended up crossing into an unmapped page"
-
-
I agree Rust would help reduce the surface area of code exposed to these issues, and its ergonomics would probably encourage better management of invariants, but many of the issues we encounter seem like they're fundamentally in unsafe land
1 reply 0 retweets 9 likes -
It would be interesting to analyze the fixes to see what issues are most common and whether a better type system would have prevented them.
1 reply 0 retweets 1 like -
Like Slava said, the vast majority of our problems are invariant violations. We don't even use C++'s type system as well as we could to head these off yet. (A clean room implementation with the benefit of hindsight would probably be more robust even if it too was written in C++)
3 replies 0 retweets 10 likes -
OTOH there *are* some things that modern C++ purports to be able to model, namely linearity via move semantics, that it utterly fails to in practice, which Rust in particular could help with
3 replies 0 retweets 17 likes -
To support our C++ development, we also need fairly thorough testing at many different levels, with the full battery of asan/tsan/ubsan, etc. to have confidence in our work, and it never feels like we have enough CI. A better language might reduce the amount of test infra we need
2 replies 1 retweet 19 likes -
Well, I used to think that testing was an adequate substitute for language-enforced memory safety, and then the SQLite bug happened.
5 replies 0 retweets 7 likes -
Note that there is a reasonable argument I would agree with in there, which is “we don’t care if there are occasional memory safety problems in the Swift compiler, because we don’t run it on untrusted input.”
2 replies 0 retweets 3 likes -
The main thing I push back against is the idea that anyone can write safe C++ at scale. If you know you’re writing code that will go wrong re. memory safety on some input and you are intentionally OK with that, I can’t really argue with it.
1 reply 3 retweets 10 likes -
Aside: I see this sometimes from experienced game developers. Less experienced game devs say that they can write safe modern C++, which is obviously bogus. More experienced ones often say they know with C++ they’ll be shipping bugs, but its advantages outweigh the cost of bugs.
1 reply 1 retweet 10 likes
The latter argument is actually fairly reasonable. (Which doesn’t mean that we shouldn’t try to make Rust as suitable as possible for them now and in the future, of course.)
-
-
My spicy take would be that, even if you don’t like Rust, designing and implementing your own language to write your large program in would be cheaper than trying to write C++ at scale
3 replies 0 retweets 25 likes -
That might be true for an initial implementation but over time the cost of maintaining an in-house toolchain will really add up, and you’d be competing with Apple/Google/Microsoft/Intel for compiler developers
3 replies 0 retweets 6 likes - 15 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.