> Making C move out of the scene and moving into safer languages for systems programming. Even though C++ also has its issues, but at least it is way safer than

> Making C move out of the scene and moving into safer languages for systems programming. Even though C++ also has its issues, but at least it is way safer than C. I guess I don't see as being "way" safer than C. I see it as being marginally safer [1], but with an arbitrary and rigid object model. > > The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs. > This is a consequence of C ABI being the OS ABI. Perhaps. But a non-OO interface layer makes a lot of sense anyway (or at least OO agnostic ones). The problem with making your main OS interface be C++ is that now every other language has to contort its object model to match the C++ one. How do you write Go code that interfaces with the C++ OS objects? C++ and Go are remarkably different. Ruby and C++ are different, as is Perl, Obj-C, Python, and Java. Either you have to use barely anything from C++ (really light inheritance, no STL, no RIAA, etc.) or you have to have extremely severe wrappers for every non-C++ language. The former means you give up on a lot of the safety that C++ gives you and the latter means that every language binding is 100% different. Neither of those is a good option. An idiomatic C++ OS interface sounds good on the surface, but I think it's really only a good idea if you want all the user code to be written in C++, too. [1] Everything you can do wrong in C you can also do in C++: Good old "((void(*)())0)();" compiles in both.