8 ms·

Google is one of the biggest C++ shops out there, and also authors and maintains many of the static analysis tools and safety features you mention. If they’re

Google is one of the biggest C++ shops out there, and also authors and maintains many of the static analysis tools and safety features you mention. If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

ghostwriter 4y ago
> If they’re saying that C++ can’t be saved, maybe they’re worth listening to. It might be true, but it also sounds like an appeal to authority. I suspect there also might be voices that are being silenced or aren't given a similar platform to speak up and provide an alternative viewpoint on the matter within the same organisation, because <team budget/political reasons why>. After all, there are greenfield projects that are being started in C++20 and people are enthusiastic about their prospects. I wouldn't just blindly dismiss their reasons in favour of Google ones.
- aswanson 4y ago
  C++ is needlessly complex and puts too much of a cognitive burden on the developer. I just wasted a day of my life traced to an errant semicolon in a legacy cpp base. I've used the language for 20 years. It can't be saved.
  - saagarjha 4y ago
    No offense, but I haven’t heard if people wasting days in semicolons outside of memes and really junior developers. What was the issue?
    - aswanson 4y ago
      In real-time systems with millions of lines of code, no debugging capabilities outside of logs, and user misuse use cases, you'd be surprised what can lurk beneath.
      - j16sdiz 4y ago
        In my experience, a good, auto, code formatter helps alot. You can’t hide a semi colon from code formatter.
        galangalalgol 4y ago
        Are you suggesting a code formatter as a mechanism for static analysis? There are really good tools like coverity, and free ones like cppcheck and clang-tidy that will catch that and so much more. Using c++ without cppcheck and clang-tidy in your cmake and pipeline is like leaving the seat up. It takes so little time, and the benefits to others is great. That said, they won't catch a ton of memory and thread safety issues. You'll need tests with 100% coverage for that. Or you could just write it in rust and the compiler will catch it.
        throw827474737 4y ago
        If it was about a semicolon it even sounds more like running with not all warnings on. C++ is "bad" (shorting a lot) due to its compatibility being able to also compile last centuries code.. but if today on active code bases you are not even running with at least that, why would you ever switch to Rust? And full agree, all what cppcheck does imo should have long gone into the warning suite, and Werror and Wall should be the default..
- MBCook 4y ago
  An appeal to authority is a fallacy because it doesn’t actually mean anything. It’s false credibility. If the authority comes along with a bunch of well researched and documented data from experiences in the real world… that seems worth listening to. It’s no longer an appeal to authority. It’s just looking at evidence.
clnq 4y ago
Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they eliminate those types of mistakes. But languages are tools for a job, and only some tools are applicable where C++ is applicable. We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?" And if a project doesn't need fast and efficient code, then why is it using C or C++ in the first place? Overall, selecting the correct tool for a job is more important than figuring out which tool is better in some abstract way.
- tptacek 4y ago
  Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. This recapitulates an argument at least as old as C89. You can probably find Usenet posts deploying it to argue against the adoption of strncpy, because if people don't know how to use sizeof and strlen, then bad for them.
  - saagarjha 4y ago
    strncpy is bad for other reasons, mind you.
  - clnq 4y ago
    Yes, my argument sounds similar. But it's in support of modernity rather than primitivism. C++ nowadays can be used in a very memory-safe way without much effort. In my professional experience, memory leaks and corruptions are sporadic in modern C++ code and common in old-style pre-C++ 11 code. That's why I'm a bit skeptical of this article from Google. It seems reasonable that Android has quite a lot of pre-C++ 11 code. And the article seems to lump two very different approaches to memory safety in pre and post-C++ 11 style programming.
    - 4y ago
blub 4y ago
They’re not saying that C++ can or can’t be saved. And there’s no “they”, there are hundreds of teams with different expectations and policies. You’re merely reading what you want between the lines.
- raggi 4y ago
  True, but what is said is: We continue to invest in tools to improve the safety of our C/C++. Over the past few releases we’ve introduced the Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE on production Android devices. We’ve also increased our fuzzing coverage on our existing code base. Vulnerabilities found using these tools contributed both to prevention of vulnerabilities in new code as well as vulnerabilities found in old code that are included in the above evaluation. These are important tools, and critically important for our C/C++ code. However, these alone do not account for the large shift in vulnerabilities that we’re seeing, and other projects that have deployed these technologies have not seen a major shift in their vulnerability composition. We believe Android’s ongoing shift from memory-unsafe to memory-safe languages is a major factor.
  - throw827474737 4y ago
    They "believe" the major shift is due to Rust, while they continously improve also their C++ tools, and the count in also all violations (even mabe more theoretical ones?) found by those .. I have no doubts about the actual claim, but especially this quite sounds like they may have made more out of this correlation==causation than there maybe is, I believe ;)
    - UncleMeat 4y ago
      I know some of the people who own the tools described above. I can assure you that if those tools were the primary cause of the reduction in vuln they'd be screaming it from the hilltops. A huge amount of work at Google goes into answering questions like "what actually accounts for this change." This is one of the benefits of the promo culture that is often criticized.
logicchains 4y ago
>If they’re saying that C++ can’t be saved, maybe they’re worth listening to. Google's one of the worst C++ shops because their code standard basically forbids using modern C++, and their C++ is more like 90s Java than modern C++. It's no wonder they want to get away from it.
- Xorlev 4y ago
  I...what? I write C++ at Google, and it encourages use of modern C++ features, and many things you see adopted in std have roots in our libraries. I'm curious what you think Google prevents us from using and why you think our C++ is like 90s Java. https://abseil.io/tips https://abseil.io/tips has a lot of our philosophies and abseil is chunks of our internal libraries published externally.
  - UncleMeat 4y ago
    I've weirdly heard people say this in the past too and I am equally baffled. I think it stems from the fact that Google was slow at making C++11 available internally so there was a period of time where the rest of the world was using smart pointers and we couldn't. That may have just solidified a "Google uses old C++" meme out in the wild despite it being wildly out of date.
kaba0 4y ago
Google’s C++ coding guide is (was?) not really up-to-date, so there is that. Modern C++ is indeed a huge upgrade on what came before and with a good amount of static and dynamic analysis the state of low-level programming is much better now, but there really is no reason for new programs to be written with these. Besides the bottom of the stack, managed languages are more than fast enough for nigh everything.
- rob74 4y ago
  > Besides the bottom of the stack, managed languages are more than fast enough for nigh everything And yet, there is a lot of enthusiasm (at least here on HN) for web development in Rust...
  - UncleMeat 4y ago
    There are plenty of people who want to write in Rust for the fun of it. But I'm not aware of too many people saying that you should avoid writing a web application in java/python/js in favor of rust. Pretty much the only people being told to stop doing what they are doing are the people starting new projects that process untrusted data in C and C++.
    - steveklabnik 4y ago
      You and your parent are saying slightly different things with regards to web dev; they said there's enthusiasm for doing it, not that you shouldn't write web applications in those languages. Someone can think it's fine to write a web application in java/python/js and Rust.
- bitexploder 4y ago
  Never mind you don’t give up any performance to use Rust anyway. They focused heavily on only incorporating features with zero cost abstractions.
humanrebar 4y ago
Google is great at engineering projects that look great in promotion packets. Just because they're big and funded doesn't mean they're good at this. It seems plausible that splashy projects in new languages are better for careers than grinding through "stable" codebases using "boring" engineering practices. I also gather that Google has a challenge, possibly for similar reasons, keeping their third party dependencies updated and up to standards. A lot of those are written in C and C++, probably.
- UncleMeat 4y ago
  //third_party is indeed a challenge, but it is definitely not the case that vulns are only coming from //third_party. I mean, the linked article is about the Android codebase (not attached to //third_party) and the Chrome codebase publishes a ton of vuln data (again, not attached to //third_party).
  - humanrebar 4y ago
    I was saying Google might be pessimistic about C and C++ for some reasons specific to Google culture, like inability to get engineers to care about "boring" work. I wasn't making the point you're addressing.
    - UncleMeat 4y ago
      I assure you that "fix vulns caused by memory safety issues through some means other than a total language shift" is not boring work, but the sort of problem that will happily get people promoted to L8. It is just hard as hell. One of the people most involved in the systems described in the blog post that are used to harden the C++ side of things is a L9 here.
      - humanrebar 4y ago
        I more meant the mid range engineer work to just buckle down, test, and fix things. As in, just owning and cleaning up a lot of important projects, including third party ones. Designing the ultimate everything sanitizer with zero performance overhead would surely be impressive even at Google. Especially if it was actually adopted across the org.

ghostwriter 4y ago

> If they’re saying that C++ can’t be saved, maybe they’re worth listening to. It might be true, but it also sounds like an appeal to authority. I suspect there also might be voices that are being silenced or aren't given a similar platform to speak up and provide an alternative viewpoint on the matter within the same organisation, because <team budget/political reasons why>. After all, there are greenfield projects that are being started in C++20 and people are enthusiastic about their prospects. I wouldn't just blindly dismiss their reasons in favour of Google ones.

aswanson 4y ago
C++ is needlessly complex and puts too much of a cognitive burden on the developer. I just wasted a day of my life traced to an errant semicolon in a legacy cpp base. I've used the language for 20 years. It can't be saved.
- saagarjha 4y ago
  No offense, but I haven’t heard if people wasting days in semicolons outside of memes and really junior developers. What was the issue?
  - aswanson 4y ago
    In real-time systems with millions of lines of code, no debugging capabilities outside of logs, and user misuse use cases, you'd be surprised what can lurk beneath.
    - j16sdiz 4y ago
      In my experience, a good, auto, code formatter helps alot. You can’t hide a semi colon from code formatter.
      - galangalalgol 4y ago
        Are you suggesting a code formatter as a mechanism for static analysis? There are really good tools like coverity, and free ones like cppcheck and clang-tidy that will catch that and so much more. Using c++ without cppcheck and clang-tidy in your cmake and pipeline is like leaving the seat up. It takes so little time, and the benefits to others is great. That said, they won't catch a ton of memory and thread safety issues. You'll need tests with 100% coverage for that. Or you could just write it in rust and the compiler will catch it.
        throw827474737 4y ago
        If it was about a semicolon it even sounds more like running with not all warnings on. C++ is "bad" (shorting a lot) due to its compatibility being able to also compile last centuries code.. but if today on active code bases you are not even running with at least that, why would you ever switch to Rust? And full agree, all what cppcheck does imo should have long gone into the warning suite, and Werror and Wall should be the default..
MBCook 4y ago
An appeal to authority is a fallacy because it doesn’t actually mean anything. It’s false credibility. If the authority comes along with a bunch of well researched and documented data from experiences in the real world… that seems worth listening to. It’s no longer an appeal to authority. It’s just looking at evidence.

clnq 4y ago

Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they eliminate those types of mistakes. But languages are tools for a job, and only some tools are applicable where C++ is applicable. We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?" And if a project doesn't need fast and efficient code, then why is it using C or C++ in the first place? Overall, selecting the correct tool for a job is more important than figuring out which tool is better in some abstract way.

tptacek 4y ago
Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. This recapitulates an argument at least as old as C89. You can probably find Usenet posts deploying it to argue against the adoption of strncpy, because if people don't know how to use sizeof and strlen, then bad for them.
- saagarjha 4y ago
  strncpy is bad for other reasons, mind you.
- clnq 4y ago
  Yes, my argument sounds similar. But it's in support of modernity rather than primitivism. C++ nowadays can be used in a very memory-safe way without much effort. In my professional experience, memory leaks and corruptions are sporadic in modern C++ code and common in old-style pre-C++ 11 code. That's why I'm a bit skeptical of this article from Google. It seems reasonable that Android has quite a lot of pre-C++ 11 code. And the article seems to lump two very different approaches to memory safety in pre and post-C++ 11 style programming.
  - 4y ago

blub 4y ago

They’re not saying that C++ can or can’t be saved. And there’s no “they”, there are hundreds of teams with different expectations and policies. You’re merely reading what you want between the lines.

raggi 4y ago
True, but what is said is: We continue to invest in tools to improve the safety of our C/C++. Over the past few releases we’ve introduced the Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE on production Android devices. We’ve also increased our fuzzing coverage on our existing code base. Vulnerabilities found using these tools contributed both to prevention of vulnerabilities in new code as well as vulnerabilities found in old code that are included in the above evaluation. These are important tools, and critically important for our C/C++ code. However, these alone do not account for the large shift in vulnerabilities that we’re seeing, and other projects that have deployed these technologies have not seen a major shift in their vulnerability composition. We believe Android’s ongoing shift from memory-unsafe to memory-safe languages is a major factor.
- throw827474737 4y ago
  They "believe" the major shift is due to Rust, while they continously improve also their C++ tools, and the count in also all violations (even mabe more theoretical ones?) found by those .. I have no doubts about the actual claim, but especially this quite sounds like they may have made more out of this correlation==causation than there maybe is, I believe ;)
  - UncleMeat 4y ago
    I know some of the people who own the tools described above. I can assure you that if those tools were the primary cause of the reduction in vuln they'd be screaming it from the hilltops. A huge amount of work at Google goes into answering questions like "what actually accounts for this change." This is one of the benefits of the promo culture that is often criticized.

logicchains 4y ago

>If they’re saying that C++ can’t be saved, maybe they’re worth listening to. Google's one of the worst C++ shops because their code standard basically forbids using modern C++, and their C++ is more like 90s Java than modern C++. It's no wonder they want to get away from it.

Xorlev 4y ago
I...what? I write C++ at Google, and it encourages use of modern C++ features, and many things you see adopted in std have roots in our libraries. I'm curious what you think Google prevents us from using and why you think our C++ is like 90s Java. https://abseil.io/tips https://abseil.io/tips has a lot of our philosophies and abseil is chunks of our internal libraries published externally.
- UncleMeat 4y ago
  I've weirdly heard people say this in the past too and I am equally baffled. I think it stems from the fact that Google was slow at making C++11 available internally so there was a period of time where the rest of the world was using smart pointers and we couldn't. That may have just solidified a "Google uses old C++" meme out in the wild despite it being wildly out of date.

kaba0 4y ago

Google’s C++ coding guide is (was?) not really up-to-date, so there is that. Modern C++ is indeed a huge upgrade on what came before and with a good amount of static and dynamic analysis the state of low-level programming is much better now, but there really is no reason for new programs to be written with these. Besides the bottom of the stack, managed languages are more than fast enough for nigh everything.

rob74 4y ago
> Besides the bottom of the stack, managed languages are more than fast enough for nigh everything And yet, there is a lot of enthusiasm (at least here on HN) for web development in Rust...
- UncleMeat 4y ago
  There are plenty of people who want to write in Rust for the fun of it. But I'm not aware of too many people saying that you should avoid writing a web application in java/python/js in favor of rust. Pretty much the only people being told to stop doing what they are doing are the people starting new projects that process untrusted data in C and C++.
  - steveklabnik 4y ago
    You and your parent are saying slightly different things with regards to web dev; they said there's enthusiasm for doing it, not that you shouldn't write web applications in those languages. Someone can think it's fine to write a web application in java/python/js and Rust.
bitexploder 4y ago
Never mind you don’t give up any performance to use Rust anyway. They focused heavily on only incorporating features with zero cost abstractions.

humanrebar 4y ago

Google is great at engineering projects that look great in promotion packets. Just because they're big and funded doesn't mean they're good at this. It seems plausible that splashy projects in new languages are better for careers than grinding through "stable" codebases using "boring" engineering practices. I also gather that Google has a challenge, possibly for similar reasons, keeping their third party dependencies updated and up to standards. A lot of those are written in C and C++, probably.

UncleMeat 4y ago
//third_party is indeed a challenge, but it is definitely not the case that vulns are only coming from //third_party. I mean, the linked article is about the Android codebase (not attached to //third_party) and the Chrome codebase publishes a ton of vuln data (again, not attached to //third_party).
- humanrebar 4y ago
  I was saying Google might be pessimistic about C and C++ for some reasons specific to Google culture, like inability to get engineers to care about "boring" work. I wasn't making the point you're addressing.
  - UncleMeat 4y ago
    I assure you that "fix vulns caused by memory safety issues through some means other than a total language shift" is not boring work, but the sort of problem that will happily get people promoted to L8. It is just hard as hell. One of the people most involved in the systems described in the blog post that are used to harden the C++ side of things is a L9 here.
    - humanrebar 4y ago
      I more meant the mid range engineer work to just buckle down, test, and fix things. As in, just owning and cleaning up a lot of important projects, including third party ones. Designing the ultimate everything sanitizer with zero performance overhead would surely be impressive even at Google. Especially if it was actually adopted across the org.