
Fuchsia Programming Language Policy - farmerbb
https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/docs/project/policy/programming_languages.md
======
mythz
Very interesting to see a technology focused analysis of what Google thinks
about the strengths and weaknesses of the different languages are.

Usually analysis's embed personal biases or are either marketing sponsored
posts to spur adoption but this looks to genuinely look at the technical
merits of each language in the context for using it to develop Fuchsia OS.

From this analysis C++ and Dart are given the green light, Dart for high-level
code as "Asynchronous programs can be written using straight-line code and
People using the language are highly productive." but because of its GC and
substantial runtime environment it's "more resource intensive" and not ideal
for programs that run indefinitely.

The comparisons between Google's designed and controlled "Go" vs Mozilla's
sponsored "Rust" is very interesting, since Go is widely used within Google
and its implementation could be influenced by Fuchsia it was initially used
but because of their negative experiences it's been blacklisted with all code
except netstack needing to be migrated to an approved language.

The biggest con of Rust seems to be that it's still new, not widely used and
its unique properties haven't been time tested enough yet, but as it's still
approved as it's more performant and requires less resources than Go.

~~~
phkahler
They mentioned one of the pros of C that nobody seems to talk about. The
stable ABI that allows language interoperability via FFI. Until another
language gets this right, C is going to be ever present at the bottom of every
stack.

~~~
kryptiskt
The C ABI doesn't require the presence of C in the stack, it can just be there
in spirit like the ghost of Pascal in the Windows ABI.

~~~
jacobush
Yes, but in practice it's often easier to just fire up the C compiler and do
some shim files and linking in the bottom.

~~~
bluejekyll
Easier than what? Their are a lot of languages that make exporting/importing C
ABI dead simple. Rust, C++ and C# are some I’m familiar with, I’ve also been
pleasantly surprised at Node.js (for imports) in this regard.

------
dhodell
This policy hasn't changed in over a year. I'm on paternity leave now, but my
job is Go on Fuchsia, and I work with people doing Rust on Fuchsia. None of us
are concerned for our jobs based on this document (which we've collaborated
on).

This policy, like most technical decisions, may be amended when things change.
We want people to have a consistent and stable platform to develop on, and if
a language doesn't officially support our platform, it kind of doesn't make
sense to support that language. And there's no commitment to support these
languages for production services and end user development until there's a
story for the stability of that toolchain on Fuchsia.

This shouldn't be surprising. Make a new system, bootstrap your programming
environments. Why bother offering support for environments you've not yet
bootstrapped?

As a thought experiment, consider the thousands of languages (including the
tens or hundreds of popular ones) not listed on that page, and whether they're
supported.

(Edit: I accidentally a word.)

~~~
malkia
Is there anything (in the plans) to make fidl cross platform?

~~~
dhodell
Not sure what you mean. FIDL as a language and protocol is conceptually
inherently cross platform. There are already bindings for multiple language
platforms that can be generated from a FIDL specification, and theoretically
one could implement a FIDL service anywhere. That said, FIDL services in the
system provide a sort of ABI -- the F in FIDL stands for Fuchsia, after all --
and I'm not aware of any actual efforts to implement these on platforms that
aren't Fuchsia.

~~~
malkia
Thanks! I was more going about the ecosystem - like grpc/protobuf have and
support across languages/runtimes/systems.

~~~
raggi
We use FIDL on host (Linux & macos) platforms via the overnet project. As far
as language ecosystems go, as swetland rightly points out below, being runtime
agnostic is important to us. FIDL being easy to implement generators for new
runtimes is part of that. There is some nascent documentation on porting
runtimes here: [https://fuchsia.dev/fuchsia-
src/development/languages/new?hl...](https://fuchsia.dev/fuchsia-
src/development/languages/new?hl=en)

~~~
malkia
Thank you so much for this information!!!

------
est31
For the distribution of languages inside fuchsia, this is the output of "tokei
-s lines" in the git checkout of fuchsia:
[https://gist.githubusercontent.com/est31/5c13979043e760a597a...](https://gist.githubusercontent.com/est31/5c13979043e760a597a019999d5602de/raw/acd8458ab45ebac186dc1a0e700985fb68d663db/gistfile1.txt)

According to this, Rust is the language with the most lines in fuchsia. It's
important to point out however that of those 2.2 million lines, 1.4 million
come from the third_party directory, which includes vendored libraries, mostly
Rust ones, and sometimes also multiple versions of a library. The src
directory contributes 0.7 million lines of Rust. If you add up the two
numbers, you get 2.1 million, so most Rust code resides in those two
directories.

This is the tokei output of the src directory:
[https://gist.githubusercontent.com/est31/5c13979043e760a597a...](https://gist.githubusercontent.com/est31/5c13979043e760a597a019999d5602de/raw/5e770560cb9dbdfa6e5d95d7bb741334f29e7aff/gistfile2.txt)

To compare those 0.7 million with other big Rust codebases: Servo has 0.39
million lines, the Rust compiler 1.4, and parity-ethereum has 0.18 (using
tokei and only looking at the git repos here, without excluding and tests or
including dependencies outside of the recursively checked out repo).

~~~
mythz
Not sure what these results is meant to be measuring since most UI Apps are
written in Dart which is unlikely captured by the 10k LOC across 123 files
reported.

Unfortunately since they've removed their mirror on GitHub we can't easily
compare these results vs GitHub project stats, unfortunately their
[https://fuchsia.googlesource.com](https://fuchsia.googlesource.com) UI is
particularly useless at showing any kind of aggregate analysis.

~~~
est31
I cloned the fuchsia repo, this one:
[https://fuchsia.googlesource.com/fuchsia/](https://fuchsia.googlesource.com/fuchsia/)

It's the main repo but some components are outside. I presume that the UI apps
are among those components.

~~~
mda
Some UI apps are here:
[https://fuchsia.googlesource.com/topaz/](https://fuchsia.googlesource.com/topaz/)

------
maximilianroos
A more positive take than many of the comments here: this seems like an
thoughtful and balanced synthesis of the various tradeoffs between languages
for systems development, at least from the perspective of a large project with
many developers.

------
nnq
> Go is not approved, [...] All other uses of Go in Fuchsia for production
> software on the target device must be migrated to an approved language.

Probably makes sense, not what Go was designed for, but I really don't get
big-G's choice of "one different language for each niche"...

I mean, ffs, Go _and_ Dart are both garbage-collected and compiled, even their
lists of pros and cons look similar. Couldn't they just blend their features
into one language (like, eg., add generics + some syntactic sugar to Go, to
make it more usable for app and GUI code too?) instead of fragmenting the
mindspace even more? _Why don 't people see the advantage of "universal"
languages? It's obvious that developer love them and they are empowered by
them, hence the success of languages like Javascript/Typescript and Kotlin
despite their obvious flaws and limitations!_

~~~
sjwright
I seriously thought Dart was abandoned. Is it actually being used outside of
Google?

~~~
pjmlp
Living under a rock?

It was rescued by the AdWords team, and later the Flutter team decided to use
it instead of JavaScript, in the process they turned Dart into a strongly
typed language with type inference (thus everyone from the dynamic camp left
the design team), and nowadays the future of Flutter and Dart are tied
together.

Flutter became enough of a nuisance that Android team has now come up with
Jetpack Composer, to detriment of the existing Android UI toolkits, because
they need to have their Java/Kotlin Flutter.

~~~
Aissen
Quoting HN rules:

> Be kind. Don't be snarky.

Your comment would have been quite helpful if you just removed the first line.

~~~
pjmlp
Noted.

------
flohofwoe
> ...and supports for production software on the target device

Assuming I understand this right... why should an operation system limit the
programming language used for creating applications in at all? That's a bad
trend to follow which unfortunately seems to be quite common on more recent
platforms.

Since C seems to be supported (which I assume means: there are C headers for
operating system APIs, and which btw is a great thing), wouldn't any language
work which can call into C APIs (which is nearly every programming language on
the planet).

E.g. even if the OS doesn't "officially" offer Go bindings, why should a
third-party not be able to come up with Go bindings via the C-APIs? Also "Con:
The toolchain produces large binaries." is laughable, because from the POV of
a C programmer, _everything_ else out there produces "large binaries" ;)

~~~
lonelappde
It's ambiguous. "Not supported" might mean "we aren't going to write APIs in
that language, and if you manage to hook in via FFI we don't promise
stability. Also, since Fuchsia is security oriented, it probably will block
various low level tricks for accessing system resources that don't use
official APIs.

Reading between the lines, it seems Dart isn't better than Go from a
performance perspective, but Dart is great for UIs so it is worth paying it's
cost on an embedded device.

------
aphextron
Interesting that the only con listed for Rust is _Not enough people are using
it_ , compared to the serious criticisms of the others.

~~~
sk0g
Pretty much every con in Rust is some variation of (we | others) don't use
Rust enough. Interesting to see!

Would have assumed the Kernel would be where Rust truly shines, but that's
where it's blocked, which is... interesting!

~~~
bsder
I'm not very happy to see C++ infecting more and more system software when it
_STILL IN 2020_ doesn't have a stable FFI/ABI.

This is going to bite us _ALL_ in the future because it will saddle other
languages with a useless set of constraints long after C++ gets removed from a
project.

~~~
jcranmer
With the exception of the change to std::string in C++11, which was very,
_very_ carefully worked around so that C++11 code can handle C++03-ABI
std::string, there have been no changes to the ABI implementation since the
Itanium ABI was adopted by gcc almost two decades ago.

How is that not a stable ABI?

~~~
rndgermandude
That's not a C++-ABI but a C++-as-compiled-by-gcc-ABI. C++ itself does not
define an ABI and different compilers (sometimes even from the same vendors)
will use different incompatible ABIs.

~~~
gpderetta
It is the linux standard C++ ABI as the defined by the linux standard base. An
ABI for low level language is necessarily (OS, architecture) specific, so you
can hardly do better than that. There is no ABI that could be usefully defined
at the standard level (and even if it somehow were, it would be mostly
ignored[1] as compilers wouldn't break compatibility to implement it).

[1] I could see the committee standardizing some intermediate portable
representation requiring installation time or even JITing in the future
though.

~~~
rndgermandude
It is not the linux standard C++ ABI, it's just the defacto standard ABI
because of gcc's former dominance and clang intimidating the ABI. And I broke
things in the past, where I had to recompile stuff, due to different compilers
(clang, clang+libc++, gcc in different -std=c++ modes) producing not 100%
compatible outputs.

You can say it's good enough (most of the time), but it isn't really a
standard, unless I am mistaken.

~~~
jcranmer
[https://uclibc.org/docs/psABI-x86_64.pdf](https://uclibc.org/docs/psABI-x86_64.pdf)
page 106 cares to disagree with:

> 9.1 C++

> For the C++ ABI we will use the IA-64 C++ ABI and instantiate it
> appropriately.

The Itanium ABI _is_ the official C++ ABI on Unix systems. (Note that this
same document officially documents the C ABI).

~~~
gpderetta
although it might the facto be, at least for AMD64, I wouldn't say it is the
official standard ABI of all unix systems. But it is the standard ABI of Linux
based systems, at least those that claim to conform to the LSB.

------
sk0g
Seems like Go has more positives and the same negatives as Dart, but Dart is
approved while Go is being scrapped in Fuchsia land.

Having said that, I wouldn't want to work on GUI applications with Go, while
Dart did have some handy semantics when I tried it.

A rather low level of detail in this comparison though, would have liked
something a little more in depth.

~~~
ohazi
The big difference seems to be:

Con: The Fuchsia Platform Source Tree has had negative implementation
experience using Go.

i.e. they tried it, because they're from Google and they basically had to, and
it wasn't great.

Not surprising, honestly, given how opinionated (in the "users of this
language are stupid" direction) Pike, et. al. seem to be.

~~~
Bendingo
> opinionated (in the "users of this language are stupid" direction) Pike, et.
> al. seem to be

Such a strong statement, wrapped in quotes to make it seem that this is Pike's
literal words, should really be substantiated with a reference. Otherwise
you're putting words in Pike's mouth that he never said.

~~~
logicchains
“The key point here is our programmers are Googlers, they’re not researchers.
They’re typically, fairly young, fresh out of school, probably learned Java,
maybe learned C or C++, probably learned Python. They’re not capable of
understanding a brilliant language but we want to use them to build good
software. So, the language that we give them has to be easy for them to
understand and easy to adopt.” – Rob Pike

~~~
Bendingo
You have supported what I said; they were not his literal words.

Where does he say "users of this language are stupid".

------
nine_k
C and C++ are the only languages used in widely deployed production OS
kernels, so Fuchsia decides to only use them in its kernel, too.

Nobody seem to want to stand out and use e.g. Rust in the kernel, so the
situation is perpetuated. (How old was C again when it was used to write the
Unix kernel? Apparently Google's stakes here are higher.)

~~~
monocasa
I think that it's more that they already have a kernel, and their focus is
moving as much as possible outside the kernel rather than adding to it.

And, FWIW, I can see a point where they have a kernel written in C or C++
that's formally verified (like sel4), at which point, what's the point of
rewriting it in Rust? sel4's semantics are stronger than what Rust gives you
out of the box.

I say this as someone who's written a handful of Rust kernels, and is quite
bullish on Rust adoption.

~~~
dogprez
Neat, I didn't know about seL4. Can you point me to how they define the proof
for it?

~~~
monocasa
They've done a really good job documenting it in their papers and online docs,
but the general flow is to verify equivalence of the generated binary and the
formal specification, then to prove properties like memory safety of the
formal spec.

I'd start here if you want to learn more:
[https://sel4.systems/Info/FAQ/proof.pml](https://sel4.systems/Info/FAQ/proof.pml)

Let me know if you have any other questions.

------
dotasm
Definitely sad to see Go get blacklisted and put on the “eventual replacement”
list. The reasons, like Dart’s, make sense, but it’s still gotta be kick in
the teeth for the Go team. I wonder how difficult it was for them to use it
and if it was during one of Go’s “transitional periods.”

I wonder if Rust/Elixir will be the one to eventually replace it.

~~~
calcifer
One of the problems they've mentioned, large binaries, is being tracked [1]
for the past _7 years_ and it's getting worse with every release.

Not to mention compile times are still much longer than what they were pre-1.5
when the compiler was written in C.

[1]
[https://github.com/golang/go/issues/6853](https://github.com/golang/go/issues/6853)

~~~
pjmlp
To be fair to Go compile times, with them using C++ and Rust, that wouldn't be
a show stopper.

------
scoutt
> Pro: The Fuchsia project has the opportunity to influence the evolution of
> the language. (RUST)

While this may be a _Pro_ for Google, is it also a _Pro_ for the users? Does
this mean that Google would hold (if not already) a chair in some "foundation"
and decide which features goes into the language (and how they will be
implemented)?

If this is the case, I don't like it very much... That would be a _Pro_ for C,
or whatever language out of their reach (as in The Fuchsia project _doesn 't_
have the opportunity to influence the evolution of the language).

~~~
nicoburns
There is no Rust foundation. All of the design and development happens in the
open on Github, a public discourse instance, and a few chat programs (zulip,
discord, matrix). I believe the Fuchsia project was quite involved in the
design of the async-await feature, along with the team behind `tokio` and
others.

~~~
rob74
Interesting! Async-await is mentioned as a "pro" for Dart and Rust
("Asynchronous programs can be written using straight-line code"). Seems they
really like async-await, and they had more success getting Rust to support it
than they had with Go - which might have led to some Google-internal strife?

------
fiddlerwoaroof
It’s really irritating to see platforms picking the programming languages that
can be used for real applications: why should the Fuchsia developers decide
that I can’t write my application in Go/Rust/Lisp/whatever? Just provide a
sandbox and a platform spec and allow third parties to build whatever
tools/languages make sense.

~~~
CDSlice
Isn't this just a list of languages allowed to use when writing Fuchsia? I
don't see how they would ban users from writing their apps in say Go or
Clojure.

~~~
fiddlerwoaroof
> This document describes which programming languages the Fuchsia project uses
> and supports for production software on the target device, both within the
> Fuchsia Platform Source Tree and for end-developers building for Fuchsia
> outside the Fuchsia Source Platform Tree. The policy does not apply to (a)
> developer tooling, either on target or host devices, or (b) software on the
> target device that is not executed in normal, end-user operation of the
> device.

As far as I can tell, this is supposed to be “the” languages that can execute
on a Fuschia-powered device.

~~~
_-___________-_
They have no means to enforce that. They're talking about what they provide
support for, not what is possible.

~~~
fiddlerwoaroof
If you control the App Store, you can enforce a policy like this. And, the
whole security model of Fuschia seems great for enforcing something like this:
use object capabilities to grant access to everything and don’t provide a
stable API for getting those capabilities in unsupported languages.

~~~
_-___________-_
Unless you have the developers submit source code, it's not really possible to
determine what language the source code was written in (if the developer
doesn't want you to). For example, if there is a C API, I could write my code
in Rust and with only a little effort, have it compile to something which
could also have been compiled from something written in C. Even for languages
with a more substantial runtime, you could "transpile".

~~~
fiddlerwoaroof
The thing is, you don’t need to make it impossible, just difficult and
officially say that it’s “unsupported” to make it a non-starter.

------
snarfy
As a user and a developer, I have zero interest in Fuchsia. Between Android
patents and Oracle lawsuits, the only problems Fuchsia solves are Google's
problems.

~~~
jasondclinton
Do you ever wonder why Android phones don't get updates to new Android
releases? It's the kernel and all of the vendor-specific hacks that makers do
to the kernels they ship. A microkernel could make a big improvement on that
problem.

~~~
snarfy
We should be encouraging vendors to release the source to their binary blobs
instead of making it easier for them.

~~~
int_19h
This has been the mantra since the first proprietary drivers for Linux. They
still don't do it, so we can keep banging head against that wall, or try
something else that would actually work.

------
lawrenceyan
Are there any major products/services where Rust is being used besides Firefox
right now?

~~~
brson
There are. Here is a copy of my notes on the subject:

[https://gist.github.com/brson/9422a92791062ac52d9e08f0ba7d48...](https://gist.github.com/brson/9422a92791062ac52d9e08f0ba7d48cf)

Sorry it's not more organized and detailed.

~~~
steveklabnik
Another recent big user is 1password, both on the Windows desktop and in the
browser with wasm. Great notes!

------
jillesvangurp
Lets wait until they actually have devices and OEMs lined up, which may very
well be never. I can't imagine e.g. Samsung being very excited about buying
into this new Google walled garden. And this our way or the highway type
policy is not going to help. So, that means they are either looking at long
term maintaining both Fuchsia and Android, or a hard fork of the Android
ecosystem by one of several third parties. And I doubt Google is going to walk
away from huge chunks of mobile device market share any time soon.

In any case, Kotlin is the obviously superior language compared to Dart that
they already have a lively developer ecosystem for. And it has a native
compiler that the before mentioned ecosystem already uses to not be stuck
using Dart when writing IOS and Android libraries that can be used from a
flutter UI.

I don't see any major technical hurdles for also having bindings for Go, Rust,
Swift, or other languages in the llvm ecosystem. Obviously the whole thing has
native bindings (flutter basically transpiles to C++). Swift support would be
a major enabler for bringing in IOS developers. Come to think about it, WASM
and flutter could be a nice marriage as well. And yes, I've heard the
arguments why all this is not possible on multiple occasions from flutter fan
boys. IMHO that's a problem that needs fixing and not an inherent design
limitation. It's a prioritization problem. It boils down to Google being
stubborn and arrogant. It boils down to not invented here syndrome.

------
stewbrew
The con arguments for dart and go are quite similar. I cannot really derive
the decision about the support status based on these arguments alone. To me
this sounds more like personal reasons.

~~~
DenseComet
Elsewhere they have mentioned the UI is written in Flutter, which is
completely Dart based. It seems as if this is what tipped the scale. Both are
Google-developed languages, but one seems to be closer to the project.

------
alphachloride
For Dart:

> Pro: People using the language are highly productive.

Ok you convinced me.

~~~
moksly
I’m not sure if you’re being sarcastic, but to management in enterprise
organisations this is the single most important feature of a programming
language because the most expensive resource you have is your programmers.

~~~
timkam
My interpretation of the comment is that it is criticizing the somewhat
baseless claim. I find it hard to believe that even internally at Google the
statement is considered an indisputable truth. I agree programmer productivity
is a complex management challenge that everyone would be happy to have a
silver bullet for.

------
pyb
The interesting bit is at the end : they really don't like Go, a language that
was developed at the same company.

~~~
numlock86
> [...] they really don't like Go

Can you cite the part you are referring to? The only negative parts they state
are used memory resources and large binaries, which is really not desired on
an embedded device, but usually totally neglectable on any dedicated cloud-
computing hardware.

~~~
pyb
I am inferring this from the language they decided to use.

They know that the Go team are going to read this : "The Fuchsia Platform
Source Tree has had negative implementation experience using Go...". They
could have sugar-coated a lot more, but chose not to.

------
pier25
IIRC last official news I heard from Fuchsia is that it was an experiment to
test OS features.

Is this is still the official position?

~~~
jml7c5
I don't know if there's been any official change, but I think it's pretty
obvious it's going to be used in some form or other. Unless the project ends
up being an irredeemable failure (e.g., fundamental design decisions make it
not performant enough, insecure, etc), there's no reason for them to just drop
it. It solves too many of Google's problems with regard to Android and Chrome
OS.

~~~
pier25
I agree, I always expected it to replace Android and Chrome OS into a single
OS.

------
lerax
Basically... Dart and C++ only?

~~~
_-___________-_
That is _really_ far from an accurate summary of the document.

------
adir1
With growing popularity of Python inside and outside of Google, any idea why
it is not in the policy?

------
walkerbrown
Is this doc no longer valid? [https://fuchsia.dev/fuchsia-
src/development/languages/new](https://fuchsia.dev/fuchsia-
src/development/languages/new)

It's worth noting the distinction between the _Fuchsia API Surface_ (consumed
by End-developers) and the _Fuchsia System Interface_ here:
[https://fuchsia.dev/fuchsia-
src/concepts/api/council#definit...](https://fuchsia.dev/fuchsia-
src/concepts/api/council#definitions)

------
dvfjsdhgfv
> Con: Rust is not a widely used language.

and then:

> Decision: Rust is not supported for end-developers.

------
emilfihlman
I cant help but think that "highly productive" here is not really a super
scrutinised reason.

------
The_rationalist
No stated support for Java and Kotlin? This is meaningless and show that
fuschia is run by vaporware people.

~~~
wffurr
Really? There no support for those on iOS either and it's hardly vapor ware.

~~~
kpgalligan
Well, technically speaking there's Kotlin support
[https://play.kotlinlang.org/hands-
on/Targeting%20iOS%20and%2...](https://play.kotlinlang.org/hands-
on/Targeting%20iOS%20and%20Android%20with%20Kotlin%20Multiplatform/01_Introduction)

------
Gonzih
Oh it saddens me so much that Rust is not approved for kernel development, oh
well.

~~~
steveklabnik
Remember, Fuchsia is a microkernel, so a lot of the stuff that would be in the
kernel in a monolithic kernel _is_ in Rust here.

------
xvilka
> Rust is not supported for end-developers.

It's unclear where this restriction comes from. Also, it is quite sad to see
that they use and allow C for such a new and innovative project.

~~~
iainmerrick
I believe it just means they don’t intend to provide a standard toolchain and
SDK for Rust. That seems fairly reasonable given that Rust doesn’t have a
stable ABI ([https://github.com/rust-
lang/rfcs/issues/600](https://github.com/rust-lang/rfcs/issues/600)). Making
sure Rust apps are forward-compatible with new OS releases could be difficult.
In comparison, C has _the best_ ABI story and can easily be used to enable
other languages at the application level.

Apart from that, they seem positive about Rust and they’re willing to use it
for internal code. Note that they _discourage_ further use of C for internal
code.

I was a little surprised not to see slow compilation times listed as a con,
but I guess that’s a trade-off they’re explicitly willing to make for a kernel
that runs fast.

~~~
steveklabnik
Fuchsia exposes services via FIDL, so the lack of stable ABI isn't as big of a
deal.

------
swiley
What kind of OS has "approved langues?"

Geese, this is the sort of crap I'd expect from google but it's weird to see
it formally declared.

~~~
Gaelan
All of them. Linux has one: C.

For clarity, this is talking mostly about what languages they will use when
writing the OS itself (that’s what “approved” means in the article). They do
also touch on what languages are supported (I.e. they’re building the
infrastructure to allow it to happen) in userspace, but they’re not saying you
can’t run other code on the OS.

~~~
throwaway17_17
I don’t know that your take away is correct, I was under the same assumption
the these specific languages were for OS code, but from the article:

“ This document describes which programming languages the Fuchsia project uses
and supports for production software on the target device, both within the
Fuchsia Platform Source Tree and for end-developers building for Fuchsia
outside the Fuchsia Source Platform Tree. The policy does not apply to (a)
developer tooling, either on target or host devices, or (b) software on the
target device that is not executed in normal, end-user operation of the
device.”

This seems to say that software executed by end-users is only going to be
‘supported’. As was stated earlier in a comment, there is a difference between
‘allowed’ and ‘supported’, but I don’t understand why they are taking such a
general hard line about the support of it is just kernel specific.

I’m still going to maintain the assumption that the OS is only going to be
natively usable in the approved languages and that all others will require
individually maintained shim layers.

~~~
swetland
You're incorrect. This document is describing languages used to develop the
platform itself (and a bit about priority of external support for languages).
The Fuchsia platform was designed to be language agnostic, bring-your-own-
runtime _.

_ at least as of when I last worked on it, but it has been a core principle
from day one that I would be shocked to see abandoned.

------
madmax96
C:

>Programs written in the language often have security bugs arising from the
language’s lack of memory safety.

How often?

“Have things changed now?: an empirical study of bug characteristics in modern
open source software” suggests that 8.8-17.2% of security bugs are caused by
memory bugs. How many of these can be caught by better testing?

I think the effects of memory bugs on security are often overstated.

~~~
liamdiprose
> Speaking at the BlueHat security conference in Israel last week, Microsoft
> security engineer Matt Miller said that over the last 12 years, around 70
> percent of all Microsoft patches were fixes for memory safety bugs.

[https://www.zdnet.com/article/microsoft-70-percent-of-all-
se...](https://www.zdnet.com/article/microsoft-70-percent-of-all-security-
bugs-are-memory-safety-issues/)

~~~
madmax96
It seems like the Windows ecosystem hasn’t benefited from the improvements
made by the research community. For example, Valgrind doesn’t run on Windows.
Cross platform applications (like the ones studied in the referenced paper)
don’t have nearly the same level of memory problems. I think that presenting
the 70% figure as inherent to developing in C/C++ is misleading because of
this. In fact, a brand new project could probably reach 0 (or very close to
it) memory bugs in C++ by following modern testing practices and using the
variety of dynamic and static analyzers that exist today.

~~~
roca
Microsoft has lots of state-of-the-art dynamic and static analysis tooling for
Windows. You don't hear much about it because a lot of it is closed source.
E.g. here's some info about some of the static annotations they use in the
kernel: [https://docs.microsoft.com/en-us/windows-
hardware/drivers/de...](https://docs.microsoft.com/en-us/windows-
hardware/drivers/devtest/sal-2-annotations-for-windows-drivers) The links in
the sidebar point to a lot of other stuff. If you look at the publications of
MSR's software researchers, many of whom are very good, you will see lots of
papers about finding bugs in Windows, some of which have been productized.

> In fact, a brand new project could probably reach 0 (or very close to it)
> memory bugs in C++ by following modern testing practices and using the
> variety of dynamic and static analyzers that exist today.

A bold claim to offer without evidence. Unfortunately even the best
organizations have so far failed to achieve this.

~~~
madmax96
> Microsoft has lots of state-of-the-art dynamic and static analysis tooling
> for Windows.

Right. If you look at the linked article, the Microsoft Engineer claimed 70%
of security bugs in Microsoft products are caused by memory errors. Does
Microsoft apply the same tools to all their products or only Windows? Do these
tools even exist for other products?

> A bold claim to offer without evidence.

If one writes a new C++ program, tested with > 75% code coverage, tested with
valgrind, the program passed coverity checks and clang static analysis, and
they followed the best practices for hardening the host kernel, and told me
that they still had an exploitable memory bug, I would be surprised. Notice
that performing all those steps is still less effort than learning Rust and
building the program in that. And you’d still have to harden your kernel and
test anyway.

The evidence? NGINX and Linux is written in C. If the situation was so dire,
why isn’t every computer in the world compromised right this second?

~~~
dpbriggs
Look no further than the browser you're likely using: Google Chrome.

There's 91 code executions and 121 RCEs, details here:
[https://www.cvedetails.com/product/15031/Google-
Chrome.html?...](https://www.cvedetails.com/product/15031/Google-
Chrome.html?vendor_id=1224)

And the project has some of the best testing and practices in the world.
Constant fuzzing, significant test coverage [0], no doubt there's memory
sanitizers, etc.

It's increasing clear that large projects written in memory-unsafe languages
will contain memory unsafety.

> The evidence? NGINX and Linux is written in C. If the situation was so dire,
> why isn’t every computer in the world compromised right this second?

Nice hyperbole. Check the stats [1].

[0]
[https://analysis.chromium.org/p/chromium/coverage](https://analysis.chromium.org/p/chromium/coverage)

[1] [https://www.cvedetails.com/product/47/Linux-Linux-
Kernel.htm...](https://www.cvedetails.com/product/47/Linux-Linux-
Kernel.html?vendor_id=33)

~~~
madmax96
>Nice hyperbole

Not hyperbole. Most of these bugs are never known to be exploited by
attackers.

>Check the stats

In your first link, there was one memory corruption vulnerability in Chrome
last year. If we're looking at RCEs, CVE-2019-5762 and CVE-2019-5756 appear to
have the same root cause (a memory bug), and CVE-2018-6118, CVE-2018-6111, and
CVE-2017-15401 (which is also the memory corruption vulnerability) are also
memory bugs. So it looks like Chrome had ~4 serious memory vulnerabilities
last year.

Don't have time to dig right now, but it appears similar observations hold for
[1].

~~~
roca
> Most of these bugs are never known to be exploited by attackers.

You have moved the goalposts. Of course there are lots of reasons why a bug
might not be exploited by attackers, e.g. "the attackers exploited some other
bug" or "no-one uses that software". That is not reassuring.

> In your first link, there was one memory corruption vulnerability in Chrome
> last year.

I don't know how you determined that, but it's just wrong.
[https://www.cvedetails.com/vulnerability-
list/vendor_id-1224...](https://www.cvedetails.com/vulnerability-
list/vendor_id-1224/product_id-15031/year-2019/opec-1/Google-Chrome.html) Bugs
2, 3, 4, 8, 9, 10, 14 and 15 are obviously memory safety vulnerabilities. Many
of the others probably are too, if you dig into them.

~~~
madmax96
Or that the exploit is so difficult it is practically impossible to attack.

>but it’s just wrong

Who’s moving the goal posts now? The parent was talking about vulnerabilities,
not bugs.

~~~
roca
> Or that the exploit is so difficult it is practically impossible to attack.

"That bug is so difficult to exploit, it is practically impossible to use in
an attack" does not have a good track record in the face of determined and
ingenious attackers. Worse, once the attackers figure out how to overcome the
difficulties, that knowledge spreads and is often packaged into kits that make
it easier for the next bug.

> The parent was talking about vulnerabilities, not bugs.

I have no idea what you're talking about. Bugs 2, 3, 4, 8, 9, 10, 14 and 15 in
that list are serious memory safety vulnerabilities that were found in Chrome
last year, contrary to your assertion that Chrome only had four last year.

