[Sir_Cmpwn]

Because it's an easy indicator of someone who has no idea what they're doing in OS development. Choosing the wrong tool for the job is meaningful. Have you ever looked through Chromium's C++ codebase? The same people are working on this and it tells us that they haven't learned their lesson (or they want to tightly integrate Chrome with Fuschia, which is also a foreboding sign).

Edit: I should clarify that I think C is the only rational choice and that Rust is ill suited to osdev as well. I'm only talking about C++ here.

[chipotle_coyote]

> Because it's an easy indicator of someone who has no idea what they're doing in OS development.

From appearances, the lead "someone" on at least the kernel appears to be Travis Geiselbrecht, who worked at the OS and/or kernel level on BeOS, the Danger Hiptop (Sidekick) OS, his own NewOS (now the basis for HaikuOS), and an embedded OS at Jawbone before joining Google and starting work on LK, which is being used as the basis for Zircon and the Android bootloader.

So I think maybe you mean

> Because it's an easy indicator of someone who does not have the same opinions about OS development than I do.

...because, y'know, that's fine! But "this guy obviously has no idea what he's doing?" Gonna agree to disagree there.

[coldtea]

>Because it's an easy indicator of someone who has no idea what they're doing in OS development.

Actually suggesting Rust as some kind of magic bullet over C/C++ is a huge indicator "of someone who has no idea what they're doing in OS development".

It's similar to when first year CS students learn that assembly is "faster" (a hazy notion itself), and then want everything to be written in assembly.

[jrimbault]

>It's similar to when first year CS students learn that assembly is "faster" (a hazy notion itself), and then want everything to be written in assembly.

That's an interesting kind of first year students... The kind I know flee before anything lower than C++.

[Sir_Cmpwn]

Added to my comment:

>Edit: I should clarify that I think C is the only rational choice and that Rust is ill suited to osdev as well. I'm only talking about C++ here.

[happyguy43]

Nah, writing a kernel in modern C++ or Rust is pretty rad. Higher level abstractions can be designed to avoid bugs (As evidenced by the explosion of macros in the Linux code base). Check out L4Ka::Pistachio https://github.com/l4ka/pistachio

[bitmapbrother]

>Because it's an easy indicator of someone who has no idea what they're doing in OS development. Choosing the wrong tool for the job is meaningful. Have you ever looked through Chromium's C++ codebase? The same people are working on this and it tells us that they haven't learned their lesson.

Have you looked into the backgrounds of the main developers working on Fuchsia OS? Because if you had you would have discovered that that they have a rather impressive resume who actually know what they're doing.

Travis Geiselbrecht - BeOS, iOS, Hiptop OS, Little Kernel

Brian Swetland - BeOS, Hiptop OS

Chris McKillop - a member of the original iPhone team, WebOS, QNX OS, Hiptop OS

[Sir_Cmpwn]

Someone said something similar earlier, but I chose not to respond to avoid getting deeper into an unrelated argument. The short of it is that I don't find BeOS (and Haiku) particularly impressive. WebOS is all userspace and I don't really care how Fuschia's userspace looks, and I have to admit I don't know much about QNX or Hiptop.

[greenhouse_gas]

I know you're a prolific commentator here, so if you don't mind me asking ... Which operating systems have you designed (or worked on) to say that writing a microkernel in C is a symptom that they don't know anything about OS development?

[Sir_Cmpwn]

Writing a microkernel in C is fine. I said _C++_. But for the record, I built this:

https://github.com/KnightOS/kernel

And I've worked on toy kernels here and there and studied more serious kernels in depth.

[kajecounterhack]

You're probably missing their tradeoffs. Google has deep expertise in C++ within the company and integration with existing libraries / tools is a huge bonus. So if the goal is a market-ready product and velocity matters, then it makes sense not to adopt a new language that is still changing a lot. It's only your opinion that they've chosen the wrong tool. There isn't one right answer to nuanced product decisions.

[Sir_Cmpwn]

>then it makes sense not to adopt a new language that is still changing a lot

I should clarify that I agree with eddieh and think C is the only rational choice.