5 ms·

The entire Rust section is premised on the common fallacy that "bad programmers", however defined, are responsible for the safety and security problems of C and

The entire Rust section is premised on the common fallacy that "bad programmers", however defined, are responsible for the safety and security problems of C and C++. The conclusion is that, because "bad programmers" are supposedly incapable of learning Rust anyway, Rust's safety features are pointless. None of that is true. The biggest memory safety flaws that have caused the most damage have been, more often than not, written by the best C and C++ programmers. That's because the best programmers are the ones who write the critical C and C++ code--Chromium, Firefox, WebKit, the Linux kernel, nginx, libpng, libjpeg, libc, etc. "Bad programmers" (whatever that means) can't, and don't, usefully contribute to projects like WebKit to begin with. The problem is with the tool. Though it's an inconvenient fact to accept, humans have shown themselves incapable of writing safe C and C++ code at scale using standard software development practices (i.e. not spending 10x on verification). That C and C++ are due to be replaced shouldn't really be controversial--it's natural to expect that we know how to design languages better now than we did in 1978.

ncmncm 8y ago
Equating C and C++ must seem compelling when one is exposed to C++ as it is written at Mozilla and at Google. Both places enforce coding standards that require programming under what amount to 1990s conventions, with a few modern tricks added. The consequence is that you get few of the benefits of modern C++, but all the costs. Google and Mozilla might never get out from under their burden of enforced bad coding habits. It is a mistake to attribute to a language the flaws of one's corporate culture. C++ is not at all under threat of being replaced. The number of C++ programmers is increasing at a much greater rate than of Rust programmers, and the language is evolving quite rapidly after its stagnation in the '00s. If you learned C++ before you could use C++11, you will be surprised at how much more fun C++ is now. Coding C++20 will be even more fun.
- pcwalton 8y ago
  > Equating C and C++ must seem compelling when one is exposed to C++ as it is written at Mozilla and at Google. Both places enforce coding standards that require programming under what amount to 1990s conventions, with a few modern tricks added. The consequence is that you get few of the benefits of modern C++, but all the costs. That's just not true. Both organizations use "modern C++" everywhere. The new C++ proposals tend to come from large companies such as Google, after all. People tend to assume that every new release of C++ will automatically solve all the problems with the previous releases until proven otherwise. This has always mystified me. Nobody has demonstrated that any new version of C++ has been able to stem the flood of memory safety problems. It's interesting that few people can actually articulate why modern C++ supposedly solves the memory safety issues, other than just mentioning smart pointers. Smart pointers actually do very little--shared_ptr can bump reference counts sometimes and that's about it--and what little benefit comes from smart pointers is generally outweighed by all the new ways to get use-after-free in modern C++. Free happens invisibly in subtle places in modern C++, while in C free happens explicitly when you write "free()", which tends to be safer. In my opinion, modern C++ is significantly less safe than classic C++, which is in turn significantly less safe than C.
  - ncmncm 8y ago
    I am forced to conclude, from your complaints about the C++ code that you are exposed to, that it is very, very far from modern, for what I have to assume to be corporate reasons. I don't know why you carry on about smart pointers. I find I use unique_ptr here and there (shared_ptr, practically never), and never, ever in any interface. Instead, modern C++ code traffics in value types, and relies on destructors, almost always from a library or compiler-generated, for cleanup. Use-after-free never happens because anything freed was only ever referenced from within a value-typed object that no longer exists. The reason that, in modern C++, memory safety issues fade into insignificance is that we have access to libraries that are fully as fast as we could ever code in-line, optimized as only code that is used in many places can afford to be, that encode logic correctly, once, that can be used everywhere without compromise. Rust does not yet have the facilities to capture as much semantics in libraries. Anything Rust can't capture in a library has to be coded in place, with all the opportunities for mistakes that brings. So, Rust is good at safing low-level memory fiddling that we just don't do much of, anymore, in C++. Meanwhile, we avoid myriad errors that come from relying on necessarily leaky abstractions.
    - xiphias2 8y ago
      I was also using unique_ptr at Google (shared_ptr is not encouraged), but the problem with unique_ptr is that it doesn't solve the more complex data ownership cases, and it's totally unusable for multi-threaded data race problems. Rust Rayon is a huge difference from anything available from C++, and it can't be solved in C++ without adding borrow checker to the C++ language (which wouldn't be a bad thing to do in my opinion, it would help modernizing old code bases).
      - ncmncm 8y ago
        When you have complicated ownership cases, you have a fundamental design problem. The Standard Library is not a place to find patches for those. Likewise, multi-threaded race problems.
        8y ago
blub 8y ago
The "bad/good" attribute is not helpful, but if we replace that with "people who obsess about memory safety or not" then the conclusion holds. The security problems of C and C++ programs are caused by the fact that it takes effort to write safe code in those languages and most programmers/companies can live just fine with the safety they can reach with less effort. Bugs are opened, the code is patched and the world goes on. And because those people don't obsess over memory safety, they won't switch to Rust either, unless something else happens to force them to. E.g: great job opportunities, official toolchain in Rust, etc. Maybe C and C++ are due to be replaced, but hopefully not by Rust, because at least back in 78 they could create a language that's at least moderately fun to use.
- pcwalton 8y ago
  > The "bad/good" attribute is not helpful, but if we replace that with "people who obsess about memory safety or not" then the conclusion holds. "People who obsess over memory safety" are in fact not writing in C and C++ these days. > The security problems of C and C++ programs are caused by the fact that it takes effort to write safe code in those languages and most programmers/companies can live just fine with the safety they can reach with less effort. No, this is not true, unless you define "effort" as "10x normal development costs and time", which does not make economic sense for mainstream software.
  - blub 8y ago
    Precisely, they are not. So then why do you expect C and C++ developers to switch to Rust if most of them don't consider memory safety that critical? Selling Rust to C and C++ programmers is like selling bicycles to Eskimos. Regarding your second point: Firefox has vulnerabilities patched in almost every version (although the last one was a certificate screw-up). Are people abandoning Firefox because of that? Are you having trouble attracting talent, because it's written in C++? Are people switching to Chrome en masse because it has better security? Even a project with middling memory safety like Firefox is able to survive just fine in a space where security's aaalways argued about. It's perversely lost market share because of Google's marketing and its poor performance. So one doesn't need to invest 10x development costs and time, probably not even 2x.

ncmncm 8y ago

Equating C and C++ must seem compelling when one is exposed to C++ as it is written at Mozilla and at Google. Both places enforce coding standards that require programming under what amount to 1990s conventions, with a few modern tricks added. The consequence is that you get few of the benefits of modern C++, but all the costs. Google and Mozilla might never get out from under their burden of enforced bad coding habits. It is a mistake to attribute to a language the flaws of one's corporate culture. C++ is not at all under threat of being replaced. The number of C++ programmers is increasing at a much greater rate than of Rust programmers, and the language is evolving quite rapidly after its stagnation in the '00s. If you learned C++ before you could use C++11, you will be surprised at how much more fun C++ is now. Coding C++20 will be even more fun.

pcwalton 8y ago
> Equating C and C++ must seem compelling when one is exposed to C++ as it is written at Mozilla and at Google. Both places enforce coding standards that require programming under what amount to 1990s conventions, with a few modern tricks added. The consequence is that you get few of the benefits of modern C++, but all the costs. That's just not true. Both organizations use "modern C++" everywhere. The new C++ proposals tend to come from large companies such as Google, after all. People tend to assume that every new release of C++ will automatically solve all the problems with the previous releases until proven otherwise. This has always mystified me. Nobody has demonstrated that any new version of C++ has been able to stem the flood of memory safety problems. It's interesting that few people can actually articulate why modern C++ supposedly solves the memory safety issues, other than just mentioning smart pointers. Smart pointers actually do very little--shared_ptr can bump reference counts sometimes and that's about it--and what little benefit comes from smart pointers is generally outweighed by all the new ways to get use-after-free in modern C++. Free happens invisibly in subtle places in modern C++, while in C free happens explicitly when you write "free()", which tends to be safer. In my opinion, modern C++ is significantly less safe than classic C++, which is in turn significantly less safe than C.
- ncmncm 8y ago
  I am forced to conclude, from your complaints about the C++ code that you are exposed to, that it is very, very far from modern, for what I have to assume to be corporate reasons. I don't know why you carry on about smart pointers. I find I use unique_ptr here and there (shared_ptr, practically never), and never, ever in any interface. Instead, modern C++ code traffics in value types, and relies on destructors, almost always from a library or compiler-generated, for cleanup. Use-after-free never happens because anything freed was only ever referenced from within a value-typed object that no longer exists. The reason that, in modern C++, memory safety issues fade into insignificance is that we have access to libraries that are fully as fast as we could ever code in-line, optimized as only code that is used in many places can afford to be, that encode logic correctly, once, that can be used everywhere without compromise. Rust does not yet have the facilities to capture as much semantics in libraries. Anything Rust can't capture in a library has to be coded in place, with all the opportunities for mistakes that brings. So, Rust is good at safing low-level memory fiddling that we just don't do much of, anymore, in C++. Meanwhile, we avoid myriad errors that come from relying on necessarily leaky abstractions.
  - xiphias2 8y ago
    I was also using unique_ptr at Google (shared_ptr is not encouraged), but the problem with unique_ptr is that it doesn't solve the more complex data ownership cases, and it's totally unusable for multi-threaded data race problems. Rust Rayon is a huge difference from anything available from C++, and it can't be solved in C++ without adding borrow checker to the C++ language (which wouldn't be a bad thing to do in my opinion, it would help modernizing old code bases).
    - ncmncm 8y ago
      When you have complicated ownership cases, you have a fundamental design problem. The Standard Library is not a place to find patches for those. Likewise, multi-threaded race problems.
      - 8y ago

blub 8y ago

The "bad/good" attribute is not helpful, but if we replace that with "people who obsess about memory safety or not" then the conclusion holds. The security problems of C and C++ programs are caused by the fact that it takes effort to write safe code in those languages and most programmers/companies can live just fine with the safety they can reach with less effort. Bugs are opened, the code is patched and the world goes on. And because those people don't obsess over memory safety, they won't switch to Rust either, unless something else happens to force them to. E.g: great job opportunities, official toolchain in Rust, etc. Maybe C and C++ are due to be replaced, but hopefully not by Rust, because at least back in 78 they could create a language that's at least moderately fun to use.

pcwalton 8y ago
> The "bad/good" attribute is not helpful, but if we replace that with "people who obsess about memory safety or not" then the conclusion holds. "People who obsess over memory safety" are in fact not writing in C and C++ these days. > The security problems of C and C++ programs are caused by the fact that it takes effort to write safe code in those languages and most programmers/companies can live just fine with the safety they can reach with less effort. No, this is not true, unless you define "effort" as "10x normal development costs and time", which does not make economic sense for mainstream software.
- blub 8y ago
  Precisely, they are not. So then why do you expect C and C++ developers to switch to Rust if most of them don't consider memory safety that critical? Selling Rust to C and C++ programmers is like selling bicycles to Eskimos. Regarding your second point: Firefox has vulnerabilities patched in almost every version (although the last one was a certificate screw-up). Are people abandoning Firefox because of that? Are you having trouble attracting talent, because it's written in C++? Are people switching to Chrome en masse because it has better security? Even a project with middling memory safety like Firefox is able to survive just fine in a space where security's aaalways argued about. It's perversely lost market share because of Google's marketing and its poor performance. So one doesn't need to invest 10x development costs and time, probably not even 2x.