4 ms·

C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. Over time, and in larger groups of people that always fails. People j

C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. Over time, and in larger groups of people that always fails. People just aren't that disciplined and they get overconfident of their own skills (or level of discipline). Decades of endless memory leaks, buffer overflows, etc. and the related security issues, crash bugs, data corruption, etc. shows that no code base is really immune to this. The best attitude in programmers (regardless of the language) is the awareness that "my code probably contains embarrassing bugs, I just haven't found them yet". Act accordingly. There are of course lots of valid reasons to continue to use C/C++ on projects where it is used and there are a lot such projects. Rewrites are disruptive, time consuming, expensive, and risky. It is true that there are ways in C++ to mitigate some of these issues. Mostly this boils down to using tools, libraries, and avoiding some of the more dark corners of the language and standard library. And if you have a large legacy code base, adopting some of these practices is prudent. However, a lot of this stuff boils down to discipline and skill. You need to know what to use and do, and why. And then you need to be disciplined enough to stick with that. And hope that everybody around you is equally skilled and disciplined. However, for new projects, there usually are valid alternatives. Even performance and memory are not the arguments they used to be. Rust seems to be building a decent reputation for combining compile time safety with performance and robustness; often beating C/C++ implementations of things where Rust is used to provide a drop in replacement. Given that, I can see why major companies are reluctant to take on new C/C++ projects. I don't think there are many (or any) upsides to the well documented downsides.

pornel 1y ago
People innately admire difficult skills, regardless of their usefulness. Acrobatic skateboarding is impressive, even when it would be faster and safer to go in a straight line or use a different mode of transport. To me skill and effort is misplaced and wasted when it's spent on manually checking invariants that a compiler could check better automatically, or implementing clever workarounds for language warts that no longer provide any value. Removal of busywork and pointless obstacles won't make smart programmers dumb and lazy. It allows smart programmers to use their brainpower on bigger more ambitious problems.
- bayindirh 1y ago
  These type comments always remind me that we forget where we come from in terms of computation, every time. It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time. It's easy to publicly shame people who do hard things for a long time in the light of newer tools. However, many people who likes these languages are using them longer than the languages we champion today were mere ideas. I personally like Go in these days for its stupid simplicity, but when I'm going to do something serious, I'll always use C++. You can fight me, but never pry C++ from my cold, dead hands. For note, I don't like C & C++ because they are hard. I like them because they provide a more transparent window the processor, which is a glorified, hardware implemented PDP-11 emulator. Last, we shall not forget that all processors are C VMs, anyway.
  - nxobject 1y ago
    > It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time. I think you're setting the bar a little too high. Rust's borrow-checking semantics draw on much earlier research (for example, Cyclone had a form of region-checking in 2006); and Turbo Pascal was churning through 127-character identifiers on 8088s in 1983, one year before C++ stream I/O was designed. EDIT: changed Cyclone's "2002" to "2006".
  - raverbashing 1y ago
    > we shall not forget that all processors are C VMs This idea is some 10yrs behind. And no, thinking that C is "closer to the processor" today is incorrect It makes you think it is close which in some sense is even worse
    - lelanthran 1y ago
      > This idea is some 10yrs behind. Akshually[1] ... > And no, thinking that C is "closer to the processor" today is incorrect THIS thinking is about 5 years out of date. Sure, this thinking you exhibit gained prominence and got endlessly repeated by every critic of C who once spent a summer doing a C project in undergrad, but it's been more than 5 years that this opinion was essentially nullified by Okay, If C is "not close to the process", what's closer? Assembler? After all if everything else is "Just as close as C, but not closer", then just what kind of spectrum are you measuring on, that has a lower bound which none of the data gets close to? You're repeating something that was fashionable years ago. =========== [1] There's always one. Today, I am that one :-)
squirrellous 1y ago
Even new projects have good reasons to use c++. Maybe the ecosystem is built around it. Maybe competent c++ programmers are easier to find than rust ones. Maybe you need lots of dynamic loading. Maybe you want drop-in interop with C. Maybe you’re just more comfortable with c++. I agree with the discipline aspect. C++ has a lot going against it. But despite everything it will continue to be mainstream for a long time, and by the looks of it not in the way of COBOL but more like C.
lelanthran 1y ago
> C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. You can't sensibly talk about C and C++ as a single language. One is the most simple language there is, most of the rules to which can be held in the head of a single person while reading code. The other is one of the most complex programming languages to ever have existed, in which even world-renowned experts in lose their facility for the language after a short break from it.
- estimator7292 1y ago
  Have you written significant amounts of C or C++? Most people don't write C, nor use the C compiler, even when writing C. You use C++ and the C++ compiler. For (nearly) all intents and purposes, C++ has subsumed and replaced C. Most of the time when someone says something is "written in C" it actually means it's C++ without the +± features. It's still C++ on the C++ compiler. Actual uses of actual C are pretty esoteric and rare in the modern era. Everything else is varying degrees of C++.
  - QuiEgo 1y ago
    Sending out a strong disagree from the embedded systems world. C is king here. (Broad, general, YMMV statement): The general C++ arc for an embedded developer looks like this: 1.) discover exceptions are way too expensive in embedded. So is RTTI. 2.) So you turn them off and get a gimped set of C++ with no STL. 3.) Then you just go back to C.
    - magnushiie 1y ago
      Skype was written without exception handling and RTTI, although using a lot of C++ features. You can write good C++ code without these dependencies. You don't use STL but with cautious use of hand-built classes you go far. Today I wouldn't recommnend Skype built in any language except Rust. But the Skype founders Ahti Heinla, Jaan Tallinn and Priit Kasesalu found exactly the right balance of C and C++ for the time. I also wrote a few lines of code in that dialect of C++ (no exceptions). And it didn't feel much different from modern C++ (exception are really fatal errors) And regarding to embedded, the same codebase was embedded in literally all the ubiquitous TVs of the time, even DECT phones. I bet there are only a few (if any) application codebases of significant size to have been deployed at that scale.
gajjanag 1y ago
> I don't think there are many (or any) upsides to the well documented downsides. C++ template metaprogramming still remains extremely powerful. Projects like CUTLASS, etc could not be written to give best performance in as ergonomic a way in Rust. There is a reason why the ML infra community mostly goes with Python-like DSL's, or template metaprogramming frameworks. Last I checked there are no alternatives at scale for this.

pornel 1y ago

People innately admire difficult skills, regardless of their usefulness. Acrobatic skateboarding is impressive, even when it would be faster and safer to go in a straight line or use a different mode of transport. To me skill and effort is misplaced and wasted when it's spent on manually checking invariants that a compiler could check better automatically, or implementing clever workarounds for language warts that no longer provide any value. Removal of busywork and pointless obstacles won't make smart programmers dumb and lazy. It allows smart programmers to use their brainpower on bigger more ambitious problems.

bayindirh 1y ago
These type comments always remind me that we forget where we come from in terms of computation, every time. It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time. It's easy to publicly shame people who do hard things for a long time in the light of newer tools. However, many people who likes these languages are using them longer than the languages we champion today were mere ideas. I personally like Go in these days for its stupid simplicity, but when I'm going to do something serious, I'll always use C++. You can fight me, but never pry C++ from my cold, dead hands. For note, I don't like C & C++ because they are hard. I like them because they provide a more transparent window the processor, which is a glorified, hardware implemented PDP-11 emulator. Last, we shall not forget that all processors are C VMs, anyway.
- nxobject 1y ago
  > It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time. I think you're setting the bar a little too high. Rust's borrow-checking semantics draw on much earlier research (for example, Cyclone had a form of region-checking in 2006); and Turbo Pascal was churning through 127-character identifiers on 8088s in 1983, one year before C++ stream I/O was designed. EDIT: changed Cyclone's "2002" to "2006".
- raverbashing 1y ago
  > we shall not forget that all processors are C VMs This idea is some 10yrs behind. And no, thinking that C is "closer to the processor" today is incorrect It makes you think it is close which in some sense is even worse
  - lelanthran 1y ago
    > This idea is some 10yrs behind. Akshually[1] ... > And no, thinking that C is "closer to the processor" today is incorrect THIS thinking is about 5 years out of date. Sure, this thinking you exhibit gained prominence and got endlessly repeated by every critic of C who once spent a summer doing a C project in undergrad, but it's been more than 5 years that this opinion was essentially nullified by Okay, If C is "not close to the process", what's closer? Assembler? After all if everything else is "Just as close as C, but not closer", then just what kind of spectrum are you measuring on, that has a lower bound which none of the data gets close to? You're repeating something that was fashionable years ago. =========== [1] There's always one. Today, I am that one :-)

squirrellous 1y ago

Even new projects have good reasons to use c++. Maybe the ecosystem is built around it. Maybe competent c++ programmers are easier to find than rust ones. Maybe you need lots of dynamic loading. Maybe you want drop-in interop with C. Maybe you’re just more comfortable with c++. I agree with the discipline aspect. C++ has a lot going against it. But despite everything it will continue to be mainstream for a long time, and by the looks of it not in the way of COBOL but more like C.

lelanthran 1y ago

> C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. You can't sensibly talk about C and C++ as a single language. One is the most simple language there is, most of the rules to which can be held in the head of a single person while reading code. The other is one of the most complex programming languages to ever have existed, in which even world-renowned experts in lose their facility for the language after a short break from it.

estimator7292 1y ago
Have you written significant amounts of C or C++? Most people don't write C, nor use the C compiler, even when writing C. You use C++ and the C++ compiler. For (nearly) all intents and purposes, C++ has subsumed and replaced C. Most of the time when someone says something is "written in C" it actually means it's C++ without the +± features. It's still C++ on the C++ compiler. Actual uses of actual C are pretty esoteric and rare in the modern era. Everything else is varying degrees of C++.
- QuiEgo 1y ago
  Sending out a strong disagree from the embedded systems world. C is king here. (Broad, general, YMMV statement): The general C++ arc for an embedded developer looks like this: 1.) discover exceptions are way too expensive in embedded. So is RTTI. 2.) So you turn them off and get a gimped set of C++ with no STL. 3.) Then you just go back to C.
  - magnushiie 1y ago
    Skype was written without exception handling and RTTI, although using a lot of C++ features. You can write good C++ code without these dependencies. You don't use STL but with cautious use of hand-built classes you go far. Today I wouldn't recommnend Skype built in any language except Rust. But the Skype founders Ahti Heinla, Jaan Tallinn and Priit Kasesalu found exactly the right balance of C and C++ for the time. I also wrote a few lines of code in that dialect of C++ (no exceptions). And it didn't feel much different from modern C++ (exception are really fatal errors) And regarding to embedded, the same codebase was embedded in literally all the ubiquitous TVs of the time, even DECT phones. I bet there are only a few (if any) application codebases of significant size to have been deployed at that scale.

gajjanag 1y ago

> I don't think there are many (or any) upsides to the well documented downsides. C++ template metaprogramming still remains extremely powerful. Projects like CUTLASS, etc could not be written to give best performance in as ergonomic a way in Rust. There is a reason why the ML infra community mostly goes with Python-like DSL's, or template metaprogramming frameworks. Last I checked there are no alternatives at scale for this.