3 ms·

An additional issue is that some sophisticated C++ doesn’t always translate easily into other languages. It isn’t just a fairly direct reimplementation but a le

An additional issue is that some sophisticated C++ doesn’t always translate easily into other languages. It isn’t just a fairly direct reimplementation but a legit redesign. That will be a bug factory, especially for the kinds of codes that tend to be difficult to translate, as proving equivalence won’t be trivial.

lmm 6y ago
I'd submit that the kind of code that's difficult to translate - that is, code where it's not clear where the responsibility for the lifecycle of a given piece of memory lies - is already a bug factory.
- jandrewrogers 6y ago
  Not at all. Modern C++ can express some memory safety and lifetime models simply and elegantly that are difficult to express in other systems languages. It doesn’t define one for you by default but it also doesn’t limit you to a single model that is clearly inappropriate for some important systems code. The bug factory, in many cases, is a consequence of having no way to properly express lifetimes in languages that only support a single lifetime model (or no lifetime at all in the case of C), therefore requiring unsafe hacks and workarounds. If, for example, your entire address space is accessed via DMA then Rust’s memory lifecycle model breaks, and this is a canonical design characteristic of all high-performance database engines. You can trivially design C++ constructs that automagically handle lifetimes under these constraints; in other systems languages you have to do a lot of fiddly manual resource management in unsafe code blocks. The idea that a single memory lifecycle model is appropriate or optimal for all systems applications is objectively wrong. C++ doesn’t implement other formally verifiable safety models but it provides the tools required to elegantly build applications using them and largely hide making them safe. This is one of the well-known strengths of modern C++: the ability to implement many different formally verifiable memory safety and concurrency models as first-class constructs. Not every application needs it but some, certainly everything I work on, definitely do. I don’t disagree with the objective — I highly value the ability of the compiler to ensure that my code is safe.
  - pjmlp 6y ago
    Yet Microsoft and Google, despite their C++ investment into compilers and ISO seats, are also investing into hardware memory tagging, forcing static analysers down developer throats no matter what, while slowly adopting other AOT compiled languages on their products. Because while Modern C++ does indeed improve the memory safety and lifetime models, a large majority of the C++ community doesn't care about modern C++ features and has even started the Orthodox C++ campaign.
    - kaba0 6y ago
      Static analysis can benefit every sort of language, Rust included.
      - pjmlp 6y ago
        For sure, I haven't said otherwise.
- josefx 6y ago
  You haven't known suffering until you tried to rewrite a large C++ codebase in Java. No clear ownership you say? All those members that clearly belong to one object suddenly have to be guarded against accidentally having their references shared, all that clear math code turns into an indecipherable mess and you can forget about lifecycles unless you guard every resource with a try block. Sadly I end up writing Java code from time to time because I can write passable swing UIs faster than I can set up Qt.
- kaba0 6y ago
  Not every program has such a well-defined life cycle that fits into Rust’s memory model. There was a great post on why the wayland library’s rust implementation was abandoned. There was basically no point of Rust’s memory model there over C.
  - lmm 6y ago
    In the worst case you're no worse off. As several replies there said, a weak pointer model would have worked fine for that scenario.
    - kaba0 6y ago
      For new code, absolutely. But rewrites, especially when the new language can’t necessarily give huge safety guarantees as in this case are very bug-prone.

lmm 6y ago

I'd submit that the kind of code that's difficult to translate - that is, code where it's not clear where the responsibility for the lifecycle of a given piece of memory lies - is already a bug factory.

jandrewrogers 6y ago
Not at all. Modern C++ can express some memory safety and lifetime models simply and elegantly that are difficult to express in other systems languages. It doesn’t define one for you by default but it also doesn’t limit you to a single model that is clearly inappropriate for some important systems code. The bug factory, in many cases, is a consequence of having no way to properly express lifetimes in languages that only support a single lifetime model (or no lifetime at all in the case of C), therefore requiring unsafe hacks and workarounds. If, for example, your entire address space is accessed via DMA then Rust’s memory lifecycle model breaks, and this is a canonical design characteristic of all high-performance database engines. You can trivially design C++ constructs that automagically handle lifetimes under these constraints; in other systems languages you have to do a lot of fiddly manual resource management in unsafe code blocks. The idea that a single memory lifecycle model is appropriate or optimal for all systems applications is objectively wrong. C++ doesn’t implement other formally verifiable safety models but it provides the tools required to elegantly build applications using them and largely hide making them safe. This is one of the well-known strengths of modern C++: the ability to implement many different formally verifiable memory safety and concurrency models as first-class constructs. Not every application needs it but some, certainly everything I work on, definitely do. I don’t disagree with the objective — I highly value the ability of the compiler to ensure that my code is safe.
- pjmlp 6y ago
  Yet Microsoft and Google, despite their C++ investment into compilers and ISO seats, are also investing into hardware memory tagging, forcing static analysers down developer throats no matter what, while slowly adopting other AOT compiled languages on their products. Because while Modern C++ does indeed improve the memory safety and lifetime models, a large majority of the C++ community doesn't care about modern C++ features and has even started the Orthodox C++ campaign.
  - kaba0 6y ago
    Static analysis can benefit every sort of language, Rust included.
    - pjmlp 6y ago
      For sure, I haven't said otherwise.
josefx 6y ago
You haven't known suffering until you tried to rewrite a large C++ codebase in Java. No clear ownership you say? All those members that clearly belong to one object suddenly have to be guarded against accidentally having their references shared, all that clear math code turns into an indecipherable mess and you can forget about lifecycles unless you guard every resource with a try block. Sadly I end up writing Java code from time to time because I can write passable swing UIs faster than I can set up Qt.
kaba0 6y ago
Not every program has such a well-defined life cycle that fits into Rust’s memory model. There was a great post on why the wayland library’s rust implementation was abandoned. There was basically no point of Rust’s memory model there over C.
- lmm 6y ago
  In the worst case you're no worse off. As several replies there said, a weak pointer model would have worked fine for that scenario.
  - kaba0 6y ago
    For new code, absolutely. But rewrites, especially when the new language can’t necessarily give huge safety guarantees as in this case are very bug-prone.