Fuchsia Developers Website | Hacker News Reader

Fuchsia Developers Website

fuchsia.dev

205 pointschenzhekl135 comments

It will be very interesting to watch how Fuchsia evolves over the next couple of years. Especially what Google has planned for it.

It might be a small moonshot experiment to see if they can come with a sensible, modern OS.

It might also be the designated successor for Android/Chrome OS, and the future of the Google ecosystem.

Conceptually, Fuchsia is interesting. It's built on a microkernel (Zirkon) and a capabilities based system. Drivers are isolated elf binaries with a stable ABI, other normally privileged things like file systems are also isolated services.

On one hand, I find it promising as a application platform, both for mobile devices and desktops: while Linux sandboxing capabilities are evolving (cgroups , namespaces, ...) , very little of the ecosystem is built around isolation as a primary concept, leading to all kinds of half-baked sandboxing and permission solutions: chroot, Flatpack, firejail, SELinux, (Docker, mentioned hesitantly since it's mainly for server environments)... All of which are somewhat tacked on an hard to use properly.

So a clean sheet design might be the best viable (practical) path.

On the other hand:

* this throws away decades of work on Linux

* many drivers will be closed source; open drivers are a major achievement of Linux

* Linux is a very collaborative effort with many stakeholders, while Google is known for keeping a very firm grip on their projects

Curios to hear other thoughts on this.

I think if Google drops Linux for Fuchsia, there's a chance Microsoft picks up Android development. That would be incredible.

Android will still be Android, but running over a Fuchsia kernel instead of the Linux kernel.

Fuchsia is an OS not a kernel, the kernel running under Fuchsia is called Zircon.

Linux is the last GPL component of Android. Dropping it would enable Google to close up Android source whenever they want.

That doesn't make sense to me at all - you can have a closed source system running on top of Linux, today.

Isn't that exactly what Android is?

edit: misread your comment

No, Android (or rather, AOSP), is fully open source.

Most device makers fork AOSP and distribute binaries containing their modifications. These always come with source code for the GPL portions, and occasionally also the portions licensed under permissive licenses such as Apache and BSD.

For instance, OnePlus and Sony publish these Android sources: https://github.com/OnePlusOSS https://github.com/sonyxperiadev?tab=repositories

> Most device makers fork AOSP and distribute binaries

That's what Google does as well and it's called "Android".

If that was actually Google's intent, then it seems silly to release Fuchsia under any semblance of a free software license.

The bad thing about fuchsia is how closed the development process is. There is no community around it, they don't advertise it, don't encourage broader use and adoption. The contribution process is quite centralized to.

It feels like it's google project and they and only they would decide its direction. So no spontaneous order, it's their way or no way.

Which is expected for their own funded project that's still under active development which they've explicitly decided against publicizing what its strategic purpose or intentions are for it.

> It feels like it's google project and they and only they would decide its direction. So no spontaneous order, it's their way or no way.

Of course they're going to have full discretion of this multi-year heavily resourced investment for which they've spent years developing and haven't officially released yet.

You can re-asses the merits of the project after they've released it, as to whether it's something you want to use or contribute to or not. It's clear at this stage they're not developing Fuchsia with reliance on external OSS contributions.

nah, it's MIT licenced. they're rebuilding, while redesigning, linux - without GPL. i think it's in a way that makes driver development less expensive for hardware manufactuters. stable driver apis mean a hardware manufacturers can care less about maintaining them while the kernel can still update without worrying as much about breaking drivers.

it doesn't really matter if it's currently in secretive development, or not - the result will be that fewer people have access to the code their phone/other device is actually running.

in essence: there's still cause for concern.

>Which is expected for their own funded project that's still under active development which they've explicitly decided against publicizing what its strategic purpose or intentions are for it.

Sure, the OP's question was what's bad about it. That's bad.

>You can re-asses the merits of the project after they've released it

There would be no merits. It's an OS. Who would write the thousands of drivers and layers for various purposes. If there will be no community, there would be no decent OS.

And no, google doesn't invest enough in it. It's either you hire a dev team of thousands people, as Microsoft does, or draw the community. Google did neither so far, and so Fuchsia has fewer drivers than Haiku. Most they want it to be a system working on a few selected phones, or maybe google doesn't even consider it seriously, and it's an initiative of a small group of enthusiasts within google.

> Sure, the OP's question was what's bad about it. That's bad.

Why exactly is it bad, bad for who? It's likely driven by a highly talented focused team, there are numerous high quality OSS projects that are commercially backed and developed internally - not relying on external OSS contributors is not an indicator of software quality. Apple/Microsoft/Google have already done quite well developing their own successful OS without relying on external OSS contributors.

> There would be no merits. It's an OS.

I don't understand what you're trying to say, that OS's don't have value?

> Who would write the thousands of drivers and layers for various purposes.

It doesn't need to support thousands of drivers, Apple has no problems getting drivers developed for their own hardware. It's not even clear it's going to be a general purpose OS, it could be for embedded / or a close knit of selected approved devices. Regardless it's not even released yet so any conclusions to this point is moot, after they're happy for it to have wider adoption they'll open their invitations to participate and add support for it then.

> And no, google doesn't invest enough in it.

How do you know how much Google has invested in it? You don't even know the purpose of it, how could you possibly know how much resources they need to accomplish what they want to achieve?

> Google did neither so far, and so Fuchsia has fewer drivers than Haiku.

So? It's still in active development, maybe they want it stable and battle tested before freezing public APIs and inviting others to build on it, maybe they only want to support selected devices/hardware. No one will know their intentions until after its released or what their plan for adoption will be. Given they already have experience developing and distributing the worlds most popular OS I'm sure they have a good chance at making a Fuchsia a success for their goals.

* many drivers will be closed source; open drivers are a major achievement of Linux

This is only partially true, simply having the source code for a driver doesn't mean you can fix anything given that overwhelmingly the hardware documentation isn't open or the drivers are talking to closed source firmware/binary blobs running on the hardware itself. It makes it easier to fix trivial problems caused by the OS changing, but it doesn't help when a problem is discovered in the underlying hardware/firmware/etc.

So, the open source doesn't help as much as you would like, given the original drivers are frequently written by the hardware provider itself, or some privileged contractor given the documentation under NDA. This has been a huge problem with the ARM soc's that are "supported" in the linux kernel. Frequently they don't actually work following any given update, and no one can fix them because if they have open documentation it frequently is missing large swaths of the actual registers and device theory of operation parts necessary to assure that any given peripheral works.

The source code of the Linux kernel portions is still a huge step in the right direction, even if it comes without detailed datasheets and and talks to proprietary firmware.

It still lets you continue to evolve the internal kernel interfaces without having to worry about the driver's existing ABI.

It still lets you fix most security holes, or remove anti-features that rely on interaction between the firmware and userspace.

Fuchsia, by means of facilitating real proprietary drivers, will take us back to the Windows era, where the OS must support 2 or 3 different driver models in parallel just to continue supporting existing hardware after it has been abandoned by the vendor (which typically means 1 or 2 years after its launch).

Yeah, my 10 year old laptop, bought with Windows 7, is now running Windows 10 latest, without any driver issues.

While my Asus netbook, bought with Linux on it, has lost the DX 11 GPU capabilities and video hardware acceleration thanks to AMD open source driver reboot.

Ah, Asus still pushes updates to Windows drivers on that specific model.

So much for the power of open drivers.

Would be kind of a shame naming-wise if the first sentient devices end up running Fuchsia instead of Android.

How do we know which devices are sentient? The first ones could have ran GM-NAA I/O for all I know.

Not how we'll know, how they'll know.

“i OS” also works, and they may process their thoughts in their own bodies instead of receiving them remotely.

Well, the first sentient device will probably be some supercomputer, so it won't be either of those. ;)

There is no rule that supercomputers cannot run on Android.

Let's just hope a new digital consciousness will be able to first observe something other than the Play Store or it's going have a very dim view of us.

No rule that I know of that sentience necessarily requires a supercomputer, either.

Coming from someone that thinks houseflies are most likely sentient at some level.

I thought that Android fully leverages SELinux? That's how it implemented permissions AFAIK.

SELinux wasn't added until after Android 4.3.

Android's Application Sandboxing primarily relies on Linux's user security model. Each app is assigned a UID and run in that "user's" context. To quote the official docs:

> The sandbox is simple, auditable, and based on decades-old UNIX-style user separation of processes and file permissions.

https://source.android.com/security/app-sandbox

SELinux is an extra layer of security that really benefited system services, drivers, and other exploit vectors. All apps remain sandboxed via normal user security on Linux, and then SELinux sprinkled on top for further hardening:

> Prior to Android 4.3, these sandboxes were defined by the creation of a unique Linux UID for each application at time of installation. Android 4.3 and later uses SELinux to further define the boundaries of the Android application sandbox.

https://source.android.com/security/selinux

Well, Android 4.3 is very old OS. Sandboxing is one thing, permissions are another. You can't deny Internet usage for application with unix permissions, for example.

You can with iptables.

Fuchsia has no real game changing new technology to offer. To me it looks just like a safety backup plan for the case that the Linux kernel can not be used anymore. For a similar reason Valve is pushing for Linux support in Games just in case Microsoft pulls them out of their Business by only allowing their own Appstore.

Google should have forked Inferno OS. The DIS VM looks a lot like Android/Dalvik VM, Limbo looks a lot like an early version of Go and per App namespaces would be a much better alternative to the current way Android sandboxes its Apps.

How would they not be able to use Linux anymore? With it being GPL and everything?

Imagine a scenario where Microsoft's moves into open source aren't genuine. They spend a decade or two working their way into the ecosystem using their ownership of GitHub to encourage Microsoft solutions. One day Google wakes up to find some key component has been replaced with something Microsoft controls, or at least primarily develops. No biggie. They'll just make their own. Until the next one.

I'm hopeful EEE[1] is a thing of the past, but I can see why Google would hedge for the possibility of Linux and open source in general being pod peopled into an ecosystem it can't keep using. They're worried Microsoft will do to Linux what Google did to AOSP. Golang's dependence on importing stuff from GitHub is already a threat.

[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

As someone that follows Android development since version 2.1, when NDK became a thing, Google has been removing GPL component one after the other with each Android release.

With Q, the Linux kernel is the only GPL thing still standing.

No need to worry about Microsoft.

For each GPL component removed, do Google open source the replacement?

No. Google has let AOSP die in the vine. It's nearly impossible to properly run Android without the play store. Most OEMs develop a lot in house to combat the rot that's occurred in the open source components.

Yes the new kernel is open source; it's the play store and perhaps other bits of the full OS they'll hang on to.

> One day Google wakes up to find some key component has been replaced with something Microsoft controls, or at least primarily develops.

Then Google just doesn't take that patch and forks the kernel. Google already has its gLinux team with their own Debian-based Linux distro, and Google has a successful history of leading OSS projects.

You don't think having a stable driver ABI is game changing?

Have you seen the nightmare that is building monolithic pile of crap using lineageOS/etc every-time it gets an update? Even googles own devices (hammerhead/etc) have been known for having binary blobs that have to be extracted and custom wrapped to get them working with the latest versions.

Mainlining the driver is the correct solution, but most Android drivers don't pass the smell test.

I don't understand how is returning to Windows model of driver development is an improvement.

Read NAMESPACES(7)

The Linux kernel itself has a unified sandboxing API, there are just a lot of clients using different parts of it.

And that's pretty nice, being able to pick what you need when developing an OS conceptually just barely above the kernel.

Cgroups is more of a resource constraining API, I wouldn't call it the exact same concern as sandboxing.

http://man7.org/linux/man-pages/man7/namespaces.7.html

I mentioned namespaces.

The point I was trying to make: while you can build sandboxing solutions based on Linux, the entire ecosystem has evolved without sandboxing as a first class concept, leading to numerous half-baked, half-adopted solutions that are all quite cumbersome from a user perspective.

A new OS with sandboxing by default would probably produce a applicaton ecosystem that is more secure.

Also, isolating many normally privileged facilities (like drivers, file systems, ...) is not something that is reasonable on Linux.

I’ve read that, and I helped develop and troubleshoot it. It’s a rather complex solution to the problem that POSIX is not particularly amenable to sandboxing. A good capability-based design can be sandboxed with no fuss at all.

If you read NAMESPACES(7) and thought to yourself "that's a unified API", we have radically different definitions of "unified".

I could see myself using Fuchsia IFF we get the GNU userland and full Posix (including all the optional parts that Linux currently implements) on top of it. Closed drivers are a concession that doesn't sound too bad as long as the userland is proper GNU.

On the other hand, the mere existence of Fuchsia might lead to its best ideas being reimplemented in Linux itself, which would be a win as well.

> I could see myself using Fuchsia IFF we get the GNU userland and full Posix

Then what the hell would be the point?

Closed source drivers running in kernel address space ... realistically — by now we know that even open source drivers running in kernel space isn’t really that great an idea. MacOS/iOS are about to move the file system layer and any third party kernel extensions out of kernel space and into user space — it seems to me an inevitable necessity that the notion that “hardware interfaces need drivers in the kernel” is going to have to die ... the time has arrived where hardware components (other than cpu and memory) need to be viewed as user space programs that the kernel talks to when the kernel wants to...

Or we could wait for Hurd, and it is not a joke.

Fuchsia doesn't implement dot dot to traverse to the parent directory. POSIX doesn't seem likely.

Then keep using a UNIX clone.

Is there any chance they're developing Fuchsia for use in their data centers? As like the Kernel/OS for Google's servers? They already use a custom version of Linux, right?

What I've heard is that Fuchsia is designed to be a consumer OS. Apparently prototype builds of Fuchsia are being tested with Chromebooks and Google Home devices.

Never say never but it's unlikely. Microkernels are slower than a monolithic kernel like Linux, and speed is money for Google's data center software.

   Microkernels are slower than a monolithic kernel like Linux,

Twenty years ago I might have agreed with the basic premise but argued the a properly designed system with a fast zero copy IPC mechanism was worth the small cost.

OTOH, Linux has become massively bloated as it attempts to fit into every nook and cranny. Optimizations that work in one environment simply don't make sense in others. Beyond that computing hardware has changed in 20 years. These days having a bunch of cores is normal, along with scattering them everywhere to manage power/clock or dedicate them for IO is common.

Further a very large number of the highest performing applications are utilizing some kind of kernel bypass. The "standardization" of DPDK despite its shortcomings has brought hundreds of applications out of dark and pointed out the folly of trying to fit everything into a posix view of the world.

Ah the typical microkernel FUD.

UNIX clones, Linux and BSD variants are the surviving monolithic kernels.

On embedded space, most high integrity OSes are microkernel based, Apple and Microsoft OSes are hybrid variants, and as shown at this year's WWDC in a couple of years Apple OSes will only allow for user space drivers.

Even Android now uses a mixed model with userspace drivers (Treble compliant ones) and the standard Linux drivers (Treble legacy mode drivers).

It's not FUD. Measure system call latency on Fuchsia and Linux for a simple read(), and you'll see Fuchsia is slower. It's the context switch that kills you, not the copies. Of course you could use FUSE on Linux and it would be just as slow.

Now go do same with INTEGRITY, QNX, L4 and plenty of others used in production on real time scenarios where Linux is found lacking.

I will, because I am genuinely curious. However the original question was about Google data centers, which do not care about real time. Real time means timely not fast.

One other con for ya:

* Google is very likely to kill privacy enabling features

Yeah as a dev I am not touching this with a 5 foot pole. Google open source is not open source. It's a nasty tactic of pretending to be open source while not actually being open source as the speed of development is so fast that it's impossible to fork anything and then its laden with proprietary blobs where you have to "trust" Google which basically means tolerate them doing nefarious shit.

> ...as a dev I am not touching this with a 5 foot pole. Google open source is not open source.

I do not understand what this means, the code is open isn't it?[0]

This sounds very over exaggerated and alarmist, just like Android and for example Chromium people have forked it and removed all the Google proprietary stuff from it[1], I am sure you and other privacy conscious developers in the future will do the same for Fuchsia.

[0] https://fuchsia.dev/fuchsia-src/development/source_code

[1] https://github.com/Eloston/ungoogled-chromium

Yes, it's open source. I wouldn't try to claim it isn't, like the parent is doing. However Google being behind it still makes me nervous, specially since this might end up replacing the copyleft Linux kernel and contributing to furthering the locking-down and tivoization of Android.

Chromium doesn't match with this description. It has a ton of forks and derivative works, both open source and commercial.

https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browser...

I find the Fuchsia Interface Description Language (FIDL) interesting as a concept. It allows components written in different languages to easily cooperate:

- Language: https://fuchsia.dev/fuchsia-src/development/languages/fidl/r...

- Wire-format: https://fuchsia.dev/fuchsia-src/development/languages/fidl/r...

I think it is an underappreciated concept in today's systems, which suffer an epidemic of monolithism, leading to GB-sized installations that do their own variation of.. nothing much.

That is just the next step of AIDL and HIDL from Android.

https://developer.android.com/guide/components/aidl

https://source.android.com/devices/architecture/hidl

And it goes back to ideas like DCE and Taligent.

https://en.wikipedia.org/wiki/Distributed_Computing_Environm...

https://en.wikipedia.org/wiki/Taligent

Also how XPC works on Apple platforms (IDL here are Objective-C protocols).

https://developer.apple.com/library/archive/documentation/Ma...

The 'Pink' of the phrase "Pink + Purple == Fuchsia" is a reference to Taligent's Pink, and 'Purple' appears [1] to be a reference to 'Project Purple', the effort at Apple that culminated in the release of the iPhone.

[1] https://spectrum.ieee.org/tech-talk/computing/software/a-mod...

Fidl is the direct evolution of Mojo

https://chromium.googlesource.com/chromium/src/+/master/mojo...

For some reason Fuchsia has always reminded me of Windows. Or at least what Windows would have been had it been built from a clean slate in 2019.

The handles etc. have clear Windows analogues and Wire is basically COM.

That's probably not a mistake. NT has some really solid design concepts that POSIX missed on.

> NT has some really solid design concepts that POSIX missed

Such as...? Genuine question. I was impressed a few years ago when I tried Ubuntu for Windows, but maybe that has nothing to do with the NT design.

IO completion ports, for example

The wire format seems strongly related to protocol buffers, which is to be expected from a Google project.

At Google it's not uncommon to have common code "libraries" actually being separate process exposing a stubby rpc interface (similar to gRPC) over shared memory IPC. It solved several inter-language issues that plagued things like swig and counterintuitively it can also be as fast of even faster than direct cross-language integration.

Story A user-facing logical container encapsulating human activity, satisfied by one or more related modules. Stories allow users to organize activities in ways they find natural, without developers having to imagine all those ways ahead of time.

Interesting. Does it mean that medules are able to declare their capabilities and the system then draws the UI around what the user wants to achieve?

For example, let's say I want to order pizza. Instead of having to download Domino's app, the system create a story based on the action of ordering pizza with all the relevant module that allows me to order said pizza.

Not sure if I understand that correctly.

I am excited for any attempt at innovation in the operating system department.

It is too early to tell how Fuchsia will do but at least they are trying.

I think https://www.qubes-os.org is interesting as well.

Unfortunately almost every attempt to get a new OS out there has failed in one way or another. (as far as user adoptation). There are some pretty nifty things out there.

I hope to the higher powers that Linux, UNIX or WindowsNT is not the end of the line.

I think it was a very exciting time when you had Atari ST, Amiga, BeOS, NeXT, Solaris etc competing.

I fear monoculture is most things. Browsers, operating systems, politis.

What features do you feel that Linux is lacking (or could be improved if you were willing to start from scratch and say to heck with backwards compatiblity)?

Is it confirmed that Fuchsia will be heavily involved with Flutter?

I thought the only thing that had been confirmed about Fuchsia is that apps for it will be written in Flutter. Aside from that I've wondered if maybe it was Google's version of Microsoft's Midori project which was a microkernel operating system written in C# from which many lessons learns have been implemented in what we know today as Windows 10.

Or it could be a plan to abandon Android in order to avoid Oracle's Java API lawsuits.

It would have been cheaper to buy Sun instead of hoping that no one would pick it up.

Now they have a scene manager that is UI framework agnostic.

https://fuchsia.googlesource.com/fuchsia/+/HEAD/docs/the-boo...

And ART is being ported to run on Fuchsia.

https://android-review.googlesource.com/q/status:open+Fuchsi...

So it remains to be seen.

By default GUI apps for Fuchsia will be written in Dart with Flutter SDK.

Fuchsia also supports C++ so I imagine you will be able to use Qt et al.

I am curious if anyone knows if Google is going to bake analytics into the OS, like Android?

Will it be data collection free, and just push users to use Google services as the default, or will it have data collection baked in?

Well, it's open source and build on the idea of interoperable components. So while Google may package data collection components it would be straightforward to build a version without them from source.

Whether you are able to put it on your phone in a working state is then the question though. You would need drivers for all parts which might be closed source and not compatible with your build.

Hopefully there's a stable driver ABI, or at least an ability to use multiple versions, so you're able to use these blobs however you want. Sad state of affairs is firmware.

> Documentation for developing for the open source operating system. Is fuchsia Android style open source or a true OSS?

What do you mean by true OSS?

Android is more of an open core project. AOSP is technically fully open source but when people say Android they mean the Android version of Google with the play store and play services.

The naming is confusing because what people call Android is not actually Android like what people call Linux is not actually Linux but a distribution.

Even with ASOP it tends to be more of a code dump than an open source development process. If you're an OEM you get to see it earlier in development (and get to dump your own OEM patches in there) but for most people the actual development is done behind closed doors.

Android style is true open source. I presume you mean "is Google going to work closely with non-Googlers to develop it" and I doubt it.

AOSP style is true open source, not Android. There are not too many phones sold with AOSP, and Android is a closed platform built on top of open AOSP core.

A phone is frankly unusable with just AOSP with today's apps

Today's open source apps?

Not saying I agree with the state of things, but very few people use open source apps other than a few high-profile ones (Chrome, Firefox, Telegram, et Al).

We need open source alternatives to everything for AOSP to be truly viable again.

LineageOS with F-Droid practically achieves this, but Google's contracts stop OEM from distributing this. The same situation from Microsoft and Linux a while back.

You or I may be able and willing to buy OSS phones, but the average consumer never would common proprietary software (FB, YouTube).

OEMs would never bother selling them in the first place, obligations or not.

Can't you redistribute NewPipe, and the whole shebang? I agree that selling phones with AOSP/LineageOS only is worthless.

For Facebook, you can make a custom Firefox bookmark, or one of those WebViews hard-coded to Facebook.

You need to add microG to the mix, otherwise a lot of Android apps (including many open ones) won't work at all on your "Android".

I think it is more if they will encourage any use outside of the control of Google. Or if they, like with Android where they illegally obstructed companies from doing so, will even discourage it.

That, plus they actively deprecated open source part in favor of their closed-source alternatives, and basically made the Android operating system useless (especially with regards to compatibility with the android SDK) without their closed-source parts.

So, it is technically "Open Source", but I am not sure I would call it "Free software" in the spirit. Especially the permissive license, which gives developers free reign over their forks.

I really like being able to get kernel sources from various phone vendors, and that's what enables projects such as postmarketos or lineage (though lineage is less concerned about getting the kernel sources/upstreaming, it seems). I just wish there was an anti-tivoization clause in the Linux kernel license.

I've always been conflicted about that. They started down that path in response to intransigent OEMs leaving people with year old phones full of vulnerabilities, but it's turned into a justification to load all the important userspace into apps they control.

On the one hand, it's great that old phones see some updates. On the other, it's terrible that Google used it as an excuse to reject and weaken the very ecosystem that propelled them to where they are.

They've made some efforts to improve the ease of updating older phones for both OEMs and users, but they keep key components locked down.

Why not Minix 3? https://www.minix3.org/

Heck, while we are dreaming: Why not buy the rights to Plan 9 and start improving on those ideas, now that would be interesting.

It doesn't seem to work in Chromium.

What isn't working for you? I'm not having any issues in chrome.

List on the left column behaves well if scrolled via scrollbar. It goes nuts when trying to use the entries at the bottom if scrolled with mouse wheel.

There's another comment or two saying the scrolling is acting weird when they have javascript turned off. Perhaps that's it?

JS is on, so no.

Maybe they think it has to do with javascript, and it does not for them either.

This is chromium on Linux.

For the record, I'm also on Chromium on Linux (Ubuntu w/ awesomewm) and scrolling works for me. Weird.

Arch w/i3.

The APIs look painfully overcomplicated.

The website refuses to scroll without javascript. WTF?

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.

The first part of the documentation being the code of conduct is a ... fuchsia flag

The code of conduct is the #3 and #4 point of the Linux developer documentation.

https://www.kernel.org/doc/html/latest/process/index.html

Reply on news.ycombinator.com