Hacker News Reader

Comment by d2kx | Hacker News Reader

They are actually using lots of Rust within Fuchsia/Magenta now and have been for months.

I poked around and didn't see any Rust code, and the github stats say

    C 49.0%	 C++ 45.4%	 Makefile 2.9%	 Assembly 1.1%	 Shell 0.8%	 Objective-C 0.4%

https://github.com/fuchsia-mirror/magenta

oh jeez, a kernel in C++...

The only thing I dislike about Linux is that it drags gcc with it, for this you need g++ too.

I don't know anything about kernel dev: why would C++ be a bad choice?

I'm not an expert, but I think it's because c++ is _heavy_. Start using a few features like genetics and suddenly your binary and compile times grow substantially. You only need to look at chrome to see this happening.

Microsoft and Apple develop their respective kernels in C++, and AFAIK, developers are limited to a very restrictive subset of C++, classes are forbidden, so are exceptions, so are new/delete. I think, templates are forbidden, too, but I am not certain.

Once you shrink C++ down to such a subset, it is substantially less heavy. I do not think I am qualified whether that makes it a better choice, but means there are examples of fairly successful operating systems whose kernels are written in C++.

Once you've striped all those features from C++, what's left to differentiate it from C?

I've only used C++ in an academic setting.

NB that I have only a little experience with C++ and none whatsoever with kernel and/or OS development.

> Once you've striped all those features from C++, what's left to differentiate it from C?

Not much, I suspect. You can declare variables anywhere instead of just the beginning of a block, you can use references, and C++ handles const-ness much better than C. Function and operator overloading is a double-edged sword, but it is possible to use them in a way that makes code easier to write, read, and maintain. C++ being C++, there are surely a bunch of things I miss.

But yes, without all the advanced features the gap between C and C++ shrinks significantly,

Its not really a bad choice, but writing really good c++ is hard (sightly less with the newer versions, but still). You can use the same performance tricks that a C dev will use to make your code faster, plus a whole lot of new tricks, some doing exactly the same thing (but not the same way). This is not a problem if your team is used to work together and have a common codebase they already wrote together, for for OS project (like linux), its a bad idea. And in my opinion, writing optimized c++ code is waaaay harder than writing optimized C code (almost each time i had to optimize c++ code, it ended looking like c with classes and weird pointers)(Disclaimer: i'm bad with OOP, it might be just me).

Anyway, Google is supposed to have good c++ devs, with experience coding together, so this is not a problem for them, i think. Another issue is that the compilation is slow compared to C, but i don't think its an issue for Google either.

[edit] Yes, binary size can be a problem too, forgot about that. But if you only use basic libraries, i don't think your binary will grow that much, right?

Reply on news.ycombinator.com