7 ms·

> and argue that this means it's not worth the hassle of switching to a new language. Defenders of C++ argue that there's no reason to change the language, bec

> and argue that this means it's not worth the hassle of switching to a new language. Defenders of C++ argue that there's no reason to change the language, because new features around safety guarantees are being introduced into every C++ standard starting from C++11 at a remarkable pace, so remarkable that compilers implement them faster than the existing adoption rate. And the adoption rate speaks volumes about existing capacity to port/rewrite big codebases in entirely new stacks. The new stacks also tend to have fewer custom static code quality analyzers from third-party vendors, and they are used a lot in mission-critical C++ codebases.

lolinder 4y ago
> The new stacks also tend to have fewer custom static code quality analyzers from third-party vendors, and they are used a lot in mission-critical C++ codebases. Are these static code quality analyzers detecting code quality problems that Rust and company are also vulnerable to? Or are they mostly looking out for the hundreds of legacy footguns that C++ still officially supports?
- ghostwriter 4y ago
  They focus on quality control and compliance to safety requirements in specific domains and industries, for instance MISRA.
  - estebank 4y ago
    This might be of interest https://github.com/PolySync/misra-rust https://github.com/PolySync/misra-rust
Ar-Curunir 4y ago
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
tulio_ribeiro 4y ago
While new safety features in C++ may be impressive, Google's data shows that memory safety vulnerabilities are still a major issue. Switching to a memory-safe language like Rust can help reduce the risk of vulnerabilities and improve the overall security and reliability of a product. The potential benefits make it a worthwhile investment, even if it requires some effort to migrate from C++. #RustIsTheRealDeal
- humanrebar 4y ago
  How much of the benefit comes from the rewrite itself? A more precise comparison would be rewriting that C or C++ in the same language but with memory safety in mind and see how things turned out. The same question comes up when an existing system is rewritten from language A to language B and big performance gains are seen. The language could be the big cause, but so could the extra engineering effort itself -- updated design, fresh attention to the requirements, etc.
  - lolinder 4y ago
    Google isn't rewriting more now than they were before, they're just discussing the use of C/C++ for new code. Presumably, if rewriting chunks of code were enough in its own right, they would never have had so many critical security flaws.
    - humanrebar 4y ago
      I also agree that it's a presumption. I don't know that I agree with it is all. It seems like more engineering attention and excitement is actually good for project quality, and maybe that's a confounding factor here. More data would help, though all this might never be definitively conclusive.
    - clnq 4y ago
      > if rewriting chunks of code were enough in its own right, they would never have had so many critical security flaws. Reducing defects is one of the main reasons (others being maintainability, readability, better integration, and similar) for refactoring and rewriting code. There's usually not enough time/money to do it, especially for large codebases. I quite like rewriting parts of a codebase to modernize it, and I have often closed tons of bugs in a short time this way. It is definitely effective. But not as cost-effective as deprioritizing bugs into "won't fix" territory, which is what many companies like to do.
UncleMeat 4y ago
And yet, people still store a string_view in a field and then access it past the lifetime of the underlying string. Yes, things have gotten better. Smart pointers are a godsend. Sanitizers are a godsend. Various static analysis tools work pretty well. But even codebases that adopt all of these things religiously still are riddled with security vulns.

lolinder 4y ago

> The new stacks also tend to have fewer custom static code quality analyzers from third-party vendors, and they are used a lot in mission-critical C++ codebases. Are these static code quality analyzers detecting code quality problems that Rust and company are also vulnerable to? Or are they mostly looking out for the hundreds of legacy footguns that C++ still officially supports?

ghostwriter 4y ago
They focus on quality control and compliance to safety requirements in specific domains and industries, for instance MISRA.
- estebank 4y ago
  This might be of interest https://github.com/PolySync/misra-rust https://github.com/PolySync/misra-rust

Ar-Curunir 4y ago

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

tulio_ribeiro 4y ago

While new safety features in C++ may be impressive, Google's data shows that memory safety vulnerabilities are still a major issue. Switching to a memory-safe language like Rust can help reduce the risk of vulnerabilities and improve the overall security and reliability of a product. The potential benefits make it a worthwhile investment, even if it requires some effort to migrate from C++. #RustIsTheRealDeal

humanrebar 4y ago
How much of the benefit comes from the rewrite itself? A more precise comparison would be rewriting that C or C++ in the same language but with memory safety in mind and see how things turned out. The same question comes up when an existing system is rewritten from language A to language B and big performance gains are seen. The language could be the big cause, but so could the extra engineering effort itself -- updated design, fresh attention to the requirements, etc.
- lolinder 4y ago
  Google isn't rewriting more now than they were before, they're just discussing the use of C/C++ for new code. Presumably, if rewriting chunks of code were enough in its own right, they would never have had so many critical security flaws.
  - humanrebar 4y ago
    I also agree that it's a presumption. I don't know that I agree with it is all. It seems like more engineering attention and excitement is actually good for project quality, and maybe that's a confounding factor here. More data would help, though all this might never be definitively conclusive.
  - clnq 4y ago
    > if rewriting chunks of code were enough in its own right, they would never have had so many critical security flaws. Reducing defects is one of the main reasons (others being maintainability, readability, better integration, and similar) for refactoring and rewriting code. There's usually not enough time/money to do it, especially for large codebases. I quite like rewriting parts of a codebase to modernize it, and I have often closed tons of bugs in a short time this way. It is definitely effective. But not as cost-effective as deprioritizing bugs into "won't fix" territory, which is what many companies like to do.

UncleMeat 4y ago

And yet, people still store a string_view in a field and then access it past the lifetime of the underlying string. Yes, things have gotten better. Smart pointers are a godsend. Sanitizers are a godsend. Various static analysis tools work pretty well. But even codebases that adopt all of these things religiously still are riddled with security vulns.