The subtext I'm reading is that Rust is more likely to produce secure code than C++ (which seems reasonable), but the security improvements weren't enough to motivate the language change. The headline is that Rust teams are twice as productive than C++ teams and felt more confident in the correctness of their changes.
https://www.theregister.com/2024/03/31/rust_google_c/
Mastodon Source 🐘
This applies to C++ to Rust rewrites, so it might be attributed to extracting and re-implementing the functionality, the beneficial psychological effects of group learning, and/or the Hawthorne effect. But - this productivity gain is only after a long period of reduced productivity: "That is, in two months about a third of devs feel they're as productive in their new language as their old one. And in about four months, half of developers say as much, based on anonymous internal surveys."
Mastodon Source 🐘
Whether a technology change "increases productivity", which in itself is less important than whether we're "increasing effectiveness", often depends on when and how it's measured. There is a version of this story that proclaims that "Teams that adopt Rust are less productive than C++ teams...After Two Months". This could be enough to thwart the migration in organizations that didn't reach consensus on intermediate checkpoints and directional signals.
Mastodon Source 🐘
Compared to improved security (which often exploits FUD or counterfactuals), promised dev productivity improvements are more likely to receive organizational funding. But those big bets have big risks, so it's critical to make sure in advance we agree how long things might take and the signals we'll use to pivot, proceed, or pause.