If you work at a FAANG company you can definitely expect to see C++ and Typescript in the same project.

I work for a FAANG and I haven’t. Unless you would count webrtc and any thing that uses as part of the same project? I can’t imagine other cases, there are underlying native libraries like electron or webrtc, but they wouldn’t count as a same project with client code.

I admit we (non-native devs) still need to edit C++ code sometimes, but we aren’t the primary or even really secondary developers on such code.

A lot of projects at these places have C++ backends because the performance gains matter at their scale. It's also not unusual for developers to be fullstack, even for large projects.

Jack of all trades master of none fullstack devs are rarer the higher up seniority you go. They are much more likely to become people managers given the way influence is wielded at a big company. I can see them at smaller companies, but it sounds like a waste of potential.

In my experience it's the exact opposite. Junior devs can only handle small parts of the stack at once, but more senior people can handle everything. Senior people specialize by gaining domain knowledge.

The senior people can still handle as much as the stack as they could as juniors, but they have deep experience in a few areas where they are considered experts.

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++. ¯ \ _ ( ツ ) _ / ¯

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.

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).

I think fptrs and v-tables are fairly predictable once you know how they work. The main issue is that "good" C++ code makes heavy use of the STL, meaning that you need to know exactly how everything is implemented to understand what code will be generated. In embedded environments there can be strict timing requirements, memory restrictions, etc. That makes C++/Rust a little more scary. You might wanna ban stuff like std::vector because you never know when it will reallocate and double in size. Better to just use dumb arrays so everything is obvious.

You can implement a self expanding vector in C though, so I’m not really sure what you are gaining/losing by using C++, I guess it’s just a matter of standard library, but you can create build rules that restrict what you can depend on in low level code.

The point is that having all these complex libraries and abstractions moves you away from understanding what your code is actually doing, which is not ideal in some domains.

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”