4 ms·

Lumping C and C++ together implies much about the use of the language - "modern" C++ features go out of their way to avoid memory unsafe and bug-prone operation

by kimixa 4y ago

Lumping C and C++ together implies much about the use of the language - "modern" C++ features go out of their way to avoid memory unsafe and bug-prone operations (avoiding raw pointer arithmetic, no manual new/delete memory management etc). Comparing Rust against the overlapping subset of "C" and "C++" is rather disingenuous. It's like writing /everything/ in Rust in an unsafe block and avoiding all the tools that actually make it a more productive language. I'd agree today you totally shouldn't be starting new projects in C-with-classes style C++, and take advantage of all the newer tools available in newer versions instead. Sure, Rust and similar may have even better tools to help the programmer, but talking about raw productivity, especially in shorter projects, learning a new language and all the fumbling and mistakes and anti-patterns that can hurt the result, as well as longer-term maintainability, may be worth consideration. Especially, as even if the core project is brand new code, the library ecosystem it's working in may still be more mature around other languages. It totally makes sense to me relegating C and older-style C++ to systems where it's really the only choice (platforms with older/poor tooling, places where the resulting code requires more massaging than usual like resource-limited embedded situations and the developer is already skilled in this with their current toolchain, other situations that no doubt some people will find etc etc.)

nicoburns 4y ago
How short is your project? I learnt Rust to a productive level in 6 weeks. So I guess if your project lifetime is shorter than ~6 month then sure. The library ecosystem in Rust is less mature (there isn’t a library for absolutely everything), but where a library does exist it tends to be much more robust than the C++ equivalent. A library in Rust will not have UB (however you call it). It won’t throw exceptions. It won’t return null without warning you, etc.
chriswarbo 4y ago
"Modern C++" versus "older-style C++" is a meaningless, hand-wavey distinction: if your toolchain accepts "older-style C++" then you're using a vulnerable language; if your toolchain rejects "older-style C++" (e.g. using lint rules) then you're not programming in C++, you're using a safer language which just-so-happens to be a subset of C++. That doesn't affect how vulnerable the C++ language is.
- kimixa 4y ago
  If you're not using every possible construct in unsafe rust blocks, then you're not using rust - just a safer language that just-so-happens to be a subset of rust. The difference is that "discouragement" is in the compiler itself not external lint tools (though many of those "lint tools" are just optional arguments to the compiler). The big difference is the general community having less of a spread of opinions on what the recommended subset is, not helped by that changing over the age of the language, and not being clear about what the general epoch of the language are to highlight things that may be generally replaces by a better construct. Honestly, I'd say the biggest failing of the C++ updates today are lacking some similar epoch system - where older constructs can actually be deprecated from the language. It would be interesting to see if rust gets exactly the same thing as the community expands, and accumulating language updates affect the generally accepted best practices. It's clear Rust doesn't intend to be completely static, with significant language features being added every version. I wonder if one day we'll look at today's rust in the same way as someone focused on "modern" c++ looks at c++98 C-with-classes style code. Everyone uses a subset of any language, that's what coding styles and common patterns are. A definition of this subset is a really useful thing you can do for any non-trivial project IMHO, for any language.
  - chriswarbo 4y ago
    > If you're not using every possible construct in unsafe rust blocks, then you're not using rust - just a safer language that just-so-happens to be a subset of rust. You seem to have misunderstood my point. Whether or not you (or I) happen to be using this or feature of a language is irrelevant; the question is whether it's valid input to the toolchain. For comparison, the existence of an SQL injection vulnerability in example.com has nothing to do with whether you or I happen to exploit that vulnerability or not. W.r.t. Rust: the mere existence of "safe" and "unsafe" subsets, which (a) can be explicitly permitted or forbidden, and (b) are well-defined and don't differ from person to person, org to org, etc. makes it much more practical to forbid "unsafe" from as much of our code as possible, and to pin-down precisely those locations where it has been used. The same cannot be said for e.g. "modern C++"

by kimixa 4y ago

nicoburns 4y ago

How short is your project? I learnt Rust to a productive level in 6 weeks. So I guess if your project lifetime is shorter than ~6 month then sure. The library ecosystem in Rust is less mature (there isn’t a library for absolutely everything), but where a library does exist it tends to be much more robust than the C++ equivalent. A library in Rust will not have UB (however you call it). It won’t throw exceptions. It won’t return null without warning you, etc.

chriswarbo 4y ago

"Modern C++" versus "older-style C++" is a meaningless, hand-wavey distinction: if your toolchain accepts "older-style C++" then you're using a vulnerable language; if your toolchain rejects "older-style C++" (e.g. using lint rules) then you're not programming in C++, you're using a safer language which just-so-happens to be a subset of C++. That doesn't affect how vulnerable the C++ language is.

kimixa 4y ago
If you're not using every possible construct in unsafe rust blocks, then you're not using rust - just a safer language that just-so-happens to be a subset of rust. The difference is that "discouragement" is in the compiler itself not external lint tools (though many of those "lint tools" are just optional arguments to the compiler). The big difference is the general community having less of a spread of opinions on what the recommended subset is, not helped by that changing over the age of the language, and not being clear about what the general epoch of the language are to highlight things that may be generally replaces by a better construct. Honestly, I'd say the biggest failing of the C++ updates today are lacking some similar epoch system - where older constructs can actually be deprecated from the language. It would be interesting to see if rust gets exactly the same thing as the community expands, and accumulating language updates affect the generally accepted best practices. It's clear Rust doesn't intend to be completely static, with significant language features being added every version. I wonder if one day we'll look at today's rust in the same way as someone focused on "modern" c++ looks at c++98 C-with-classes style code. Everyone uses a subset of any language, that's what coding styles and common patterns are. A definition of this subset is a really useful thing you can do for any non-trivial project IMHO, for any language.
- chriswarbo 4y ago
  > If you're not using every possible construct in unsafe rust blocks, then you're not using rust - just a safer language that just-so-happens to be a subset of rust. You seem to have misunderstood my point. Whether or not you (or I) happen to be using this or feature of a language is irrelevant; the question is whether it's valid input to the toolchain. For comparison, the existence of an SQL injection vulnerability in example.com has nothing to do with whether you or I happen to exploit that vulnerability or not. W.r.t. Rust: the mere existence of "safe" and "unsafe" subsets, which (a) can be explicitly permitted or forbidden, and (b) are well-defined and don't differ from person to person, org to org, etc. makes it much more practical to forbid "unsafe" from as much of our code as possible, and to pin-down precisely those locations where it has been used. The same cannot be said for e.g. "modern C++"