You have some strange ideas about why people use C instead of C++ these days. People continue using C not because C++ lacks coroutines or something else (a strange argument for C which has almost no features to speak of), and not because they hate safety. No, people use C dor the sake of portability, for the sake of embedded systems, and for the sake of utter simplicity where that is required. Weaning them off C to C++ is impossible because C++ already doesn't fit their requirements. In fact, Rust is better suited to embedded devices than C++, so there's no real need to proselytize C++ to C programmers. Or to anyone, I would argue, because C++ is a terrible language nearly impossible to write safe software in, as well as an ergonomical, developmental and compilational pain in the ass.

In fact, I believe that in terms of developer time wasted as well user frustration, C++ is the most harmful language in the history of humanity. Someday I'll put together a page listing the dozens of C++'s design daults. Here's just a single article demonstrating how incompatible with simplicity and correctness C++ is: http://www.icu-project.org/docs/papers/cpp_report/the_anatom...

The article is from 1997. Every C++ developer will agree that the area surrounding owning raw pointers is chock-full of footguns, but that area is avoided in modern C++, both in theory and in practice.

It is a fact that people still do graduate from C to C++, for a wide variety of reasons. Some discover that their embedded system can be coded with C++ as easily as C. Some learn that C++ is faster than C. Some just gain more confidence and adopt a new feature that is only in C++.

The large number of remaining C coders, and the ease of switching incrementallty, means that the number switching to C++ is always overwhelmingly larger than the number adopting Rust from all starting points.

We may lament that they do not start writing modern, high-level C++ immediately, but the number of CppCon (and similar) talks hosted on Youtube, and rocketing attendance at, and number of, such events, shows that there is great interest in learning good modern C++.

In my experience, the majority of C that is used is actually by people who think they're working in C++, because they were taught to use manual memory management, raw pointers and other such C-like constructs. Some keywords about classes were thrown in towards the end of "C++ 101" or whatever they learned from, and away they go, writing C with classes like the last 30 something years never happened.

That's still C++, just not modern C++.

Technically, in that the C++ spec allows it, yes, it's C++. However, I find such definitions to be of little practical use, although frequently in the workplace I sit and wait while someone satisfies their need to carefully divide the world up into precise, clear, exacting and useless definitions before we can get on with doing something useful - the industry just seems to attract that; often they don't care about trashing all those lines immediately afterwards, so long as everyone acknowledged the lines. That said, the discussion about how many layers there are in a model of networking and what they're named rendered some people unable to do anything for the rest of the day.

Colloquially and practically, I might suggest that it demonstrates that the programmer may be dangerously thinking in C with little lumps of data as their classes. The programmer is thinking and coding in C, with some classes, that they then feed to a C++ compiler.

People were doing it like that back in the nineties, when what we think of as "modern C++" didn't exist.

AFAIK this very problem is addressed with introduction of move semantic and the goodness, which comes with it, such as unique_ptr instead of raw pointers. With that default move assignment operator does the right thing by default. So C++ langauge development actually improves simplicity and correcness as least for this particular example.

> Someday I'll put together a page listing the dozens of C++'s design daults.

It's pretty old and somewhat outdated by now, but you might enjoy the C++ FQA (Frequently Questioned Answers):

https://yosefk.com/c++fqa/

"Here's just a single article demonstrating how incompatible with simplicity and correctness C++ is"

I don't see where is the problem. Perhaps, you could give an example of the equivalent code in your favorite language?

Almost no one is using Rust in embedded. C++ has a much higher uptake among that crowd.

I'm not sure modern C++ has proven to be safer than C (old C++ most certainly has not). Also, I'm not as sure as you that there is an overwhelming number of people adopting modern C++, given the slow speed at which I've seen at least my company being able to move to C++11 and then C++14.

The reality is that C++ is still an extremely unsafe language, where any slight deviation from strict discipline (discipline that itself has only really been ergonomical since C++14 or so) will lead to memory corruption errors. Even with modern C++ features you can get memory corruption: null references, references to moved objects, no way to signal errors from destructors, and there is still no good way to check whether an operation on ints will overflow. Moreover, the insistence on optimizing around undefined behavior, specific to C and C++ I believe, coupled with large reliance on undefined behavior in the standard, leaves C++ in a very poor position as far as guarantees of safety are concerned.

In general, the responsible thing if we want a more secure world would be to discourage the use of manual memory management as much as possible, whether it be in C, C++ or Fortran. That does include trying to get people to use smart pointers if they absolutely have to use C++, but it should also include getting people to use other languages if at all possible (Java, C# or Go would be the more mature ones for large business).

You're saying that switching to "safe" modern C++ is just something you could do at a whim. Learning how to write safe C++ is a hell of a task to undergo, and still you are at the mercy of your program crashing even though you have taken careful approach to memory management etc.

Modern C++ is just not a safe language to program with. It is very easy to produce errors that result in segmentation faults, and it takes great care to produce code that works properly even with shared_ptrs and unique_ptrs and so on.

But you are correct that adoption of C++ is higher than Rust, and will continue to be so until some mission critical framework or for example game engine starts to support Rust in as a first citizen language.

Until then, we have modern C++, with all it's quirks and difficulties and lost developer time in figuring out where the hell was that dangling pointer or why the heck was an object not freed correctly, or why did the array access or vector access go off by some value.

Not saying C++ isn't good, it is, but a lot of time is wasted figuring with C++ currently when a lot safer alternative could be used. Unfortunately that is not very realistic in many scenarios yet, although I carefully evalulated Rust also for my current project, the requirement of supporting a C++ game engine just outweighs easily the hassle of having to figure out bridges and bindings and such.

Writing safe modern C++ is much easier, and much less work than the old ways. So it is easy to switch, and easy to tell if you are Doing It Right: if it's not clean, safe, and easy, there is a better way.