Live data from Hacker News

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

twitter.com

21–30 of 41 posts

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

#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 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.

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

#22

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…

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 automated.

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

#23
post #22

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…

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++ 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.

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

#24

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.

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

#25

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…

Do you think “Lars”, as chair of the Rust Foundation board of directors and previous Servo project member could have a conflict of interest here?

Something that should be mentioned as a disclaimer when quoting his opinion on Rust vs. other languages and that would significantly water down the strength of their claims.

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

#26
post #24

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.

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, Microsoft and some others, just to not have to deal with it.

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

#27

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…

It's bad because people that write C++ for a living got all the joy and happiness sucked out of them and since Rust is in a similar playing field regarding performance, they can't say that they need to use C++ for performance reasons and therefore would admit that all the pain and suffering would be for nothing if they let one good word regarding Rust stay uncontested on the Internet.

I don't even like Rust that much but it's like Stockholm Syndrome is a requirement to have a positive opinion regarding C++.

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

#28
post #25

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…

Do you think “Lars”, as chair of the Rust Foundation board of directors and previous Servo project member could have a conflict of interest here? Something that should be mentioned as a disclaimer when quoting his opinion on Rust vs. other languages and that would significantly water down the strength of their claims.

Could? Sure, in an abstract sense.

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.

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

#29
post #24

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.

I think this is an incredibly kind take for CMake... what about projects that automatically generate bindings (like swig), or attempt to find system-installed header files (like CUDA)? Look at, for example, pytorch (huge amounts of autogenerated code via ATen, at least a few years ago). In my experience C++ projects rarely live in a vacuum and projects build up cruft very easily.
Post reply on HN