Hacker News new | past | comments | ask | show | jobs | submit login

My experience is the same as theirs. In recent years I've run into more compiler bugs than memory bugs in the large, complex C++ code bases I work with.

It makes sense. A common use case for C++ today is writing high-performance software, where the software architecture is likely to be schedule-driven (e.g. thread-per-core, userspace I/O, etc). In these cases, you see minimal heap allocation, shared structures, or locking. Modern C++ is pretty safe by default for this; it allows you to do unsafe things, and to do safe things that the Rust compiler deems unsafe, but there isn't a cabal forcing people to write non-idiomatic unsafe C++ code in software architectures where the code is naturally almost entirely single-threaded and with few heap allocations.

The most insidious bugs I see in modern C++ code bases are scheduling bugs e.g. logical or behavioral edge cases due to pure async execution, which can be very subtle. Rust doesn't help with that.




As someone that doesn't work in this space, I'm interested in the schedule-driven architectures that you mention. Do you know of any talks where they explain this or, if you have some time, could you explain how the approach has changed over the past couple of decades, what architectures were common in the past, their issues, and what issues this fixes?


is your code as actively attacked as a web browser or iOS?


Good luck getting Apple to rewrite iOS in Rust, so at least that part of your argument is pointless.


no, just clarifying the difference between not encountering bugs and not having them.


Then you should have said that. This actually makes sense.

Apart from that, everyone even half competent would know that and make a trade-off involving other factors. Being dogmatic about a single facet isn't helpful.


the trade-offs are probably made to maximize profits for shareholders, and security is deprioritized as a negative externality.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: