Fuchsia Programming Language Policy
fuchsia.googlesource.com
fuchsia.googlesource.com
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.
They also had similar reasons, however lack of ISO standard and certified compilers also played a role.
https://www.adacore.com/webinars/securing-future-of-embedded...
Have you got a reference for that, it seems pretty damning if it's true.
> Con: The Fuchsia Platform Source Tree has had negative implementation experience using Go.
Decision
> Go is not approved, with the following exceptions: netstack ... In the fullness of time, we should migrate
> All other uses of Go in Fuchsia for production software on the target device must be migrated to an approved language.
> Con: The Fuchsia Platform Source Tree has had negative implementation experience using Go. The system components the Fuchsia project has built in Go have used more memory and kernel resources than their counterparts (or replacements) the Fuchsia project has built using C++ or Rust.
I wonder if they had other negative experiences beside the higher resource usage? Because it's hardly surprising that a garbage-collected language should have higher resource usage than C++/Rust. They could have still supported it for app development however - but it seems they took a "there can only be one" approach and went for Dart instead.
Also most likely why Android will never support Go officially.
That's more cost than benefit.
why?
Yes? In the next point they mention that pretty much all languages support the C ABI.
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.)
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...
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).
> does the src directory include any vendored software for the other languages? Or is that also only fuchsia code?
It doesn't contain vendored software. The third_party dir is responsible for that, at least for Rust and Go. The C libraries used are in separate repos I think.
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 UI is particularly useless at showing any kind of aggregate analysis.
It's the main repo but some components are outside. I presume that the UI apps are among those components.
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!
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.
> Be kind. Don't be snarky.
Your comment would have been quite helpful if you just removed the first line.
It's #23 in the current TIOBE index.
https://www.tiobe.com/tiobe-index/
It's a long, long way from being as widely used as the top 10 languages, but many people outside of Google are using it.
Since Dart is the language of Flutter, which is growing in popularity, it should substantially increase its user base in the years ahead.
Dart might be a bit of a kitchen sink language (what's it with Danes and operator overloading?), but you couldn't port over the minimalism of Go by addition, it would not be minimalism anymore.
Dart innovations like "collection if/for" syntax seem laughably trivial, but when you look at the examples for declarative UI it should become immediately clear that they reduce cognitive load a lot compared to the equivalent flatMaps or imperative state buildup. Those syntax goodies seem really nice in the scope Dart is made for, but I think that they would look seriously out of place in a more general purpose language.
I knew exactly how handy that was the first time I saw it.
Relevant XKCD: https://xkcd.com/927/
It's curious to argue that we should all be content with "universal" languages and stop developing new ones by citing TypeScript and Kotlin, two brand new languages created specifically to replace the already existing "universal" languages of JavaScript and Java.
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" ;)
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.
Would have assumed the Kernel would be where Rust truly shines, but that's where it's blocked, which is... interesting!
For an os project fully in rust and targeting end users, check out: https://www.redox-os.org/
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.
How is that not a stable ABI?
Because it's an ABI with several severe constraints, especially around the more OO features and templates, plus the solutions introduce even more abstractions: https://community.kde.org/Policies/Binary_Compatibility_Issu...
Most higher level languages (java, c#, python) handle most of those much better, albeit with a different set of trade offs. Things like adding a private field to a class won't break binary compatibility in a c# apllication. C++ is fairly unique in that it tries to be high level and tries to be low level but the cost is it pushes the complexity of this split personality onto the developers.
[1] I could see the committee standardizing some intermediate portable representation requiring installation time or even JITing in the future though.
You can say it's good enough (most of the time), but it isn't really a standard, unless I am mistaken.
> 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).
The standard library ABI it is not covered the the Itanum ABI (outside of some basic functionality), but it is defined necessarily by the platform. For linux that would be libstdc++.
The LSB references the Itanium ABI and defines libstdc++ as the ABI for the C++ standard library on linux platforms; it is again not an ISO standard, but it is as close as you can get on Linux.
And of course the C++ ABI being a very complex and both the ABI document itself and compilers have bugs from time to time, especially if you live close to the bleeding edge.
I don't think Rust, Dart, or Go are any better.
In practice it seems C++'s ABI is called "protocol buffers".
https://fuchsia.googlesource.com/fuchsia/+/master/docs/devel...
There is a stable ABI inside some OSes, moreso than any wannabe C++ replacements.
Speaking of which, Rust is a very nice language, but still lacks many productive tooling that systems developers came to expect.
If anything this rationale is great input for the Rust community, how to improve the ecosystem.
It was checked into git yesterday.
Even with this relative improvement, though, I question if it's enough to overcome the shorter compile and test loop the other languages have, or the mental overhead of managing lifetimes and ownership.
“ Rust is not supported for end-developers.
Rust is approved for use throughout the Fuchsia Platform Source Tree, with the following exceptions: kernel. The Zircon kernel is built using a restricted set of technologies that have established industry track records of being used in production operating systems.”
That’s better than Go, which is not supported.
Likewise a future Fuchsia Studio won't support templates, debugging, or OS libraries written in Rust.
And the Fuchsia team most likely won't prioritize toolchain bugs related to Rust.
This is the biggest difference between using an official SDK language and guest languages.
Calling it the "majority" or "doing the best" is probably coming off as disingenuously impling "most significant". Sloc dosn't meet anyone's idea of that.
Being pretty conservative overall but betting the house on Dart for the UI seems like a strange combination of decisions to me.
If Johnny doesn't like JVM languages, or C++, all they get is a bare bones C API, which requires JNI even for opening files, asking for permissions and so forth.
You don’t get Flutter without Dart. Anyone that’s ever looked at what is behind any Flutter component can see the Dart code building it.
You literally can not bet on Flutter and not Dart. Don’t confuse Flutter as some DeclarativeUI of its own.
EDIT: How we that’s not to say the cart can’t lead the horse (good analogy). Flutter requirements are definitely driving changes in Dart Lang.
Flutter demonstrates Dart is a good choice; it gives you a successful declarative UI framework that effectively builds on Dart as a fairly straightforward upgrade of the most tried and true UI scripting language ever made: Javascript.
To answer the GP comment, betting the house on Dart for the UI doesn't seem like a strange or risky decision in that light.
Yea. Before using Flutter, I probably wouldn’t have agreed. After using, I can’t disagree at all.
It still seems incongruous that widespread usage is portrayed as an important criterion for Fuschia PLs, but they bet big on Flutter which forces them to adopt Dart, a language which has very little uptake outside Flutter.
Rust, on the other hand, is treading new ground with the unusual core concept of a borrow checker.
And still the decision on Rust reads very much like a "we'd love to extend the scope of the time is right" whereas the dismissal of Go is surprisingly brutal, almost reads as if there was a cold civil war going on between the two garbage collected Google languages and Fuchsia people feel need to to demonstrate loyalty to their Darters. Might even just mirror an equal dismissal regarding server side Dart.
That'd be my guess. Given the nature of Flutter and its co-development with Dart it's not surprising that Fuchsia prioritizes it. After all, you need to implement the UI in something. Meanwhile I have literally never heard of a UI implemented in Go, and outside of the UI I can see why they don't want to use garbage collected languages in their OS.
I expect it has the same issue as UI in Rust: UI is one of the domain where OO inheritance is most convenient and most deeply embedded. So langages which don’t do inheritance are hard sells.
Newer “declarative” UI frameworks less so but they’re probably not mature enough conceptually that you’d want to bet your OS’s core UI system on them, right now they’d be used as an overlay on the core stateful UI system (see bodil’s vgtk for example).
This seems like an exaggeration. Maybe Fuchsia will turn out to be important, maybe it won't. As of right now, it's another Google vanity project that makes them no money.
It could turn out to be enormously strategically important by allowing Google to drive a stake through the heart of Linux on consumer devices...or just as easily get killed tomorrow.
Adoption and community are one of our top factors. It's a pretty serious one, IMHO.
EDIT: our as in our company. Not in any way affiliated to Fuchsia.
Do you mean legitimate, instead of serious? The issue you point out sounds more like technical debt and verification/specification rather than something that can’t or won’t be overcome.
I would say, that as debt goes, this seems like something not egregious, but I can understand not wanting to take it on. But, with every passing year and no significant flaws having been discovered (I mean language destroying not some of the unsoundness bugs that exist), empirical evidence is getting stronger and stronger that Rust has an excellent model.
This means that while the overall project is used outside of Fuchsia, google is contributing upstream patches, to many of those projects specifically to support Fuchsia. At that point it’s not a clean separation of what’s “in house” vs. not.
Con: None of our current end-developers use Rust.
And not enough people are using it is devastating critique of a language - every piece of code written will be read by someone eventually. And you want that pool to be as big as possible.
To me it seems Google are cautiously bullish on Rust.
My worry comes from the fact that a computer system of the scale of Fuchsia comes up every couple decades. I'd like not waste another one on C++ shortcomings and Fuchsia going with Rust was a great chance for a better dominant language in 20ties.
Developers seem to like Rust (or at least pay lip service). It's understandable. We are all suckers for a golden hammer. Rust promises no data races, no dangling pointers, high performance, and best of all it can run on numerous targets, making it a contender for The Last Language you have to know.
But you don't judge a restaurant's performance by the holiness of the chef's choice of tools in the eyes of other chefs. What is the most profitable piece of Rust software or the piece of Rust software that the most people depend on? If it wants to be taken seriously at the systems programming table, then we should see the Unix coreutils written in Rust (with all the command line flags working exactly the same way). Come on, replace GNU. You say you can do it faster and safer than everyone else. Let's see it.
Perhaps you and I have very different definitions of "a lot" or of "good", because I don't agree with this at all. There are plenty of high profile Rust projects with excellent production track records. Linkerd, TiKV, and Firecracker (originally crosvm) come to mind immediately, and of course Servo. Facebook also selected it for Libra, Google for Fuchsia.
Literally all of the things you mentioned (except linkerd which is mostly Go) are half-finished incubator projects. Rust has been around for over 10 years. Come on.
https://github.com/linkerd/linkerd2 https://github.com/linkerd/linkerd
It's confounding how a project that doesn't include Rust is included in Rust's "Greatest Hits."
Citing a cryptocurrency that...for all intents and purposes, doesn't really exist right now, is also a strange choice.
> Today, Lambda processes trillions of executions for hundreds of thousands of active customers every month. Last year we extended the benefits of serverless to containers with the launch of AWS Fargate, which now runs tens of millions of containers for AWS customers every week.
> Battle-Tested – Firecracker has been battled-tested and is already powering multiple high-volume AWS services including AWS Lambda and AWS Fargate.
That doesn't sound like a half-finished incubator project.
I'm not blind. I can see that Rust has its major downsides, and the zealotry you see is on HN and elsewhere is downright annoying. But dismissing it based on age is being disingenuous. There was another list of projects elsewhere in this comment thread which listed a number of things being used in production that can't be considered half-finished by any measure.
While I'm not convinced that implementing an identical API to coreutils is necessary to be "taken seriously" as a systems programming language, there's a fairly far along implemention that already exists:
You've got:
* Every page load of Firefox
* Every page served of Reddit
* Every byte stored in dropbox
* Every user of 1password's browser extension, and every user of their Windows client.
* Every HTTP/3 request served through Cloudflare (okay HTTP/3 is still a baby but, the future here)
* Every DNS request of every user of the 1.1.1.1 mobile app (hundreds of thousands of installs)
* Every invocation of AWS Lambda and Fargate
* 4% of Debian packages
* Every control-F in Visual Studio: Code
* Every time a user list changes in Discord, also other things.
... so, yeah. Take your pick.
Find in project is really awesome in VSCode.
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.
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.
Rather obviously, people who implement OSes are usually the opposite.
1 - give programmers access to powerful jedi tricks, but make those just annoying enough that novices aren't terribly tempted to build them and put them into prod (but not so annoying that they aren't tempted to play around with them not-in-prod and learn something about the runtime)
2 - make "doing the right thing" easy, like, tests, documentation, sane package management, cryptographic primitives, comments, tests, etc, also, did I mention tests? Tests should be easy and you should want to write them.
3 - Make tests blazingly fast and parallelizable. That means, you can write two (or more) tests that hit the database (or some other source of state) and it doesn't matter that they are operating on different views of the universe, they shouldn't collide.
4 - be opinionated about deployment, so that those rube goldberg tricks you have to do to put into prod are testable and reproducible.
I must be using go wrong then because I've always felt they were easy and wanted to write them. The last big project I built with it had great test coverage.
> be opinionated about deployment, so that those rube goldberg tricks you have to do to put into prod are testable and reproducible.
Of all the languages I feel like go's deployment is probably the simplest, if it's hard for you you're probably doing something pretty wacky.
100% agree with this. Statically compiled binary is basically the easiest thing to deploy.
We let the AWS autoscaler health monitoring just kill unhealthy ec2 instances. No need to worry about any sort of restart policy. It is VERY rare we actually get a Go process in an unhealthy state.
We’ve always handled banning in app, so that’s never been a consideration. Our rules around that are very complicated as we sell into institutions that have thousands of people behind a single IP address, so blocking a full IP incorrectly could mean institution wide downtime and possible loss of a client.
Our secrets get set with a little come-online script in the ec2 image. Secrets change? Kill the instances and autoscale more. Instrumentation is via REST api.
It’s basically the same way we deploy anything else but without worrying about library and language versions. Its reasonably simple, and been very easy especially compared to the previous ways we used to deploy apps.
People coming from language like C++ and senior enough to write OSes may be startled how inexpressive Go is.
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.
Where does he say "users of this language are stupid".
I think this is a big one, even though they listed this for Go I'm curious if they actually believe it. I certainly don't.
For Dart they're potentially a significant stakeholder, for Go though I can't imagine them getting any significant changes through that don't benefit server side programming at Google.
I like Go, but Dart has been a pretty good language to learn.
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.)
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.
I'd start here if you want to learn more: https://sel4.systems/Info/FAQ/proof.pml
Let me know if you have any other questions.
The fact that you don't have to write C and also that you can have different API semantics. E.g. you can pass user space code (say callbacks) to the kernel while maintaining safety.
I guess the embedded version of this would have to be an offline compiler & code signing based system, and the language would need to be much more sandboxy than Rust.
Unless you mean more like using the user callback in the same way, say, a posix signal handler works, or Microsoft's SEH or APCs, then I would say it's already possible with a C ABI, citing those things as examples.
https://www.sigops.org/s/conferences/sosp/2009/papers/klein-...
The day is only 25 hours, or maybe even less.
Frankly - who didn't see this coming. The widely touted network stack written in Go will be rewritten in something else.
> Nobody seem to want to stand out and use e.g. Rust in the kernel, so the situation is perpetuated
Redox does, but it's still early days there apparently. I tried to boot it in VirtualBox a few minutes ago, following some instructions on StackExchange[1] but it didn't boot.
> How old was C again when it was used to write the Unix kernel?
Very young, as C was developed between 72-73[2], and the first rewrite of UNIX in C from PDP assembly happened in 1973 for V4, although it wasn't really _portably_ rewritten until 1978[3]). The C rewrite was the first version to support multi-programming; before that it was single-tasking.
(maybe you know all this, but I post the info to clarify for other readers who might not, and to underscore your point).
Also don't forget that UNIX source was reasonably available in those days, and both C and UNIX developed alongside the much simpler hardware of the day, and evolved with them. Hitting modern hardware targets, trying to provide modern OS features out of the gate, and using a newly emerging language seems to be a feat which is an order of magnitude larger IMHO.
[1] https://unix.stackexchange.com/questions/463192/install-redo...
Worth giving it another go. I've been playing around with it in QEMU lately, and it even booted on my laptop (but I had no working input since it seems USB HID isn't implemented). It's an impressive project.
I wonder if Rust/Elixir will be the one to eventually replace it.
Not to mention compile times are still much longer than what they were pre-1.5 when the compiler was written in C.
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).
Edit: here: https://news.ycombinator.com/item?id=22008887 but I think it's not official.
It was very much a pro for our users; like any open source project, we need contributors who are willing to help do the work. Fuchsia's experience with async/await was really important to validate that the design worked well; for example, many people think of it as a feature that's useful for web servers only, but Fuchsia demonstrated its validity in other contexts. Beyond semantics, it also helped with syntax; https://github.com/inejge/await-syntax was created during the debate about "prefix await," and was able to show us what a few variants of the syntax would look like in real-world code.
> 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).
C has a standards process that anyone can get involved in, following ISO rules. Google is a major player in the C++ standards process too.
Perhaps it was the wording that made me think that way... "To influence". I would rather prefer as you wrote; to collaborate or to contribute.
Time will tell...
“Supported”, however, is a different word than “allowed”.
As far as I can tell, this is supposed to be “the” languages that can execute on a Fuschia-powered device.
FTA: "Supported for end-developers means that the Fuchsia SDK contains tools and libraries that help people use the language to develop software for Fuchsia, including a language-specific backend (and supporting libraries) for FIDL. Support also implies some level of documentation, including tutorials and examples, as well as investment from developer relations."
> Go is not approved, with the following exceptions:
>>>> netstack. Migrating netstack to another language would require a significant investment. In the fullness of time, we should migrate netstack to an approved language.
> All other uses of Go in Fuchsia for production software on the target device must be migrated to an approved language.
Does that not imply that okay sure use whatever language you want, but production software (that exists in repositories?) must adhere to approved languages?
I could be misreading
> I could be misreading
To me, that reads: platform devs, i.e. people developing Fuchsia itself, must adhere to the approved language list. Which is not uncommon in projects of all sizes from small to large.
I think the wording is a bit weird because Google is expecting 3rd party device manufacturers to make modifications to the OS and expects them to adhere to the approved language list as well.
Edit: had I read the quote from a comment not far below before posting, I would not have made these assumptions. That quote does sound like applications will be language restricted.
> I could be misreading
That’s for “production software” (as opposed to tooling I’d guess) in / of Fuschia itself. They’re saying that aside from netstack & stuff that only runs on the dev machines everything that’s in Go in the Fuschia repository must be migrated ASAP to an approved langage.
For end-developers it’s the same status as eg Rust: you’ll be on your own with no support from the fuschia project.
Fuchsia, as a fundamental principle, supports "bring your own runtime" -- if you are a PIE ELF executable and can dynamically link against libzircon.so (the syscall ABI) and speak the platform's RPC protocols, you are a Fuchsia app.
The Fuchsia IDL compiler is designed to support third party backends for other languages beyond the core platform languages.
I've moved on to other things, but I'd be very surprised to learn this had changed.
Only in part; they also specifically mention whether or not they will support use of each language by end-developers. (As you say, end-developers can use whatever they want, as long as their language has a C-ABI FFI, but that's not the same as being "supported".)
As far as "using it in a substantial portion of their product", dunno.
https://gist.github.com/brson/9422a92791062ac52d9e08f0ba7d48...
Sorry it's not more organized and detailed.
[0] https://dtmf.io/
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.
> Pro: People using the language are highly productive.
Ok you convinced me.
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.
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.
Is this is still the official position?
Dart is a lovely language and with Flutter you can target any OS/device.
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...
and then:
> Decision: 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.
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.
And there's no telling about the future; the Fuchsia team is certainly allowed to change their minds later and add supported SDKs.
Geese, this is the sort of crap I'd expect from google but it's weird to see it formally declared.
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.
Sure the individual components pick a language but there's no singular language applications are "supported" for (except libraries like GTK which you don't really need), that's how we get nice things like TCL/TK and guile.
“ 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.
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.
Support for end-developers means provision for built-in API and affordances. They won’t stop you from using something else for your Fuschia applications but you should not expect much if any help in getting it working or whatnot.
I imagine that an end-developer could write their Fuchsia program in any language they want, but if it's not on this list, Google won't provide documentation or bindings for it.
I'll trade my laptop for an abacus before I trade it for a pixel.
>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.
How often?
https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
https://www.youtube.com/playlist?list=PLbzoR-pLrL6rF8E5yyknJ...
Plenty of tasty material how Linux ecosystem has benefited from the improvements made by the research community.
> 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.
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?
There's 91 code executions and 121 RCEs, details here: https://www.cvedetails.com/product/15031/Google-Chrome.html?...
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
[1] https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
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].
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... 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.
>but it’s just wrong
Who’s moving the goal posts now? The parent was talking about vulnerabilities, not bugs.
"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.
They recently released an AddressSanitizer port for MSVC, and they've had Valgrind-like functionality for Windows userspace for over a decade (see https://www.usenix.org/legacy/events/vee06/full_papers/p154-...), but I don't know of any public source describing what tools they use across their product range, so I don't know. They're well resourced, well motivated, and not stupid, so it would be surprising if they don't use the technology available.
I know that highly capable organizations, e.g. the Chrome and Firefox teams, do use state-of-the-art tools and practices in their browsers and get similar results to the Microsoft 70% number.
> I would be surprised
Check out Firefox and Chrome, for example, and be surprised.
> learning Rust
This isn't about Rust, but FWIW learning Rust doesn't seem so bad when you compare it to just the learning required to keep up with the ever-growing complexity of C++. (See e.g. Scott Meyers refusing to handle errata for his books because his C++ knowledge is obsolete after a few years out of the game.) Not to mention learning how to use and deploy in CI all the static and dynamic analysis tools you need to keep your C++ code safe(-ish).
> NGINX and Linux is written in C
nginx is better than most but had a serious memory safety vulnerability reported as recently as 2018: http://mailman.nginx.org/pipermail/nginx-announce/2018/00022.... The Linux kernel, of course, has lots.
> If the situation was so dire, why isn’t every computer in the world compromised right this second?
Exploitation mitigations, patching, and ecosystem effects. But the situation is pretty dire.
Unfortunately, the threads grown too long and it’s starting to get difficult tracking referenced and arguments. The paper “Have things changed now? An empirical study of bug characteristics in modern open source software” specifically studies Firefox and finds no where near the 70% number (18%).
As a former Mozilla distinguished engineer (left Mozilla in 2016), I assure you memory safety bugs are the majority of exploitable Firefox security bugs.
I also think that a percentage is a weak indicator in general. With bug bounties we're seeing a massive influx of vulnerability reports for exposed APIs - this is almost always XSS and CSRF. I am not discounting the impact of those vulns, only saying that percentages are very market driven.