4 ms·

> There are also other types of safety beyond memory safety that are better supported in C++ than other systems languages. Such as? Genuinely curious.

jandrewrogers 3y ago
C++20 has very powerful compile-time metaprogramming and generics facilities. As a consequence, you can codegen complex systems of data structures and algorithms that are verified to be both optimal and safe at compile-time, essentially from a specification. The ability to automagically infer and codegen use-case specific types means that there are almost no naked primitive ‘int’ and similar types anywhere, the types are restricted to what they need to express and little more. While there is some ability to formally verify the correctness of these type interactions at compile-time, it is limited as a practical matter. The real strength is the ability verify the properties pretty exhaustively at runtime, given sufficiently good testing. If you implement something like a database kernel almost entirely in user space, which is what you want to do if you care about performance, you have a new set of problems that languages like Rust were not designed to solve. Ownership, mutability, and lifetimes are not resolvable for most objects at compile-time, they can only be resolved dynamically at runtime. With C++, you can make these look like ordinary objects with ordinary behaviors, with metaprogramming abstractions under the hood arbitrating the chaos. Things that look unsafe are actually guaranteed safe by the underlying abstractions. In this type of software, almost your entire address space is “unsafe” in some way, so it is enormously useful to be able to overlay a safety model that does not rely on the compiler, since the compiler cannot solve these cases. I use both C++ and Rust in production environments. There are cases where C++ used well is legitimately safer, theoretically and empirically, which is why I still use C++ for some things. Rust may become stronger at dealing with these cases but it still has many years to go. (Also, Rust async story is a hot mess, and you really need async for scalable, performant systems software.)

jandrewrogers 3y ago

C++20 has very powerful compile-time metaprogramming and generics facilities. As a consequence, you can codegen complex systems of data structures and algorithms that are verified to be both optimal and safe at compile-time, essentially from a specification. The ability to automagically infer and codegen use-case specific types means that there are almost no naked primitive ‘int’ and similar types anywhere, the types are restricted to what they need to express and little more. While there is some ability to formally verify the correctness of these type interactions at compile-time, it is limited as a practical matter. The real strength is the ability verify the properties pretty exhaustively at runtime, given sufficiently good testing. If you implement something like a database kernel almost entirely in user space, which is what you want to do if you care about performance, you have a new set of problems that languages like Rust were not designed to solve. Ownership, mutability, and lifetimes are not resolvable for most objects at compile-time, they can only be resolved dynamically at runtime. With C++, you can make these look like ordinary objects with ordinary behaviors, with metaprogramming abstractions under the hood arbitrating the chaos. Things that look unsafe are actually guaranteed safe by the underlying abstractions. In this type of software, almost your entire address space is “unsafe” in some way, so it is enormously useful to be able to overlay a safety model that does not rely on the compiler, since the compiler cannot solve these cases. I use both C++ and Rust in production environments. There are cases where C++ used well is legitimately safer, theoretically and empirically, which is why I still use C++ for some things. Rust may become stronger at dealing with these cases but it still has many years to go. (Also, Rust async story is a hot mess, and you really need async for scalable, performant systems software.)