4 ms·

> How much more productive is an software engineer that uses Rust compared to one that uses, say, C/C++? That is to say, do I need fewer software engineers to d

> How much more productive is an software engineer that uses Rust compared to one that uses, say, C/C++? That is to say, do I need fewer software engineers to deliver the same product if they use Rust rather than another language? Anyone who's used both in production for any length of time can tell you that you will not deliver the same product in C++ unless you're willing to put in JPL levels of investment. So yes, it's far more productive for "the same product." The question is what you mean by "the same product." Do you consider a project implementing a feature set with loads of memory errors to be functionally the same thing as one without? If you do, then Rust probably won't be that much more productive than C++ (IME still more productive, but within the realm of subjectivity). If you do not, then it's not even close. This is the calculation companies like Microsoft and Google have been doing when they invested in Rust for new OS development.

mytailorisrich 5y ago
The same product means seemingly the same thing in the hands of the customer. Users does not care or know whether MS Word is written in C++, Rust, or what not, they just see what the product can do and how well. Maybe that's a good way to compare productivity: Let's say you have to develop and maintain MS Word. What's the size of the team if you do in C++ vs Java vs Rust vs whatever? The smallest team has the highest productivity by definition, all else being equal.
- 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 ago
    There 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 ago
      It 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.

mytailorisrich 5y ago

The same product means seemingly the same thing in the hands of the customer. Users does not care or know whether MS Word is written in C++, Rust, or what not, they just see what the product can do and how well. Maybe that's a good way to compare productivity: Let's say you have to develop and maintain MS Word. What's the size of the team if you do in C++ vs Java vs Rust vs whatever? The smallest team has the highest productivity by definition, all else being equal.

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 ago
  There 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 ago
    It 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.