Orthogonality doesn’t obviate the need for metaprogramming though. For example, there are lots of places you might need a linked list structure, where the nodes store different types. You might use templates over intrusive structures to gain some type safety without duplicating code for each contained type.
Sure, but linked lists have solutions already using simple macros [1]. There aren't many sophisticated kernel data structures, mainly tables for indexing and linked lists, all of which have simple expressions as macros. Templates perhaps make this a little easier, but are overkill.
[1] http://www.roman10.net/2011/07/28/linux-kernel-programmingli...
aPerson = list_entry(node, struct Person, list);
Sure they do, unless your type checker is formally verified. Are you suggesting there exists a formally verified C++ compiler?
> Running the compiler is also a lot cheaper than having someone inspect every line of code carefully.
Except that's not what I suggested. You only need to audit lines that perform potentially undefined behaviour. The C type checker ensures the rest are fine. I think it's clear this problem is worse in C++ given all of the additional abstractions that interact in surprising ways.
Furthermore, C++ has no formal verification tools, so if you wanted real guarantees, you'd use something like Frama-C or a theorem prover like they did with seL4. Microkernels in C++ have been tried, and in every case they switched back to C for very good reasons.
If I care so much about system correctness that I do the insane amount of work that is formal verification (just look at how many man years sel4 consumed!), I don't write C or C++ at all, I use Spark. There is a reason why you can count the number of formally verified kernels on the fingers of one hand, and it's not because everybody tries to use C++ instead of C.
Nope, but your unqualified statement was simply false, and in any case, your point isn't really relevant. This single line of code we're discussing is easily verifiable by manual inspection and automated testing. We're not talking about huge swaths of code here, we're talking about a few unsafe primitives, because this kind of reuse isn't typical of a microkernel.
The type safety of a single operation expressed as a template is relatively insignificant compared to the added complexity of C++, particularly considering the "reuse" benefits are non-existent for microkernels, and if all you're left with is some elusive "type safety" for a linked list, that's simply not enough.
This is obvious when you know the history of multiple C++ kernel verification efforts, all of which failed, no matter how simple of a C++ subset was chosen. Many C verification efforts have succeeded, and tools for lightweight formal methods, like Frama-C, make the transition to verification possible with C. C++ is a dead end for this purpose, and the various L4 groups that created L4 kernels in C++ and then rewrote them in C all agree.
I haven't worked with Go personally, but "no generics" is probably the most commonly vocal complaint I hear about it, so clearly some people do care.
Multiply that by 10 if you have several junior team members who have been told, and read, that concurrency and parallelism is easy in go.
Advanced users might want to use advanced data structures that are not built-in in the langage, and templates can be convenient to do that.
Not my observation at all.