Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

twitter.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

#31

Post by [deleted] »

blub wrote: post #24
constantcrying wrote: post #21

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. 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. There isn't really much…

CMake is something you set up once and then mostly add source files which is a one liner. A platform like Android would have an SDK with all dependencies pre-installed, anything else would be nuts. Have no idea what “include conflicts” are supposed to be. The compiler receives a series of paths and searches for files by name.

[deleted]

Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

#33

Post by hardware2win »

steveklabnik wrote: post #19
hardware2win wrote: post #18

Earlier quoted context omitted.

Ok, people with "passion" then

You could just like, say what you mean rather than try and launder the opinion through insinuating things about the people involved. If someone is passionate but that makes them more productive, why would that be a bad thing? At the end of the day, they’re still more productive? Regardless, there’s nothing to indicate that the folks involved are new, or “more passionate” or whatever. They’re Google engineers doing th…

I meant that people who write Rust may be more curious about tech, so they could be better devs

Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

#34

Post by Mawr »

steveklabnik wrote: post #13

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. Timestamped: https://youtu.be/6mZRWFQRvmw?t=27012 Some additional c…

More timestamps:

- Graph on time to become sufficiently productive in Rust to comfortably contribute to a codebase: https://youtu.be/6mZRWFQRvmw?t=27149

- Graph on time to become as productive in Rust as in other languages: https://youtu.be/6mZRWFQRvmw?t=27240

- "Yes, it takes some time, but people do feel like they are as productive in Rust as they were in the language that they previously were writing in." https://youtu.be/6mZRWFQRvmw?t=27274

- Graph on the ease of code review in Rust vs other languages: https://youtu.be/6mZRWFQRvmw?t=27304

- Graph on confidence in Rust code correctness: https://youtu.be/6mZRWFQRvmw?t=27361

- Code example vs C++ #1: https://youtu.be/6mZRWFQRvmw?t=27431

- Code example vs C++ #2: https://youtu.be/6mZRWFQRvmw?t=27656

Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

#35

Post by quuxplusone »

steveklabnik wrote: post #17
quuxplusone wrote: post #16

Earlier quoted context omitted.

For anyone like me who wondered what "TCO" is: In this context "TCO" stands for "time-cost optimization," basically the idea that time is money and so you shouldn't be scared of weighing: - an alternative that costs a small amount of money over a long span of time, against one that costs a large amount of money for just a short span of time - an alternative that costs money (or time) up front, against one that costs…

Ooos sorry! I meant https://en.wikipedia.org/wiki/Total_cost_of_ownership

Ha! I guess at least "time-cost optimization" and "total cost of ownership" aren't too terribly different. :)

But there's an interesting difference in framing or worldview between the two acronyms: My assumption of "time-cost optimization" assumed that such tasks as debugging were part of _producing_ a software artifact. Our implied goal (just like in the Rust talk's title) was to maximize _production_ of such artifacts at a reasonable level of quality. The back-loaded testing and bugfixing work might go on for a while (if you made that tradeoff), but it eventually ends in a "product" (or in project failure).

On the other hand, "total cost of ownership" emphasizes that our primary job isn't production but _ownership_ of software, which is open-ended and goes on forever. We have to think not only about "How long will it take to get it right?" but (mostly!) about "How costly will it be to maintain, year after year, even _after_ we get it right?"

Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

#36

Post by pptr »

constantcrying wrote: post #23
pptr wrote: post #22

Earlier quoted context omitted.

A lot of this tooling is available for C++ development at Google. Includes are added automatically when you use code completion. There is also a simple IDE command to add all the include dependencies to your build file. I don't know how well rust is integrated with Googles internal tooling. The golang integration is incredible, though. You don't need to touch includes or build dependencies at all. They are fully auto…

>A lot of this tooling is available for C++ development at Google. 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++…

All libraries you would need are already in Google's monorepo. There is no need for a package manager.

There are a few external libraries in the monorepo. Maybe it's a trickier task to add those. Most Googlers don't need to do that, though.

Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

#37

Post by steveklabnik »

quuxplusone wrote: post #35
steveklabnik wrote: post #17

Earlier quoted context omitted.

Ooos sorry! I meant https://en.wikipedia.org/wiki/Total_cost_of_ownership

Ha! I guess at least "time-cost optimization" and "total cost of ownership" aren't too terribly different. :) But there's an interesting difference in framing or worldview between the two acronyms: My assumption of "time-cost optimization" assumed that such tasks as debugging were part of _producing_ a software artifact. Our implied goal (just like in the Rust talk's title) was to maximize _production_ of such artifa…

Agreed! I also was like "... that's not what I meant but that does kind of work, when I read your comment." :)

Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

#38

Post by constantcrying »

pptr wrote: post #36
constantcrying wrote: post #23

Earlier quoted context omitted.

>A lot of this tooling is available for C++ development at Google. 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++…

All libraries you would need are already in Google's monorepo. There is no need for a package manager. There are a few external libraries in the monorepo. Maybe it's a trickier task to add those. Most Googlers don't need to do that, though.

Mono repos don't make it so that suddenly you don't have to manage dependencies for a project. They certainly don't fix CMake.

Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

#39

Post by ttfkam »

constantcrying wrote: post #26
blub wrote: post #24

Earlier quoted context omitted.

CMake is something you set up once and then mostly add source files which is a one liner. A platform like Android would have an SDK with all dependencies pre-installed, anything else would be nuts. Have no idea what “include conflicts” are supposed to be. The compiler receives a series of paths and searches for files by name.

You can't be serious. >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, M…

Android APPLICATION development is typically in Kotlin (and of course Java), but Android OS doesn't contain a large percentage of Java. That's C/C++ land and now increasingly Rust.

Re: Google's Lars Bergstrom: Rust teams are twice as productive as teams using C++

#40

Post by ttfkam »

tutfbhuf wrote: post #8
martijnarts wrote: post #2

Full quote: "Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++." From his keynote presentation the RustNation UK conference.

I do not wonder about the double productivity increase compared between Rust and C++. But what really makes me wonder is the comparable productivity of Rust vs. Go. I thought Go is much easier than Rust and that people could write applications much faster in Rust. I would expect that Rust takes at least 2-3 times more time to write an application, compared to Go, but then I would also expect it to run at least 2-3 ti…

If you write Rust where you copy all the time instead of borrow, it can save you enormous amounts of time with arguably minimal performance degradation. This can make up a lot of the perceived time disparity between Go and Rust, and leave C++ in the dust. (Yes, I know C++ can copy as well, but in my experience, it can be very difficult to teach old C++ devs new habits.)

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.

Post reply on HN