Hacker News Reader

Comment by sim_card_map | Hacker News Reader

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

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.

Reply on news.ycombinator.com