4 ms·

I'd say it's actually the other way around. C++ in the abstract is full of half-baked, ill conceived ideas that later had to be deprecated or walked back entire

I'd say it's actually the other way around. C++ in the abstract is full of half-baked, ill conceived ideas that later had to be deprecated or walked back entirely: std::auto_ptr and memory leaks; std::shared_ptr::unique() not being threadsafe; taking the time to implement bounds checking in std::vector, but the default access operator isn't checked; corner cases with std::initializer_list leading to unexpected behavior. In practice, most C++ shops seem to limit themselves to a small subdialect of C++ that's reasonably safe. The C++ Core Guidelines are essentially an effort at canonicalizing some of these best practices and building them into the tooling. I think it's fair to say that Rust or managed code should at least be considered for any greenfield project, maybe even a hard requirement for certain domains like cryptography, networking, financial applications, etc. But I don't believe that every application needs to be security hardened to that level, and the C++ library ecosystem is still much more robust than Rust's is. Crates.io feels like a graveyard of experimental libraries that reached 40% the functionality of their C++ cousins before the commit activity dropped to zero.

marcus0x62 3y ago
> Crates.io feels like a graveyard of experimental libraries that reached 40% the functionality of their C++ cousins before the commit activity dropped to zero. Not only that, but you see a huge increase in external dependencies because of the ease of importing crates. I'll admit I have absolutely no evidence to back this up, but the crates system feels to me like the Achille's Heel of Rust's security model in two respects: 1) There's the obvious supply-chain risk in that the provenance of most of these crates is...uncertain at best... At best you can see some stats that x number of projects use the crate, and who the owner is or at least purports to be. 2) Having eliminated most memory-related vulnerabilities (or at least constrained them to unsafe blocks,) the remaining vulns are going to tend to be logic flaws, and Rust, of course makes no guarantees in that realm. If you import 1 crate, ok, you can probably audit that crate and maybe reason accurately about what your code is really doing. But, when you import a half dozen crates, and those crates have dependencies, and so on, and you end up with 100+ external dependencies, I would argue that reasoning accurately about the behavior of your code is going to be quite difficult. To me, this is a cultural problem/blindspot with Rust that will be difficult to fix.
- carols10cents 3y ago
  How are these two problems unique to Rust though?
  - marcus0x62 3y ago
    Where did I say they are unique or exclusive to Rust? I said they are problems with Rust.
kazinator 3y ago
C++ could benefit from a grassroots project to provide a from-the-ground up alternative library, which shares not a single thing with the ISO C++ one. It would provide everything: I/O streams, strings, containers, smart pointers, ... This project's number one priority would be safety, followed by ergonomics. Performance would be somewhere down the list, below portability.

marcus0x62 3y ago

> Crates.io feels like a graveyard of experimental libraries that reached 40% the functionality of their C++ cousins before the commit activity dropped to zero. Not only that, but you see a huge increase in external dependencies because of the ease of importing crates. I'll admit I have absolutely no evidence to back this up, but the crates system feels to me like the Achille's Heel of Rust's security model in two respects: 1) There's the obvious supply-chain risk in that the provenance of most of these crates is...uncertain at best... At best you can see some stats that x number of projects use the crate, and who the owner is or at least purports to be. 2) Having eliminated most memory-related vulnerabilities (or at least constrained them to unsafe blocks,) the remaining vulns are going to tend to be logic flaws, and Rust, of course makes no guarantees in that realm. If you import 1 crate, ok, you can probably audit that crate and maybe reason accurately about what your code is really doing. But, when you import a half dozen crates, and those crates have dependencies, and so on, and you end up with 100+ external dependencies, I would argue that reasoning accurately about the behavior of your code is going to be quite difficult. To me, this is a cultural problem/blindspot with Rust that will be difficult to fix.

carols10cents 3y ago
How are these two problems unique to Rust though?
- marcus0x62 3y ago
  Where did I say they are unique or exclusive to Rust? I said they are problems with Rust.

kazinator 3y ago

C++ could benefit from a grassroots project to provide a from-the-ground up alternative library, which shares not a single thing with the ISO C++ one. It would provide everything: I/O streams, strings, containers, smart pointers, ... This project's number one priority would be safety, followed by ergonomics. Performance would be somewhere down the list, below portability.