For everyone asking: in the talk, Lars mentions that they often rely on self-reported anonymous data. But in this case, Google is large enough that teams have developed similar systems and/or literally re-written things, and so this claim comes from analyzing projects before and after these re-writes, so you’re comparing like teams and like projects.<p>Timestamped: <a href="https://youtu.be/6mZRWFQRvmw?t=27012" rel="nofollow">https://youtu.be/6mZRWFQRvmw?t=27012</a><p>Some additional context on these two specific claims:<p>Google found that porting Go to Rust "it takes about the same sized team about the same time to build it, so that's no loss of productivity" and "we do see some benefits from it, we see reduced memory usage [...] and we also see a decreased defect rate over time"<p>On re-writing C++ into Rust: "in every case, we've seen a decrease by more than 2x in the amount of effort required to both build the services written in Rust, as well as maintain and update those services. [...] C++ is very expensive for us to maintain."
If you ever used Rust I am sure you already are aware of one major reason for the discrepancy, which surprisingly has nothing to do with the language. The tooling around rust is just so much better.<p>CMake, include conflicts, dependency management, etc. either don't exist or are all much less painful in rust. There is just so much annoying stuff that you do not have to deal with when using it.<p>There isn't really much revolutionary that rust the language does. Explicitly having to describe the behavior of memory takes getting used to, but lifts some weight of your shoulders. Other than that it has a somewhat better, and less verbose, syntax than C++. But that really is it.
Full quote: "Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++."<p>From his keynote presentation the RustNation UK conference.