I cannot consistently write safe C/C++ code

C++ is certainly a different language now, but you can write code that compiles as either C or C++ with a little care. Everything I write compiles as C or C++ (yes I cast all the void allocations and choose to ignore the C warnings that this is verboten).

It's true but I'd argue that they're not really "coding" in C or C++ in the way it's commonly accepted in those critical environments. It's more like a "fill the blanks" exercise where everything is split in tiny functions that are thoroughly specified and tested.

Effectively 90% of the dev work is done higher level by the various specification and constraint tools. All that's left to the C coder is the most menial of tasks, "dumbly" implementing the algorithm exactly as spelled out in the spec. And even then every piece of code will be checked multiple times before being validated. There's simply not enough leeway for the coder to make a significant mistake, or at least that's how it's supposed to be.

Clearly generalizing this approach to all of software development seems impractical. It's extremely costly and makes it hard to make quick changes to the codebase. For non-critical applications it's probably overkill. There's room for a compromise I think.

The problem with C IMO is that on its own it's highly and uselessly unsafe. At the time of its conception it was probably impractical to write a compiler that would check things like lifetimes statically because it would've made compile times unbearably long but nowadays it's not really a problem anymore.

Do you really encourage people to write critical code in a language where the compiler gladly compiles codes like this, without even a warning (tested with -Wall -Wextra on gcc 6.4)?

    int test(void) {
      int i[3] = {0};

      return i[8];
    }

And the following code only with a non-critical warning:

    int *test(void) {
      int i;

      return &i;
    }

Isn't the entire hacker mantra to have the computer work for you? I'd prefer if my compiler was actively trying to detect my mistakes instead of dumbly spewing machine code.

The author worked on Firefox, a largely C++ codebase, so he was writing C++.

I assume he feels that the problems he talks of are common to both languages, if different in magnitude.

There is a big difference between modern C++ (C++11 ff.) and even the most current iteration of C. The two languages might have been quite similar back in the day when "C with classes" was created, but they have diverged significantly since then. Therefore, I think it is wrong to consider C a "proper subset" of C++, as often is claimed, or even to treat them as equals.

In other words, the real fallacy of the original post is throwing C and C++ into one pot, as if it were all the same - something I consider could not be further from the truth, even back in the C++98 days. A part of that problem is that persons having a (possibly incomplete) understanding of only one of the two languages (on top) believe they can apply that understanding to the other language, too, without having to learn the correct idiomatic usage of the other [1]. And that situation is made even worse by posts that claim to only have to point out some "gotchas" you need to be aware of to understand the other language, particularly coding in C after picking up some C++. Just to name the most critical changes in C++ over C: RAII, abstractions (objects/polymorphism/templates/generics), I/O, error handling, and namespaces/encapsulation. However, not even keywords work the same (fe., `const` and `typedef`). Finally, when C code breaks, it typically is closely related to one of those features that would have tooling in C++ to avoid the issue (in particular, containers to avoid resource leakages in connection with more advanced error and I/O handling techniques).

In other words, I pretty much agree with the GP about the hyperbole of the linked blog entry, and would only let the original post "stand" if it had some kind of significant `C != C++` distinction. I can agree with anyone who thinks that coding in C is probably a Bad Idea today unless you must due to maintaining legacy code-bases, while I think that C++11 has greatly changed the issues you have to look after when coding in C++, making it a lot more safer - and IMO quite fun - to use.

[1] https://olvemaudal.com/2011/10/10/deep-c/ (note that all C++ issues in the post can be avoided by using proper modern C++, like "naked" `new` usages and such)

[minors edits after the post for spelling corrections and readability - but no semantic changes]

>> Spend the next 5 years learning the ins and outs of C++, [..,] Spend a single month learning Rust. Play with it for another month or even two just to be sure. Hopefully after the 3rd month, they'll be 100% certain that their code won't break [...] Rust gives me the confidence to "compile once, run safe everywhere".

See, this is exactly the fallacy that I am criticizing. I think the belief that "C++ is too hard to learn but one could become a good systems programmer in rust in a few months" is - frankly - misguided. I think that in order to become a good systems programmer in rust, you _will_ have to know all of your systems basics (i.e. you should already be able to code in C for starters) and then some more. But sadly this seems to be the spin that their marketing is pushing also.

Personally, I found practical rust (that interfaces with actual system libraries - think openssl) to be more or less on par with good C++11 with RAII memory and ressource management in terms of practical memory safety. Having somebody writing rust code without a basic understanding of things like ressource management and threading is just as bad as having them writing "unsafe" C(++) code.

I hope I'm not feeding the trolls here.