Though it is fun to rag on C++ every now and again, I believe Google's C++ style guide is a subset of features (classes, no exceptions, subset of boost,..).

Most C++ issues come from using every feature under the sun and accumulating loads of technical debt instead of picking one tool and sticking with it.

> Though it is fun to rag on C++ every now and again, I believe Google's C++ style guide is a subset of features (classes, no exceptions, subset of boost,..).

Which is the same thing Genode does[1], and it has served them well. Maybe a different language like ADA/SPARK or something else would have been better, but C++ was what they're familiar with, so they made it work. Although I like Rust, it's a bad argument here. Rust has been changing a lot and is still changing, and Fuchsia wasn't started yesterday. And with C++, you could even replace critical parts with formally verified LEAN[1], which has C++ code generation and should be even safer than Rust.

[0] https://genodians.org/nfeske/2019-01-22-conscious-c++

[1] https://leanprover.github.io/

Don’t forget that Fuchsia also has a lot of Rust in it already. These things don’t have to be either/or.

C++i is excellent when you have a large code base. But if you have a large code base for a driver or a stack, you have already lost.

Super sane choice, C has had its time, Rust is an improvement over C++, but lacks higher kinded types and other niceties that are easy to implement in C++. C++ is also used in a large number of projects that fuchsia needs to interface with, such as skia, the graphics stack and so on. This is one of fuchsias competitive advantages. Moreover FIDL (fuchsia interface description language) allows for components to be implemented in a number of other languages.

Do you care to elaborate?

I see no issue in using a fair subset of C++ features in privileged mode.

I think most opponents of C++ for OS kernel development take their position because the simplicity of C results allows for pretty straightforward and direct reasoning about the static (asm, obj layout) and dynamic properties (memory allocations, procedure invocation, etc) of their code.

Both C++ and our tooling has come a long way — not to mention a change in the nature of the challenges of kernel development/performance. I think most of the old arguments against C++ have lost their edge.

Just like Symbian, BeOS, newer parts of IBM mainframes, macOS/iOS drivers, Android drivers post Treble, Windows since Vista, Genode, Arduino,...

C can stay with classical UNIX.

You could sanely use namespacing and other simple mostly lexical / mangling features that help manage the codebase while adding negligible complexity.

They seem to see it the other way around. Most things are "hermetic C++" that export only a C interface. Which is to say they tame C++'s complexity not only by using a very restricted subset, but also by not letting ~any C++ stuff cross API boundaries.

Please don't respond to a bad comment with a worse one. That helps nothing. And especially please don't cross into personal attack, or introduce extraneous flamebait.

https://news.ycombinator.com/newsguidelines.html

It’s also possible that he formed his opinion based on the context of 20 years ago which has since changed into the reality we have today...

Discourses become much nicer when we don’t make/take such explicitly negative angles which are rife with hostile undertones.

"Kernel written in C++... The horror."

What kind of discourse is that leading to? It's just an unqualified, unsubstantiated attack on serious work undertaken by presumably top quality engineers.

In fairness though, it's kinda the stance taken by top quality engineers themselves when faced with the prospect of writing a kernel in C++.

The Google C++ style guide is pretty rigid, and is pretty upfront about the fact that the rigidity is in the interest of not allowing Google C++ projects to devolve into the mess that consumes most large C++ projects.[0]

Linus Torvalds has in the past said some pretty unkind things about the idea of doing kernel development in C++.[1]

Finally, Fuchsia's kernel Zircon is a microkernel. The engineers involved have elected not to attempt to write a monolithic kernel in C++ probably in part for the reasons that Torvalds described. Things like filesystems, drivers, and the networking stack are outside of the Zircon kernel in the Garnet layer and are implemented in languages like Rust (filesystems, drivers) and Go (the networking stack).

[0]https://google.github.io/styleguide/cppguide.html [1]http://harmful.cat-v.org/software/c++/linus

Plenty of top quality engineers write kernel code in C++ every day.

His baby would be nowhere without the contribution of the likes of IBM, Compaq, Oracle and many other nameless contributors.

Linus opinion is his opinion, that is all.

@pjmlp I am going to hijack this and ask you somewhat off topic question:

Most of the OS books teach in a very Unix centered way. Can you recommend some books or resources which describe non-C non-Unixy Operating Systems? I really liked the Blue Book of Smalltalk, and looking for more!

Sure.

- MacOS (pre-OS X)

"Revolution in the Valley"

https://www.amazon.com/Revolution-Valley-Insanely-Great-Stor...

http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...

- NeXTSTEP / Mac OS X

Debatable about non-C non-Unixy part, but it surely isn't the focus of the whole stack.

"Mac OS X Internals: A Systems Approach"

https://www.amazon.com/Mac-OS-Internals-Approach-paperback/d...

http://www.nextop.de/NeXTstep_3.3_Developer_Documentation/

- Oberon and its derivatives (1992 and 2013 versions, System 3, Insight ETHOS and A2)

https://inf.ethz.ch/personal/wirth/

https://inf.ethz.ch/personal/wirth/ProjectOberon/index.html

http://www.projectoberon.com/

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.472...

http://www.ocp.inf.ethz.ch/wiki/Documentation/Front

https://www.research-collection.ethz.ch/handle/20.500.11850/...

- Symbian

"Symbian OS Internals: Real-time Kernel Programming"

https://www.amazon.com/Symbian-OS-Internals-Real-time-Progra...

"Symbian OS Platform Security: Software Development Using the Symbian OS Security Architecture"

https://www.amazon.com/Symbian-Platform-Security-Development...

"The Symbian OS Architecture Sourcebook: Design and Evolution of a Mobile Phone OS"

https://www.amazon.com/Symbian-OS-Architecture-Sourcebook-Ev...

- Mesa and Mesa/Cedar

http://www.digibarn.com/friends/curbow/star/XDEPaper.pdf

http://worrydream.com/refs/Teitelman%20-%20The%20Cedar%20Pro...

- JX

http://www4.cs.fau.de/Projects/JX/

- SPIN OS

http://www-spin.cs.washington.edu/external/overview.html

- Singularity,

https://www.microsoft.com/en-us/research/project/singularity...

https://channel9.msdn.com/Shows/Going+Deep/Singularity-A-res...

https://channel9.msdn.com/Shows/Going+Deep/Singularity-Revis...

- Barrelfish

https://www.microsoft.com/en-us/research/project/barrelfish/...

- Midori,

http://joeduffyblog.com/2015/11/03/blogging-about-midori/

https://www.infoq.com/presentations/csharp-systems-programmi...

"RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing"

https://www.youtube.com/watch?v=EVm938gMWl0

"While never reaching commercial release, at one time Midori powered all of Microsoft’s natural language search service for the West Coast and Asia."

Source: https://www.microsoft.com/en-us/research/project/singularity...

- Helios

https://www.microsoft.com/en-us/research/wp-content/uploads/...

- Muen

https://muen.codelabs.ch/

- GenodeOS

https://genode.org/documentation/index

- Inferno

http://www.vitanuova.com/inferno/docs.html

- Minix 3

https://wiki.minix3.org/doku.php?id=www:documentation:start

- BeOS

"Be Developer's Guide"

https://www.amazon.com/Be-Developers-Guide-Development-Team/...

"Be Advanced Topics"

https://www.amazon.com/Be-Advanced-Topics-Development-Team/d...

- Windows

https://www.amazon.de/Windows-Internals-Part-Pavel-Yosifovic...

https://www.amazon.de/Windows-Internals-Part-Mark-Russinovic...

https://channel9.msdn.com/Shows/Going+Deep/Rob-Short-and-ker...

https://channel9.msdn.com/Shows/Going+Deep/Doron-Holan-Kerne...

https://channel9.msdn.com/Events/Build/2012/3-005

Not everything by a long shot, plenty more to re-discover like VMS,IBM i and Z, Unisys ClearPath, mbed,...

Just keep an open mind and don't idolatrize UNIX, yes it has a couple of good ideas, but they don't make it the be all end all of OS design.

Thank you so much!!

Or got his opinion on C++ in kernels from Linux.

http://harmful.cat-v.org/software/c++/linus

Linux developers, or rather its BDFL are hardly the best place to go to, when looking for sane, balanced opinions.

Considering all C programs are valid C++ programs (albeit some requiring minor alterations), it is possible to find a subset of C++ that is less painful to write than C, while also being as easy to grasp, simple, and maintainable, as C code. Google has an internal style guide that attempts to accomplish that, which I didn't agree with much, but oh well.

Just like Apple has done on IO Kit and now Driver Kit, just to cite one example.

At least since C99 it is no longer true that all C programs are valid C++ programs. C isn't a subset of C++.