[Subsentient]

Bleurgh. I have a deep soft spot for C, and I'm known to get twisted pleasure from using obscure language features in new ways to annoy people, but this is a level of abuse that even I can't get behind. If you need namespacing, use C++. As much as I love C, it's terrible for large projects.

[vbezhenar]

Linux kernel is large project and clearly C is sufficient for it, given the fact that migrating to C++ would probably be very easy (not using all C++ features, but just selected ones), yet it did not happen.

I think that C++ is better than C, but C is not that bad, even for large projects.

[dkersten]

> Linux kernel is large project and clearly C is sufficient for it

Sure, and operating systems have been written in assmebly too. The question is whether it would be better than just sufficient if Linux were written in C++, today (ie C++17 or 20, not something old). Switching now probably wouldn't be feasible (even ignoring technical reasons, the kernel developer community is familiar with the C codebase and code standards and bought into it), but if Linux were started today, would it be a better choice?

Maybe the answer is still no and C would still be chosen, but the choice today is very different than it was when Linux was started. Of course, maybe Rust or something would be chosen today instead.

[Bayart]

Cantrill did a talk on which he touches on C, C++ and Rust for systems programming [1].

His tl;dr being that Rust feels very much like a proper systems programming language, and more of a « better C » than C++. I don't entirely know what to make of it, but my instinct is that something like C++ with such an opportunity space for baroque concoctions (leading to an obsession with design patterns) is just playing with fire.

[1] https://www.youtube.com/watch?v=LjFM8vw3pbU

[adtac]

the kernel has to live with the choices it made in the 90s, you don't

[midjji]

Yeah they should have upgraded to some restricted subset of C++ or new restrictive language ages ago. I mostly buy the arguments against having exceptions, perhaps even against polymorphism in general, but the argument against destructors, or atomics... hell no.

[humanrebar]

> ...against polymorphism...

C has polymorphism. Inheritance-based virtual dispatch is just one kind of polymorphism. It's common to wire up polymorphism in C with bespoke data structures using tagged unions it function pointers. Changing an implementation at link time is even a form of polymorphism.

[TeeMassive]

> Changing an implementation at link time is even a form of polymorphism.

I never truly appreciated how polymorphism can take so many different forms!

[midjji]

yes, and that is generally worse

[dathinab]

And the Kernel devs would probably get really annoyed if you try to push this kind of name-spacing.

> C++ would probably be very easy

Not necessary, besides some small? problems due to the C++ allowing "more magic optimizations" then C they would switch to a sub-set of C++, and it might be so you would need to communicate to all contributors that a lot of C++ things are not allowed. And it might be easier to simple not use C++. I mean if it would be that easy the kernel likely would have switched.

[shakna]

> And the Kernel devs would probably get really annoyed if you try to push this kind of name-spacing.

Actually, they use it themselves. [0]

[0] https://lwn.net/SubscriberLink/864521/d704bdcced0c5c60/

[dathinab]

Yes, it's scary.

But it's also not used <to have namespacing> but to <improve on cross-field memory operation>.

[AlotOfReading]

A big issue with introducing C++ into a codebase is that it's incredibly hard to stick to a particular subset or standard. There's always a well-justified argument for the next standard or "just this one additional feature". Eventually you end up with the whole kitchen sink, regardless of where you started.

I've had far more success hard-firewalling C++ into its own box where programmers can use whatever they can get running than trying to limit people to subsets.

[kktkti9]

People will make a mess of a large project regardless of the language.