Hacker News Reader

Comment by javajosh | Hacker News Reader

Anyone know why they are building in C as opposed to a newer language like Rust or Go? I mean, if you're going to start from scratch, might as well go all the way, right?

View on HN

C is still the king in performance I believe. Linux still has assembly code apart from C for those crucial performant sections.

Remember if you are talking at the HW-level you don't have the luxury of libraries and I doubt Go/Rust would be of any help unless you build the ecosystem for it. Something like the implementation of coreutil binaries can benefit from Go/Rust but not the OS-code itself.

If Rust is significantly slower than C, it's a bug.

Yeah, just one that will take a decade of compiler optimizations to solve. C and C++ didn't become what they are today overnight.

We share an optimizer with clang thanks to LLVM; we get to take advantages of those decades already.

Clang and LLVM have evolved together for a while. It is pretty difficult to get similar results with other LLVM frontends.

You don't have to believe me, just write a reasonably complicated algorithm (say.. a naive SAT solver) with both C++ and Rust (or Swift or $NEW_LANG) and compare the speeds.

You don't have to believe me either; if you try it, you should generally see that they have the same performance.

When you say "naive SAT solver" do you mean one where you hard-code a boolean formula with N variables and then check every possible solution (from 0 to 2^N)? If so, does this kind of program accurately characterize the kind of work a kernel does?

No, something like the CDCL algorithm without domain specific heuristics and tweaks. I expect that is fairly representative in terms of ..say.. common data structures needed in most systems.

Here are some fairly realistic examples.

1. Rust : http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

2. Swift : http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

As for a SAT solver, I was not speaking out of my ass. Here is one try that got a fair bit of attention. https://github.com/mishun/minisat-rust

Yeah, we've had some small regressions recently; a few months ago we were usually faster, now we're slightly slower. Still generally close, except for the ones that need explicit SIMD, as that's still being designed.

I think Go has mandatory garbage collection. I think you can turn it off, but you can't manually manage memory.

Manually managing memory is important when you are writing real-time software like operating systems. You don't want the garbage collector to kick in without being asked when you trying to complete a task within a deadline

You could manually manage memory in Go if you want. Here's a few links:

https://news.ycombinator.com/item?id=9545873

https://github.com/teh-cmc/mmm

Probably because Google's C++ tooling is top notch and their developers are all proficient already.

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?

They have an AI now that guarantees no subtle flaws in the C code.

Reply on news.ycombinator.com