4 ms·

If you are supporting Windows or Linux, and are supporting the x86 platform, then for me the only reasons to use C++ over Rust are for compatibility with existi

If you are supporting Windows or Linux, and are supporting the x86 platform, then for me the only reasons to use C++ over Rust are for compatibility with existing code/libraries, or lack of Rust expertise on the team and no time to learn Rust. If you are working in an embedded environment Rust is still very capable, but the tooling for Rust does not seem at the level of the embedded tooling for C and C++. You can still use Rust for embedded, and there are success stories to be found in the links below. [1] https://www.rust-lang.org/what/embedded https://www.rust-lang.org/what/embedded [2] https://rust-embedded.github.io/book/ https://rust-embedded.github.io/book/ [3] https://github.com/rust-embedded/awesome-embedded-rust https://github.com/rust-embedded/awesome-embedded-rust [4] https://github.com/rust-embedded/cortex-m-quickstart https://github.com/rust-embedded/cortex-m-quickstart

pjmlp 6y ago
So giving up on Visual Studio, C++ Builder, QtCreator, NVidia NSight productivity, and fast builds via UWP/COM tooling is compatibility with existing code/libraries?
- cptroot 6y ago
  My dude, we get it, you like your IDEs. You don't have to mention it in every comment thread. If you find Visual Studio and CLion to be your desired work environments, both of them have support for Rust code via extensions. No it won't be as perfect as what you're used to, but it will be more than sufficient for most people.
  - pjmlp 6y ago
    Well, there are plenty of dudes like myself to convince to drop 50 years of mature tooling support.
- Communitivity 6y ago
  I use Visual Studio Code for both my Rust and my C++ work, and love it. Tooling support comes from plugins there. I've also used QtCreator, and hated it because for me it was a resource hog, you had to do things its way, and the Qt APIs were horribly designed.
sseagull 6y ago
> the only reasons to use C++ over Rust are for compatibility with existing code/libraries, or lack of Rust expertise on the team and no time to learn Rust But these are huge reasons. It is the difference between theory and practice. In theory you can just replace C++ with Rust. In practice, it can be difficult because of those reasons. Choosing a language isn't just about the language, but about the entire ecosystem and community.
- nilkn 6y ago
  It really depends. In some domains, compatibility is a big enough reason as to completely rule out Rust or Go. In other domains, it's just not something you need at all.
jandrewrogers 6y ago
No, for things like database engines C++ still has significant expressiveness and memory model advantages. While you could write something equivalent in Rust, it would require a lot of "unsafe" since it can't express the memory semantics of some modern architectures and it would require much more code.
- andrekandre 6y ago
  as someone whos really interested in this kind of thing, what kind of memory semantics specifically does c++ support compared to rust?
  - jandrewrogers 6y ago
    A couple examples: Rust requires references to memory to be visible at compile time. If you use direct DMA for I/O then the silicon holds mutable memory references at runtime that are not visible in code at compile time. In C++ you can make ownership objects (in the vein of unique_ptr) that automagically track the lifetime of DMA references. Exposing most of your address space to DMA is not optional in databases if you care about performance. DMA has other nuances as well e.g. it can modify memory that is not part of the object you care about and which might be "owned" by someone else. There are safety models wherein it is provably safe, and optimal code-wise, for multiple mutable references to the same object to coexist at runtime. Modern databases often use schedule-based safety, which dynamically reorders operations on references at a fine-grained level, for performance reasons, and which guarantee correctness of the aggregate execution graph without using locks. This wasn't common a decade ago but it is today. A developer can grab all the mutable references they need to objects, knowing that the execution scheduler can see through and arbitrate any potential conflicts. (This is a sophisticated reimagining of the old "deadlock-free" locking structures in databases without the locks, which didn't prevent deadlocks per se but transparently detect and resolve them.) You can make all of this work in Rust by using a lot of "unsafe" and inelegant data structure workarounds but it voids most of the safety benefits of Rust and requires more complex code.
    - andrekandre 6y ago

pjmlp 6y ago

So giving up on Visual Studio, C++ Builder, QtCreator, NVidia NSight productivity, and fast builds via UWP/COM tooling is compatibility with existing code/libraries?

cptroot 6y ago
My dude, we get it, you like your IDEs. You don't have to mention it in every comment thread. If you find Visual Studio and CLion to be your desired work environments, both of them have support for Rust code via extensions. No it won't be as perfect as what you're used to, but it will be more than sufficient for most people.
- pjmlp 6y ago
  Well, there are plenty of dudes like myself to convince to drop 50 years of mature tooling support.
Communitivity 6y ago
I use Visual Studio Code for both my Rust and my C++ work, and love it. Tooling support comes from plugins there. I've also used QtCreator, and hated it because for me it was a resource hog, you had to do things its way, and the Qt APIs were horribly designed.

sseagull 6y ago

> the only reasons to use C++ over Rust are for compatibility with existing code/libraries, or lack of Rust expertise on the team and no time to learn Rust But these are huge reasons. It is the difference between theory and practice. In theory you can just replace C++ with Rust. In practice, it can be difficult because of those reasons. Choosing a language isn't just about the language, but about the entire ecosystem and community.

nilkn 6y ago
It really depends. In some domains, compatibility is a big enough reason as to completely rule out Rust or Go. In other domains, it's just not something you need at all.

jandrewrogers 6y ago

No, for things like database engines C++ still has significant expressiveness and memory model advantages. While you could write something equivalent in Rust, it would require a lot of "unsafe" since it can't express the memory semantics of some modern architectures and it would require much more code.

andrekandre 6y ago
as someone whos really interested in this kind of thing, what kind of memory semantics specifically does c++ support compared to rust?
- jandrewrogers 6y ago
  A couple examples: Rust requires references to memory to be visible at compile time. If you use direct DMA for I/O then the silicon holds mutable memory references at runtime that are not visible in code at compile time. In C++ you can make ownership objects (in the vein of unique_ptr) that automagically track the lifetime of DMA references. Exposing most of your address space to DMA is not optional in databases if you care about performance. DMA has other nuances as well e.g. it can modify memory that is not part of the object you care about and which might be "owned" by someone else. There are safety models wherein it is provably safe, and optimal code-wise, for multiple mutable references to the same object to coexist at runtime. Modern databases often use schedule-based safety, which dynamically reorders operations on references at a fine-grained level, for performance reasons, and which guarantee correctness of the aggregate execution graph without using locks. This wasn't common a decade ago but it is today. A developer can grab all the mutable references they need to objects, knowing that the execution scheduler can see through and arbitrate any potential conflicts. (This is a sophisticated reimagining of the old "deadlock-free" locking structures in databases without the locks, which didn't prevent deadlocks per se but transparently detect and resolve them.) You can make all of this work in Rust by using a lot of "unsafe" and inelegant data structure workarounds but it voids most of the safety benefits of Rust and requires more complex code.
  - andrekandre 6y ago