Yeah I've grown to appreciate C++ in many ways, but what I noticed at my last job is that the baroque interfaces give it a viral effect.
Once you have a little C++ code, the easiest thing to do is to continue writing more C++ code, even if it's not the best tool for that job. It's too hard to use a C++ interface from any other language. Even wrapping it in C is annoying, although as I understand LLVM does exactly that for some of its API.
IMO there are a lot of systems where C++ is the best language for about 10% of the code. C++ really is unique in terms of offering zero-cost abstraction. But then the remaining 90% gets written in C++ too. It can be remarkably awkward for many problems, and your build times scale nonlinearly too.
In some way this is inherent ... the compiler's job is to erase all those abstractions and generate straightforward machine code. In other ways it is the fault/result of adhering to the C linking model, which ironically was for interoperability.
C++ is sort of like a universal receiver and not a universal donor. It can assimilate any C code, and thus it gets code in other languages transitively. But other languages can't assimilate it, at least not without great effort.
That said, Clang has a better API than GCC-XML, so the problem might be solved. Athoough honestly C++ just keeps growing more features with C++ 11, 14, 17 that make it harder to interoperate with any other code. It's this huge compile-time language completely separate from the C linking model.
> It's too hard to use a C++ interface from any other language.
D has the best support for this. It's not as simple as `#include <cppheader.hpp>` but it's better than any other language at it. Name mangling matches, C++ exception support and C++ abstract classes can be declared as D interfaces and everything works.
> C++ really is unique in terms of offering zero-cost abstraction
As far as zero cost, my understanding is that D is still trying to get rid of GC from the standard library.
And I'm explaining why I think Rust is having a hard time getting adoption. It makes an effort to be compatible with C, but not with C++. But really C++ is its "competitor", not C.
And C++ has the network / lock-in effect I described. All languages have a network effect to some degree (libraries, documentation), but I think the situation with C++ is especially acute.
Also, I would say that safety and zero-cost abstractions are the goal of Rust. Those two goals conflict somewhat -- e.g. in the decision over bounds checking. Although I guess you can say that without bounds checking you have no abstraction; you just have a pile of buggy code at zero cost :)
I quite like using Erlang/OTP to host C++ nifs. I feel like it strikes that 10% of code being in C++ balance that you mentioned. I heard it's a popular combo for HFT applications.
> C++ is sort of like a universal receiver and not a universal donor. It can assimilate any C code...
This is part of the language's design.
Bjarne's goal after being forced to use BCPL instead of Simula was never to use a bare bones language ever again, and C with Classes needed to fit into AT&T's C tooling.
Hence why we also didn't got modules back then and a funky name mangling to fit into those bare UNIX linkers.
As for being an universal donor, the story is a bit different in OSes where the ABI is not C based, e.g. BeOS, Symbian, Genode, Windows (COM, .NET, UWP), OS/400 (TIMI), z/OS (ILC).
Yeah I read "The Design and Evolution of C++" and quite liked it. His goal was definitely to assimilate C code, with compatibility being a high priority.
But I'm not sure the goal was to make C++ hard to use from other languages. I think that just fell out of the focus on zero-cost abstractions.
COM seems like the right middle ground between baroque C++ interfaces and RPC/message passing. You write native code, but it can interoperate dynamically with components in other languages, in the same address space. But I think it is overly tied to OOP, and that doesn't play well with the style of Unix.
I wonder if it would be possible to do better, or if that ship has sailed. I'm not overly familiar with Windows... I know there were some problems with COM but it seemed basically sound. I used JScript once and it was pretty powerful.
COM works remarkably well (and a ton of system APIs simply doesn't exist as a C API). It probably only gets bashed because some people conflate it with DCOM and it's security issues.
Well UWP is basically the COM+ Runtime reborn, picking up the ideas that they were discussing back when Ext-VOS was being planned, which eventually became .NET instead.
OS/2 SOM was better in that it supported implementation inheritance and meta-classes.
Apple also had some nice ideas for Copland and how to further develop Taligent, but there is little documentation left of that effort.
Once you have a little C++ code, the easiest thing to do is to continue writing more C++ code, even if it's not the best tool for that job. It's too hard to use a C++ interface from any other language. Even wrapping it in C is annoying, although as I understand LLVM does exactly that for some of its API.
IMO there are a lot of systems where C++ is the best language for about 10% of the code. C++ really is unique in terms of offering zero-cost abstraction. But then the remaining 90% gets written in C++ too. It can be remarkably awkward for many problems, and your build times scale nonlinearly too.
In some way this is inherent ... the compiler's job is to erase all those abstractions and generate straightforward machine code. In other ways it is the fault/result of adhering to the C linking model, which ironically was for interoperability.
C++ is sort of like a universal receiver and not a universal donor. It can assimilate any C code, and thus it gets code in other languages transitively. But other languages can't assimilate it, at least not without great effort.
That said, Clang has a better API than GCC-XML, so the problem might be solved. Athoough honestly C++ just keeps growing more features with C++ 11, 14, 17 that make it harder to interoperate with any other code. It's this huge compile-time language completely separate from the C linking model.