Fuchsia Programming Language Policy

Very interesting to see a technology focused analysis of what Google thinks about the strengths and weaknesses of the different languages are.<p>Usually analysis&#x27;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.<p>From this analysis C++ and Dart are given the green light, Dart for high-level code as &quot;Asynchronous programs can be written using straight-line code and People using the language are highly productive.&quot; but because of its GC and substantial runtime environment it&#x27;s &quot;more resource intensive&quot; and not ideal for programs that run indefinitely.<p>The comparisons between Google&#x27;s designed and controlled &quot;Go&quot; vs Mozilla&#x27;s sponsored &quot;Rust&quot; 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&#x27;s been blacklisted with all code except netstack needing to be migrated to an approved language.<p>The biggest con of Rust seems to be that it&#x27;s still new, not widely used and its unique properties haven&#x27;t been time tested enough yet, but as it&#x27;s still approved as it&#x27;s more performant and requires less resources than Go.

This policy hasn&#x27;t changed in over a year. I&#x27;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&#x27;ve collaborated on).<p>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&#x27;t officially support our platform, it kind of doesn&#x27;t make sense to support that language. And there&#x27;s no commitment to support these languages for production services and end user development until there&#x27;s a story for the stability of that toolchain on Fuchsia.<p>This shouldn&#x27;t be surprising. Make a new system, bootstrap your programming environments. Why bother offering support for environments you&#x27;ve not yet bootstrapped?<p>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&#x27;re supported.<p>(Edit: I accidentally a word.)

For the distribution of languages inside fuchsia, this is the output of &quot;tokei -s lines&quot; in the git checkout of fuchsia: <a href="https:&#x2F;&#x2F;gist.githubusercontent.com&#x2F;est31&#x2F;5c13979043e760a597a019999d5602de&#x2F;raw&#x2F;acd8458ab45ebac186dc1a0e700985fb68d663db&#x2F;gistfile1.txt" rel="nofollow">https:&#x2F;&#x2F;gist.githubusercontent.com&#x2F;est31&#x2F;5c13979043e760a597a...</a><p>According to this, Rust is the language with the most lines in fuchsia. It&#x27;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.<p>This is the tokei output of the src directory: <a href="https:&#x2F;&#x2F;gist.githubusercontent.com&#x2F;est31&#x2F;5c13979043e760a597a019999d5602de&#x2F;raw&#x2F;5e770560cb9dbdfa6e5d95d7bb741334f29e7aff&#x2F;gistfile2.txt" rel="nofollow">https:&#x2F;&#x2F;gist.githubusercontent.com&#x2F;est31&#x2F;5c13979043e760a597a...</a><p>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).

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.

&gt; 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.<p>Probably makes sense, not what Go was designed for, but I really don&#x27;t get big-G&#x27;s choice of &quot;one different language for each niche&quot;...<p>I mean, ffs, Go <i>and</i> Dart are both garbage-collected and compiled, even their lists of pros and cons look similar. Couldn&#x27;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? <i>Why don&#x27;t people see the advantage of &quot;universal&quot; languages? It&#x27;s obvious that developer love them and they are empowered by them, hence the success of languages like Javascript&#x2F;Typescript and Kotlin despite their obvious flaws and limitations!</i>

&gt; ...and supports for production software on the target device<p>Assuming I understand this right... why should an operation system limit the programming language used for creating applications in at all? That&#x27;s a bad trend to follow which unfortunately seems to be quite common on more recent platforms.<p>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&#x27;t any language work which can call into C APIs (which is nearly every programming language on the planet).<p>E.g. even if the OS doesn&#x27;t &quot;officially&quot; offer Go bindings, why should a third-party not be able to come up with Go bindings via the C-APIs? Also &quot;Con: The toolchain produces large binaries.&quot; is laughable, because from the POV of a C programmer, <i>everything</i> else out there produces &quot;large binaries&quot; ;)

Interesting that the only con listed for Rust is <i>Not enough people are using it</i>, compared to the serious criticisms of the others.

Seems like Go has more positives and the same negatives as Dart, but Dart is approved while Go is being scrapped in Fuchsia land.<p>Having said that, I wouldn&#x27;t want to work on GUI applications with Go, while Dart did have some handy semantics when I tried it.<p>A rather low level of detail in this comparison though, would have liked something a little more in depth.

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.<p>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&#x27;s stakes here are higher.)

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.”<p>I wonder if Rust&#x2F;Elixir will be the one to eventually replace it.

&gt; Pro: The Fuchsia project has the opportunity to influence the evolution of the language. (RUST)<p>While this may be a <i>Pro</i> for Google, is it also a <i>Pro</i> for the users? Does this mean that Google would hold (if not already) a chair in some &quot;foundation&quot; and decide which features goes into the language (and how they will be implemented)?<p>If this is the case, I don&#x27;t like it very much... That would be a <i>Pro</i> for C, or whatever language out of their reach (as in The Fuchsia project <i>doesn&#x27;t</i> have the opportunity to influence the evolution of the language).

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&#x2F;Rust&#x2F;Lisp&#x2F;whatever? Just provide a sandbox and a platform spec and allow third parties to build whatever tools&#x2F;languages make sense.

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&#x27;s problems.

Are there any major products&#x2F;services where Rust is being used besides Firefox right now?

Lets wait until they actually have devices and OEMs lined up, which may very well be never. I can&#x27;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.<p>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.<p>I don&#x27;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&#x27;ve heard the arguments why all this is not possible on multiple occasions from flutter fan boys. IMHO that&#x27;s a problem that needs fixing and not an inherent design limitation. It&#x27;s a prioritization problem. It boils down to Google being stubborn and arrogant. It boils down to not invented here syndrome.

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.

For Dart:<p>&gt; Pro: People using the language are highly productive.<p>Ok you convinced me.

The interesting bit is at the end : they really don&#x27;t like Go, a language that was developed at the same company.

IIRC last official news I heard from Fuchsia is that it was an experiment to test OS features.<p>Is this is still the official position?

Basically... Dart and C++ only?

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

Is this doc no longer valid? <a href="https:&#x2F;&#x2F;fuchsia.dev&#x2F;fuchsia-src&#x2F;development&#x2F;languages&#x2F;new" rel="nofollow">https:&#x2F;&#x2F;fuchsia.dev&#x2F;fuchsia-src&#x2F;development&#x2F;languages&#x2F;new</a><p>It&#x27;s worth noting the distinction between the <i>Fuchsia API Surface</i> (consumed by End-developers) and the <i>Fuchsia System Interface</i> here: <a href="https:&#x2F;&#x2F;fuchsia.dev&#x2F;fuchsia-src&#x2F;concepts&#x2F;api&#x2F;council#definitions" rel="nofollow">https:&#x2F;&#x2F;fuchsia.dev&#x2F;fuchsia-src&#x2F;concepts&#x2F;api&#x2F;council#definit...</a>

&gt; Con: Rust is not a widely used language.<p>and then:<p>&gt; Decision: Rust is not supported for end-developers.

I cant help but think that &quot;highly productive&quot; here is not really a super scrutinised reason.

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

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

&gt; Rust is not supported for end-developers.<p>It&#x27;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.

What kind of OS has &quot;approved langues?&quot;<p>Geese, this is the sort of crap I&#x27;d expect from google but it&#x27;s weird to see it formally declared.

C:<p>&gt;Programs written in the language often have security bugs arising from the language’s lack of memory safety.<p>How often?<p>“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?<p>I think the effects of memory bugs on security are often overstated.