Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++ (opens in new tab)

What would the motivation be for someone so senior to lie on stage about this stuff? Just because he likes a programming language?

This is conspiracy style thinking.

Thankfully, if Lars is lying about this, there's tons of Google folks here on Hacker News. I haven't seen anyone yet make an actual claim with any evidence that he's not telling the truth here.

No, it isn't. Google even has their own build system, because obviously CMake is so bad, but it it is made for insanely large systems not ease of entry for medium/small projects.

C++ slowly is adopting the language features that allow for such integrated tooling, but it isn't there yet. But right now the tooling can't exists simply because of what C++ is. The problems you can't easily solve in C++ are things like "how do I integrate this already existing library into our build chain", that is a legitimately hard question and millions of lines of code have been written trying to solve that problem.

There is no equivalent to cargo for C++, there is build2, there is conan there is vspkg and the VS build system. ALL of them suck and have their own gigantic problems which will raise their head and suddenly you are struggling with include and build problems.

Google hasn't fixed C++, nobody has.

>A platform like Android would have an SDK with all dependencies pre-installed, anything else would be nuts.

Android is usually Java, but you still have to manage dependencies yourself. There is no SDK which includes "all" dependencies, that would be absurd. You are going to create your own dependencies.

For CMake, it is so bad that there are many high effort attempts to replace it, by Google, Microsoft and some others, just to not have to deal with it.

After you've profiled your working code, you can go back and optimize with less copying, more borrowing, and other optimizations where it matters.

Go has the same issue. After it's working, you go back to profile, and those optimization steps can often take longer than original development. (Which is why you profile before optimizing.)

With C++ you must add on time to catch all the memory access bugs and fix them, which is time you don't have to take in Rust and Go due to the borrow checker and garbage collector respectively.

In Go you have to find all the spots where you didn't check the error return code or other unhandled branches, hopefully before deploying to prod. This is time you don't have to take in Rust since it catches these errors during compile.

The advantage of Go is that the typical path is easier, the learning curve is much shallower, and its orders of magnitude faster to compile leading to faster dev feedback loops. On the Rust side, you've got a longer learning curve, and you really have to actively resist the urge to prematurely optimize.

Productivity in Rust is difficult to talk about, because of differences in opinion and what I like to call “the TCO problem.”

Because Rust is hard to learn, a lot of folks assume it’s that hard all the time. Which means they assume things take just as long for a new Rustacean as they do an experienced one. This is generally not the case. Once things click and you’re over that hump, it feels like programming in any other language. If there are similar libraries available and I don’t need to create the world from scratch, I am just as productive in Rust as in other languages that also have those libraries, generally.

But that kinda leads into the other thing I alluded to; a lot of people think of “productivity” as “whatever lets me see something quickly.” But this doesn’t capture real prodctivity, in my mind, which includes the total development time, aka, how many bugs do I have to deal with later. Rust moves a lot (but not all, of course!) of this up front. Which can feel like it slows you down (but again, with experience, I find this is actually kinda minimal), but then you save time on the back end by needing to debug less. This means that robust features end up being developed more quickly than in some other “productive” languages I’ve used in the past.

TL;DR things aren’t simple, and “fast to get going” doesn’t inherently mean “productive.”