3 ms·

I'm not sure that we're measuring productivity correctly these days. Take AI, for example. Going from barely being able to play chess, to winning at Starcraft a

I'm not sure that we're measuring productivity correctly these days. Take AI, for example. Going from barely being able to play chess, to winning at Starcraft and Go and basically any game Google thinks is worth cracking is a huge, huge leap in technological capacity. What was the impact of the people that worked on these and related technologies on "productivity"? You can count apples. You can't really quantify DynamoDB or Rust on the economy. Now, median worker productivity growth seems like it's drastically slowed and I think we have real problems in the economy, but as everything started merging with tech it gets harder to see the full picture.

mytailorisrich 5y ago
Oh we are measuring productivity correctly. 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? If the answer is "not really", then Rust does not increase productivity (I don't know the answer, btw). In general, I don't think that software as a tool made much difference to people's productivity in the last 20 years or so. The boost enabled by internet connectivity was probably over by ~2005. Since then not much has happened. Uber, Deliveroo, etc. are great for consumers but they don't increase the productivity of drivers: Drivers cannot drive faster or service more customers per hour, really, these are bounded by physical constraints.
- Jweb_Guru 5y ago
  > 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.

mytailorisrich 5y ago

Oh we are measuring productivity correctly. 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? If the answer is "not really", then Rust does not increase productivity (I don't know the answer, btw). In general, I don't think that software as a tool made much difference to people's productivity in the last 20 years or so. The boost enabled by internet connectivity was probably over by ~2005. Since then not much has happened. Uber, Deliveroo, etc. are great for consumers but they don't increase the productivity of drivers: Drivers cannot drive faster or service more customers per hour, really, these are bounded by physical constraints.

Jweb_Guru 5y ago
> 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.