4 ms·

> I have spent strictly more time in the last five years filing compiler bugs than chasing memory usage errors in my C++ code. maybe because your code isn't wo

> I have spent strictly more time in the last five years filing compiler bugs than chasing memory usage errors in my C++ code. maybe because your code isn't worth having people actively attack?

jandrewrogers 5y ago
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.
- kobebrookskC3 5y ago
  is your code as actively attacked as a web browser or iOS?
  - tempodox 5y ago
    Good luck getting Apple to rewrite iOS in Rust, so at least that part of your argument is pointless.
    - kobebrookskC3 5y ago
      no, just clarifying the difference between not encountering bugs and not having them.
      - tempodox 5y ago
        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.
        kobebrookskC3 5y ago
        the trade-offs are probably made to maximize profits for shareholders, and security is deprioritized as a negative externality.
- farresito 5y ago
  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?

> I have spent strictly more time in the last five years filing compiler bugs than chasing memory usage errors in my C++ code. maybe because your code isn't worth having people actively attack?

jandrewrogers 5y ago

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.

kobebrookskC3 5y ago
is your code as actively attacked as a web browser or iOS?
- tempodox 5y ago
  Good luck getting Apple to rewrite iOS in Rust, so at least that part of your argument is pointless.
  - kobebrookskC3 5y ago
    no, just clarifying the difference between not encountering bugs and not having them.
    - tempodox 5y ago
      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.
      - kobebrookskC3 5y ago
        the trade-offs are probably made to maximize profits for shareholders, and security is deprioritized as a negative externality.
farresito 5y ago
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?