4 ms·
I didn't say anything about consumers caring whether a program was written in C++ or Rust, and I don't think consumers care about that. I talked about whether
by Jweb_Guru 5y ago
I didn't say anything about consumers caring whether a program was written in C++ or Rust, and I don't think consumers care about that. I talked about whether the product is full of memory unsafety or not. Where that is a relevant aspect of your product, Rust is far, far more productive--it's more or less impossible to produce a large C++ program without exploitable memory unsafety bugs, while it's fairly tractable in Rust. Where it is not, I expect productivity gains to be modest at best.
My point here is that there is pretty much no sized team that will deliver a C++ program with equivalent functionality to Rust, when considering security as part of the feature set. We know that about 70% of CVEs in memory unsafe programs come directly from exploitation of UB, that there is no commensurate increase in CVEs in safe languages, and that only about 1% of LOC is unsafe--so weighing the percentage security bug reduction is pretty easy. But not all customers prioritize security very much, so Rust's benefits over C++ in this context will have to be downgraded according to how highly they value a 70% reduction in CVEs. That is why I said it depends on the product--you can't come up with a flat "productivity" metric, like you seem to want, that applies the same to every situation.
- mytailorisrich 5y agoThere is indeed a flat productivity metric. But of course, a programming language being a tool, its impact on productivity varies from product to product. I think my previous comment stands: Do you need fewer people to develop and maintain the product? That applies to every situation.
- Jweb_Guru 5y agoIt entirely depends on what you mean by "the product" and I can't help but feel that you are deliberately missing my point. Suppose we take it as a given that for any given program, ignoring performance, a pure Python program requires fewer developers to implement the same number of features than the same program in C++; does it then follow that we would need fewer Python developers to build a web browser than C++ developers? It does not, because you simply could not build a web browser in pure Python that would fulfill people's performance expectations. But for many other projects, the claim does follow, because they are within the realm of "stuff you can do in pure Python." My claim is that a similar phenomenon applies for C++ and security, regardless of whether Rust is otherwise more productive: no matter how many people you add to a large C++ project, you are not going to come close to the level of assurance on security properties that you get from a Rust program of the same size (your only real hope is formal verification, which for verifying code in just about any language is multiple times less productive than writing the same code without verification). For these cases, asking which is more productive is pointless--C++ cannot deliver the expected product. However, if this is not the case for your project, I believe Rust's productivity benefits are more modest and are probably outweighed by things like team experience and available tooling. I think I'm being pretty clear here about what I mean and why your question does have a single answer that applies in all situations.