[0]https://wiki.osdev.org/User:Sortie/Sortix_Thread_Local_Stora...
http://harmful.cat-v.org/software/c++/linus
I wonder if things have changed in the decade since he penned that.
There are reasons to avoid using C++:
* The main benefit of C++ is that it has a standard library that's somewhat usable. Except you can't use standard libraries anyways in kernel code.
* Templates, particularly as they intersect with name lookup, are difficult semantics both to the compiler and the user. Until a decade ago, using templates meant more or less playing roulette as to which compilers could handle it correctly.
* RTTI and exceptions are broken features. It has more or less been accepted that these features are optional in C++.
* The famous saying goes "there's a safe subset to C++, but no one agrees what that subset is." That's still more or less true today.
The main advantage of C++ is that it gets you RAII (which makes dealing with errors much easier, since you're less liable to have issues like gotofail), and you can use templates to build safer ADTs. These are strong benefits in that it's a lot harder to make mistakes as a developer, but there is a strong tendency in this corner of systems developer to assume that stupid mistakes are a fault of the programmer and not the language, and so such benefits are considered flaws because it means letting in stupid people.
I have to disagree in this case. I think the rationale here is that a working, productive mastery of C suggests a developer of a certain caliber. For many projects you would be right, it would be good to encourage the more junior developers to join the project. But, for the Linux kernel, for the core of one of the most widely-deployed pieces of software on the planet, the foundation of countless systems, many of which are performing critical functions, I, frankly, think it's good to filter the dev team for properly competent devs at every possible juncture. If rejecting C++ keeps the noobs out, that's a good thing.
Possibly, but that's still pretty silly. Like...I am a cautious programmer by nature. I can write C. I understand the language and its semantics at a fairly intuitive level. I am still cognizant that a moment's inattention means that I am going to screw up in ways that I literally can't with a language that has a scope guard (to say nothing of typing that isn't based on how wide the data structure is, that sort of thing). Not using a language more featureful than C--even to the point of literally banning every feature from the language that isn't a nonvirtual dtor--doesn't "keep the noobs out". It does, however, create classes of bugs. If anything, a "noob" is less likely to realize the danger they're in when fearlessly[0] writing code!
Recognition of my own limits is most of why I don't write C, and if I absolutely must interop with C (passing through to Ruby or whatever) I write the thinnest, dumbest layer I can between it and C++. (These days, I'm trying to go towards Rust for these tasks, but I know C++ much better.) C just does not make you the hard man that many C devotees think it does, that's all.
[0] - This is mostly a compliment and only a little tongue-in-cheek. Novices being willing to write code that I have to think about analytically to feel safe when writing it can, in the general case, often work well enough/long enough to get by.
The problem is that in early 1990s, when Linux started, no viable alternatives existed. Pascal required a standard library; Modula-2 did not, but it was late to the scene. C++ was poorly supported, and even more full of hidden traps than C. Ada was theoretically a good choice, but accessible compilers did not exist.
C had widespread use, 20 years of history, many compilers, including a free (GPL'd) GCC, wide platform support. Because the language is so compact and simple, these compilers were mostly reliable, there are no complex features that are tricky to implement.
Hence the choice.
Now we have a much wider choice, we have Rust, we have ATS-lang, we have good-quality C++ compilers, we have various tools to synthesize verified C code from higher-level code, etc. We can hope than in 10-15 years we could see e.g. a viable OS kernel written in Rust.
I don't disagree with you, but I think I can steelman Torvalds' position a little bit:
Low-level development is touchy. If you're not extremely careful, you're going to make errors which no language could possibly prevent, which could very well hard-brick some poor schlub's gear. Selecting for people who know the most "be careful" of all the "be careful" languages means selecting for people who are at least somewhat less likely to make errors like those.
Quite frankly, even if the choice of C were to do *nothing* but keep the C++
programmers out, that in itself would be a huge reason to use C.
It's not that you can't do realtime in C++: it's that you have to fight against lots of C++ developers who want to apply the non-realtime C++ popular idioms.
For example: using interface classes for mocking objects with googletest, the result: virtual methods everywhere..
Some thoughts though, for my os-test project I went and installed every free software Unix-like OS and ran a lot of tests on each of them and got experience with each of them.
I don't really consider MINIX a relevant OS. It doesn't have a 64-bit port. The site doesn't offer HTTPS and only has MD5 checksums, so there clearly isn't an attention to security. Sortix offers HTTPS downloads with SHA256 checksums and is up front about its lack of security (next release will do release signing). The latest MINIX release is from 2014, which is a bad project health sign. My latest release is from 2016 (been a bit busy since I got a full time job, but the next release is still being made if at a slower pace, and nightly builds are available and supported). The stable Minix 3.3.0 was pretty buggy and things got better after I upgraded to the Minix 3.4.0 prerelease. The os-test data revealed a bit of a lack of attention to detail in the UDP stack.
I don't think MINIX is really trying to be a more generally used system. It used to be more of an education system, which lead to Linux. I have no plans to make Sortix widely used either, but I avoid making mistakes that prevent adoption as part of the general good work. I want to make a good OS that I personally like.
I'm happy to be compared to systems like MINIX, Haiku and GNU/Hurd. The ideal reaction to someone mentioning Sortix support should be "Eh, Sortix is cool but who cares? I guess I can do it if trivial". And that's fine, at least they heard of it. I'm a one person project with a small community but I think I'm competing reasonably in this space. I don't really consider Minix that usable. GNU/Hurd is alright but the GNU project is notoriously bad at actually releasing an OS themselves with any sort of technical vision and quality. Haiku is pretty interesting, though it seems to be focusing more on being BeOS than being a general purpose system (it doesn't have a multi user support for instance, which Sortix does have, though with a few security vulnerabilities). They're all different projects with different goals and strengths and I try to make Sortix better whenever I can do it.
I want Sortix to have a really good and inclusive community. I enjoy the coding but I really enjoy putting the whole OS together and building a whole project and community.