[sdmike1]

As someone who specializes in the type of low level systems that are still built in C, C++ is considered high risk let alone rust. That is largely the reality of the industry. Some co-workers and I hope to introduce C++ as an experimental project next year. We also have some data processing code written in C++ that we would like to integrate as is. The reality on the ground is that C is often used over C++. ¯ \ _ ( ツ ) _ / ¯

[EasyMark]

How about the subset of simple classes, RAII, basic containers(vector, map, duque), single inheritance, overloads for type safety/less casting, stronger casting features, references. Things that c programmers can pick up quickly and use in both c-style and c++ style? That’s what we do and it works out well our embedded. There are a host of embedded STL libraries to let you do hard limits and checks on containers to prevent “hidden” dynamic memory allocation and the like. Of course you’ll have to depend more on the quality of your compiler’s reputation for the processor, c++ is much much more complicated compiler than c and more apt to have bugs. But we’ve yet to encounter anything that forced us to say “f this generated incorrect assembly because of a compiler bug”

[zeroCalories]

Depending on your field, I can definitely understand the hesitation. It's fairly easy to imagine what kind of machine code will be generated from C, but much harder with C++/Rust.

[seanmcdirmid]

Is there game for a Rust like native language over a close to assembly procedural language like C? It seems the only thing that makes predictions hard are things like fptrs and their structured v-table organization (which you can roll your own in C if you want, which almost any large project will).