17 ms·

Fuchsia Programming Language Policy

308 points by farmerbb 7y ago

aphextron 7y ago
Interesting that the only con listed for Rust is Not enough people are using it, compared to the serious criticisms of the others.
- sk0g 7y ago
  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!
  - kvark 7y ago
    Good to know! I'll look for an OS written in Rust elsewhere then. Fuchsia is interesting, but could be much more so.
    - bluejekyll 7y ago
      If you want to learn to write an OS in Rust, checkout this series: https://os.phil-opp.com/ https://os.phil-opp.com/ For an os project fully in rust and targeting end users, check out: https://www.redox-os.org/ https://www.redox-os.org/
  - monocasa 7y ago
    Given that they already have a microkernel written in C++ (zircon is derived from littlekernel), and they're trying to move as much as possible outside the kernel, it makes sense that (for the time being) adding a new kernel language isn't on the table.
  - bsder 7y ago
    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.
    - monocasa 7y ago
      They don't want to add loadable kernel modules (but instead go pretty strict microkernel), so what would an unstable FFI/ABI really matter?
      - lmm 7y ago
        It's much easier to progressively migrate away from a language if you have a stable ABI.
        monocasa 7y ago
        The goal is to get it to the size where it can be replaced all at once. For instance sel4 is only 10kloc.
    - jcranmer 7y ago
      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?
      - flukus 7y ago
        > 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_Issues_With_C%2B%2B https://community.kde.org/Policies/Binary_Compatibility_Issu...
  - anp 7y ago
    Rust binary size can be pretty painful, depending on what you're doing. Also, it doesn't look like that document is receiving regular updates, so grain of salt and all.
    - est31 7y ago
      > it doesn't look like that document is receiving regular updates It was checked into git yesterday.
  - hu3 7y ago
    It's worth noting that Go and Dart were characterized as "highly productive" whilst Rust wasn't.
    - ShinTakuya 7y ago
      Absolutely, I don't think any sane Rust zealot would argue that Rust can compete with Go/Dart productivity. The argument can be made that Rust code has a lower maintenance cost over time, though, and that productivity may not drop as much as the system becomes more complex. 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.
- melling 7y ago
  Rust sounded like it was close: “ 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.
  - foota 7y ago
    That's probably in part demand driven? I.e., there's little need for rust to be supported officially for end users.
    - dodobirdlord 7y ago
      Moreover, C is supported for end users, and if C is supported then Rust is de facto supported though C bindings, which Rust understands natively.
      - pjmlp 7y ago
        Someone will have the fun of writing those wrappers, because Google won't do it. 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.
        zozbot234 7y ago
        Rust doesn't have a stable ABI, so it's sensible to always go through C bindings anyway. The other things you mention are just a matter of what their future Fuchsia Studio chooses to support.
  - ztjio 7y ago
    The majority of the code in the project is already written in Rust. If we're judging Rust based on its acceptance in Fuchsia for some weird reason, it's doing very well. Doing the best, in fact.
- brianpgordon 7y ago
  That doesn't seem like a non-serious criticism to me. They're trying to build something huge that's of immense strategic importance looking forward potentially decades. It seems appropriate to adopt the utmost caution about incorporating a language that's promising but for which widespread traction might not materialize as expected. Though to be fair, the same (and more) might be said of Dart...
  - ollien 7y ago
    Yeah, but when something is built in-house like Dart is, I imagine there's some level of support the Fuchsia team will get.
    - roca 7y ago
      The world of paid Rust language contributors is so small that Google could easily get all the advantages of "built in-house" for Rust if they spent a relatively tiny amount of money. Being pretty conservative overall but betting the house on Dart for the UI seems like a strange combination of decisions to me.
      - toastal 7y ago
        Is there a conspiratorial side of Mozilla vs Google in this Rust vs Dart story?
        usrusr 7y ago
        The languages are as different as Python and C++, I honestly don't really see a Rust vs Dart story. Note that Rust is approved for use within much of the source tree, but outside it is only not supported. Johnny end-developer, whoever that is, could still use Rust if he insisted, coding against C bindings.
        pjmlp 7y ago
        Just like it happens in Android. 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.
- bassman9000 7y ago
  compared to the serious criticisms of the others 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.
- badsectoracula 7y ago
  The reasoning does sound serious: "The properties of the language are not yet well-understood, having selected an unusual language design point (e.g., borrow checker) and having existed only for a relatively short period of time". It isn't just "it isn't popular thus it is not good" but "it does something weird that no other language does and because few people use it, we haven't yet figured out what potential issues that weird part may have".
  - bluejekyll 7y ago
    > does sound serious 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.
    - badsectoracula 7y ago
      Yes i meant legitimate, though i'm not sure why you say that it sounds like technical debt. I'd say it is the opposite - trying to avoid technical debt that could happen by betting on something unknown and instead staying on the safe side.
      - bluejekyll 7y ago
        I meant technical debt for the Rust project, not for fuchsia. I don’t disagree, Fuchsia would end up incurring this debt in the kernel too. 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.
  - mirekrusin 7y ago
    After having 2.2 million lines of code in rust in their project they should know a bit better imho; that's more than any other language they use; with go they knew quite quickly it's not good for them.
- ReptileMan 7y ago
  Sorry, but that was not the only con. The other were that the design was unusual and it is not yet understood. 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.
  - zbraniecki 7y ago
    I agree with your summary. 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.
    - _-___________-_ 7y ago
      The microkernel is a pretty small component. It's like if 80% of the Linux kernel was Rust and 20% was C++.
- EamonnMR 7y ago
  Notice that they omitted the "highly productive" claim thy applied to Dart and Go.
- zelly 7y ago
  There isn't a lot of good software written in Rust, open source or not. It's a lot of small and half-finished stuff here and there. The actual software out there is the ultimate, unforgiving, unfraudable review of a language, not what people say. 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.
  - dodobirdlord 7y ago
    > There isn't a lot of good software written in Rust, open source or not. It's a lot of small and half-finished stuff here and there. 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.
    - zelly 7y ago
      > half-finished 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.
      - kick 7y ago
        There is literally no Rust in the main repo: https://github.com/linkerd/linkerd2 https://github.com/linkerd/linkerd2 https://github.com/linkerd/linkerd 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.
sk0g 7y ago
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 7y ago
  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.
  - nine_k 7y ago
    Not "stupid" but "inexperienced". Rather obviously, people who implement OSes are usually the opposite.
  - throwaway894345 7y ago
    You might not agree, but the idea is that you should devote your cognitive resources to the problem you’re solving and not working around complexities in your language (such that brilliant developers such as yourself and “stupid” developers like me can be even more productive than we would be with C++ or Haskell or whathaveyou) or choosing stylistic standards for how contributors are to program (because the language is so expressive that the solution space is astronomical). “Go programmers are stupid” is a deliberately uncharitable interpretation.
    - dnautics 7y ago
      You might not agree, but there are programming languages that, unlike Go, don't take a "programmers are stupid" opinion, that are incredibly productive. Here are some other ways you can make developers productive (just off the top of my head): 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.
anthm1988 7y ago
What's the fucking point of developing a language like rust if people like this are too cowardly to use it.
nine_k 7y ago
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 7y ago
  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 7y ago
    Neat, I didn't know about seL4. Can you point me to how they define the proof for it?
    - monocasa 7y ago
      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.
    - reirob 7y ago
      FOSDEM speach video [1] about the status of seL4, I really enjoyed. [1]: https://fosdem.org/2020/schedule/event/uk_sel4/ https://fosdem.org/2020/schedule/event/uk_sel4/
  - adamnemecek 7y ago
madmax96 7y ago
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.
- beart 7y ago
  If I could eliminate 17% of the bugs in a future code base by choosing to use a different language, I would need a strong reason not to.
  - madmax96 7y ago
    The strong reason is given in the linked article. C is better supported, more stable, has more developers, and is better understood. Meanwhile many of these bugs could be caught by testing, which you should be doing anyway. You can also survive the effects of the bugs with other tools like stackguard with extremely low overhead, while still having the vast benefits of C described in the original article.
    - pjmlp 7y ago
      We have been hearing that matra for 40 years now, thankfully companies are finally getting wiser.
- tomesco 7y ago
  >I think the effects of memory bugs on security are often overstated. How often?
- liamdiprose 7y ago
  > 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-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
lawrenceyan 7y ago
Are there any major products/services where Rust is being used besides Firefox right now?
- clSTophEjUdRanu 7y ago
  The Mullvad VPN app is written in Rust.
- ehsankia 7y ago
  I know Discord is migrating a lot of their stuff from Go to Rust. Not sure how major you consider Discord.
- Groxx 7y ago
  Some: https://www.jonathanturner.org/2018/07/snapshot-of-rust-popularity.html#rusts-commercial-users https://www.jonathanturner.org/2018/07/snapshot-of-rust-popu... As far as "using it in a substantial portion of their product", dunno.
- PudgePacket 7y ago
  just a sample: dropbox, cloudflare, canonical, sentry, atlassian, npm, ibm, xero https://www.rust-lang.org/production https://www.rust-lang.org/production https://www.rust-lang.org/production/users https://www.rust-lang.org/production/users
- brson 7y ago
  There are. Here is a copy of my notes on the subject: https://gist.github.com/brson/9422a92791062ac52d9e08f0ba7d48cf https://gist.github.com/brson/9422a92791062ac52d9e08f0ba7d48... Sorry it's not more organized and detailed.
  - steveklabnik 7y ago
    Another recent big user is 1password, both on the Windows desktop and in the browser with wasm. Great notes!
- kgersen 7y ago
fiddlerwoaroof 7y ago
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 7y ago
  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 7y ago
    > 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.
    - terminaljunkid 7y ago
      Support means all APIs have first class support by Google, just like how Kotlin has first class support on Android.
    - _-___________-_ 7y ago
      They have no means to enforce that. They're talking about what they provide support for, not what is possible.
      - fiddlerwoaroof 7y ago
        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.
swiley 7y ago
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.
- franciscop 7y ago
  All of the current mobile OS. I also prefer seeing it formalized than hidden.
  - swiley 7y ago
    Those are models now?? I'll trade my laptop for an abacus before I trade it for a pixel.
- Gaelan 7y ago
  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.
  - swiley 7y ago
    A lot of Linux OSes define protocols and interfaces with matching implementations. The kernel has syscalls, the GUI has a socket protocol etc. 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.
    - anthk 7y ago
      In Unix, C is THE API.
  - throwaway17_17 7y ago
    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.
maximilianroos 7y ago
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.
est31 7y ago
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/5c13979043e760a597a019999d5602de/raw/acd8458ab45ebac186dc1a0e700985fb68d663db/gistfile1.txt https://gist.githubusercontent.com/est31/5c13979043e760a597a... 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/5c13979043e760a597a019999d5602de/raw/5e770560cb9dbdfa6e5d95d7bb741334f29e7aff/gistfile2.txt 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).
- bluejekyll 7y ago
  does the src directory include any vendored software for the other languages? Or is that also only fuchsia code?
  - est31 7y ago
    Could you clarify your question? The fuchsia subdir contains various user space components of the OS, like a network stack, bluetooth, graphics drivers, etc. Also some tools and test code. Rust is used in most of the components I looked at.
    - bluejekyll 7y ago
      Edited my comment. Didn’t notice that vendored got spelling corrected to censored :(
      - 7y ago
scoutt 7y ago
> 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 7y ago
  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.
  - scoutt 7y ago
    Sorry, I thought I read somewhere that a foundation might be started eventually. Edit: here: https://news.ycombinator.com/item?id=22008887 https://news.ycombinator.com/item?id=22008887 but I think it's not official.
  - rob74 7y ago
    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?
- steveklabnik 7y ago
  While the other commentors are correct that there's no Rust foundation, it is true that a member of the Fuchsia team is on the Rust language team, which does decide the direction of the language. 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 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.
sproketboy 7y ago
All GAY languages. Like fags on this web site.
stewbrew 7y ago
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.
- titzer 7y ago
  I saw that too, but there is another bullet point about the implementation experience of trying to use Go to implement some system services. Sounds like they had a bad experience.
- DenseComet 7y ago
  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.
- kirbyfan64sos 7y ago
  They're used for pretty different things. Dart with Flutter is used for the UIs, which Go wouldn't really do well at, and for system services that's where the con list really comes into play.
alphachloride 7y ago
For Dart: > Pro: People using the language are highly productive. Ok you convinced me.
- moksly 7y ago
  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 7y ago
    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.
lerax 7y ago
Basically... Dart and C++ only?
- _-___________-_ 7y ago
  That is really far from an accurate summary of the document.
- ____Sash---701_ 7y ago
  Pretty much, dart-ffi is used for C/C++ interop. Rust is mainly just mem-safe business logic. Dart is a lovely language and with Flutter you can target any OS/device.
mythz 7y ago
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.
- pjmlp 7y ago
  NVidia has decided to embrace Ada/SPARK after a study with Ada, Frama-C and Rust, and there is a Webinar with their decision rational. They also had similar reasons, however lack of ISO standard and certified compilers also played a role.
  - cpeterso 7y ago
    Link to NVIDIA's "Securing the Future of Safety and Security of Embedded Software" webinar about Ada/Spark: https://www.adacore.com/webinars/securing-future-of-embedded-software https://www.adacore.com/webinars/securing-future-of-embedded...
- tonyedgecombe 7y ago
  but because of their negative experiences it's been blacklisted with all code except netstack needing to be migrated to an approved language. Have you got a reference for that, it seems pretty damning if it's true.
pier25 7y ago
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 7y ago
  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 7y ago
    I agree, I always expected it to replace Android and Chrome OS into a single OS.
Gonzih 7y ago
Oh it saddens me so much that Rust is not approved for kernel development, oh well.
- steveklabnik 7y ago
  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 7y ago
> 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 7y ago
  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 7y ago
    Fuchsia exposes services via FIDL, so the lack of stable ABI isn't as big of a deal.
- kelnos 7y ago
  Not supported, but I expect that some enterprising individuals, if there's enough interest, will write some rust bindings. They'll support a C ABI for end-developers, and rust's C interop story is just fine. And there's no telling about the future; the Fuchsia team is certainly allowed to change their minds later and add supported SDKs.
walkerbrown 7y ago
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#definitions https://fuchsia.dev/fuchsia-src/concepts/api/council#definit...
dotasm 7y ago
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 7y ago
  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 7y ago
    To be fair to Go compile times, with them using C++ and Rust, that wouldn't be a show stopper.
pyb 7y ago
The interesting bit is at the end : they really don't like Go, a language that was developed at the same company.
- numlock86 7y ago
  > [...] 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 7y ago
    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.
- esjeon 7y ago
  It's not that they don't like Go. Go isn't designed for projects like this in the first place. Dart and Go are much more biased than C/C++ and Rust, and, even worse, Go is biased towards building services.
dvfjsdhgfv 7y ago
> Con: Rust is not a widely used language. and then: > Decision: Rust is not supported for end-developers.
nnq 7y ago
> 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 7y ago
  I seriously thought Dart was abandoned. Is it actually being used outside of Google?
  - pjmlp 7y ago
    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 7y ago
      Quoting HN rules: > Be kind. Don't be snarky. Your comment would have been quite helpful if you just removed the first line.
      - pjmlp 7y ago
        Noted.
flohofwoe 7y ago
> ...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 7y ago
  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.
The_rationalist 7y ago
No stated support for Java and Kotlin? This is meaningless and show that fuschia is run by vaporware people.
- wffurr 7y ago
  Really? There no support for those on iOS either and it's hardly vapor ware.
  - The_rationalist 7y ago
    iOS already has an existing multi billion software ecosystem. Did your brain forgot to take into account this little information?
    - pjmlp 7y ago
      With the easiness that Google kills anything that isn't search, it wouldn't surprise me.
    - wffurr 7y ago
      Now the size of an ecosystem might be a valid reason to consider something vaporware, rather than an arbitrary choice of programming language. Although if anything iOS proves you can build a billion dollar software ecosystem on a niche language: Objective-C. Also, are you always this rude or is it just internet comments that you disagree with? Not only does this site have guideline, the people you are writing to are people, like you, not just pixels on a screen.
      - The_rationalist 7y ago
        Although if anything iOS proves you can build a billion dollar software ecosystem on a niche language: Objective-C. Here the key information is that you can build a billion dollar software ecosystem for smartphones with any turing complete language, IF you are the first on the smartphone market. Such a situation will no longer happen in mankind history. Also, are you always this rude or is it just internet comments that you disagree with? Firstly I must say that I'm pretty tired of low intellectual efforts comments, especially when they increase or maintain a common erroneous/suboptimal opinion. As such, I highly consider information pollution and I want to protect people from this and their cognitive biases. Also, It require a big chunk of wisdom, but if you really think about it: Did your brain forgot to take into account this little information? Is not rude at all. This statememt is true and I didn't use imperative mood but conditional grammatical mood. Also some truths hurts ego indeed. But being hurt by information showing that our brain has limitations is irrational, we as humans make thinking errors as a daily routine, myself included. Such information allow you and readers to progress (iff they bypass their ego and the backfire effect). Personally I exclude myself from my past brain and my statements, I visualize them as beings outside of myself so when someone attack (without fallacies) what I said, they didn't attack ME, they attacked only what I said: that is, an intellectual product that could have been malformed due to limitations such as lacking knowledge or cognitive biases or presence of logical fallacies. My comment could show you there is a path to intellectual progress and I could give you some useful links (such as lesswrong.com ) if you're interested in it. Thanks for reading, human not made of pixels.
dhodell 7y ago
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 7y ago
  Is there anything (in the plans) to make fidl cross platform?
  - dhodell 7y ago
    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 7y ago
      Thanks! I was more going about the ecosystem - like grpc/protobuf have and support across languages/runtimes/systems.
      - raggi 7y ago
snarfy 7y ago
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 7y ago
  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 7y ago
    We should be encouraging vendors to release the source to their binary blobs instead of making it easier for them.
    - int_19h 7y ago
      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.
emilfihlman 7y ago
I cant help but think that "highly productive" here is not really a super scrutinised reason.
adir1 7y ago
With growing popularity of Python inside and outside of Google, any idea why it is not in the policy?
jillesvangurp 7y ago
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.

308 points by farmerbb 7y ago

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

sk0g 7y ago
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!
- kvark 7y ago
  Good to know! I'll look for an OS written in Rust elsewhere then. Fuchsia is interesting, but could be much more so.
  - bluejekyll 7y ago
    If you want to learn to write an OS in Rust, checkout this series: https://os.phil-opp.com/ https://os.phil-opp.com/ For an os project fully in rust and targeting end users, check out: https://www.redox-os.org/ https://www.redox-os.org/
- monocasa 7y ago
  Given that they already have a microkernel written in C++ (zircon is derived from littlekernel), and they're trying to move as much as possible outside the kernel, it makes sense that (for the time being) adding a new kernel language isn't on the table.
- bsder 7y ago
  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.
  - monocasa 7y ago
    They don't want to add loadable kernel modules (but instead go pretty strict microkernel), so what would an unstable FFI/ABI really matter?
    - lmm 7y ago
      It's much easier to progressively migrate away from a language if you have a stable ABI.
      - monocasa 7y ago
        The goal is to get it to the size where it can be replaced all at once. For instance sel4 is only 10kloc.
  - jcranmer 7y ago
    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?
    - flukus 7y ago
      > 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_Issues_With_C%2B%2B https://community.kde.org/Policies/Binary_Compatibility_Issu...
- anp 7y ago
  Rust binary size can be pretty painful, depending on what you're doing. Also, it doesn't look like that document is receiving regular updates, so grain of salt and all.
  - est31 7y ago
    > it doesn't look like that document is receiving regular updates It was checked into git yesterday.
- hu3 7y ago
  It's worth noting that Go and Dart were characterized as "highly productive" whilst Rust wasn't.
  - ShinTakuya 7y ago
    Absolutely, I don't think any sane Rust zealot would argue that Rust can compete with Go/Dart productivity. The argument can be made that Rust code has a lower maintenance cost over time, though, and that productivity may not drop as much as the system becomes more complex. 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.
melling 7y ago
Rust sounded like it was close: “ 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.
- foota 7y ago
  That's probably in part demand driven? I.e., there's little need for rust to be supported officially for end users.
  - dodobirdlord 7y ago
    Moreover, C is supported for end users, and if C is supported then Rust is de facto supported though C bindings, which Rust understands natively.
    - pjmlp 7y ago
      Someone will have the fun of writing those wrappers, because Google won't do it. 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.
      - zozbot234 7y ago
        Rust doesn't have a stable ABI, so it's sensible to always go through C bindings anyway. The other things you mention are just a matter of what their future Fuchsia Studio chooses to support.
- ztjio 7y ago
  The majority of the code in the project is already written in Rust. If we're judging Rust based on its acceptance in Fuchsia for some weird reason, it's doing very well. Doing the best, in fact.
brianpgordon 7y ago
That doesn't seem like a non-serious criticism to me. They're trying to build something huge that's of immense strategic importance looking forward potentially decades. It seems appropriate to adopt the utmost caution about incorporating a language that's promising but for which widespread traction might not materialize as expected. Though to be fair, the same (and more) might be said of Dart...
- ollien 7y ago
  Yeah, but when something is built in-house like Dart is, I imagine there's some level of support the Fuchsia team will get.
  - roca 7y ago
    The world of paid Rust language contributors is so small that Google could easily get all the advantages of "built in-house" for Rust if they spent a relatively tiny amount of money. Being pretty conservative overall but betting the house on Dart for the UI seems like a strange combination of decisions to me.
    - toastal 7y ago
      Is there a conspiratorial side of Mozilla vs Google in this Rust vs Dart story?
      - usrusr 7y ago
        The languages are as different as Python and C++, I honestly don't really see a Rust vs Dart story. Note that Rust is approved for use within much of the source tree, but outside it is only not supported. Johnny end-developer, whoever that is, could still use Rust if he insisted, coding against C bindings.
        pjmlp 7y ago
        Just like it happens in Android. 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.
bassman9000 7y ago
compared to the serious criticisms of the others 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.
badsectoracula 7y ago
The reasoning does sound serious: "The properties of the language are not yet well-understood, having selected an unusual language design point (e.g., borrow checker) and having existed only for a relatively short period of time". It isn't just "it isn't popular thus it is not good" but "it does something weird that no other language does and because few people use it, we haven't yet figured out what potential issues that weird part may have".
- bluejekyll 7y ago
  > does sound serious 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.
  - badsectoracula 7y ago
    Yes i meant legitimate, though i'm not sure why you say that it sounds like technical debt. I'd say it is the opposite - trying to avoid technical debt that could happen by betting on something unknown and instead staying on the safe side.
    - bluejekyll 7y ago
      I meant technical debt for the Rust project, not for fuchsia. I don’t disagree, Fuchsia would end up incurring this debt in the kernel too. 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.
- mirekrusin 7y ago
  After having 2.2 million lines of code in rust in their project they should know a bit better imho; that's more than any other language they use; with go they knew quite quickly it's not good for them.
ReptileMan 7y ago
Sorry, but that was not the only con. The other were that the design was unusual and it is not yet understood. 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.
- zbraniecki 7y ago
  I agree with your summary. 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.
  - _-___________-_ 7y ago
    The microkernel is a pretty small component. It's like if 80% of the Linux kernel was Rust and 20% was C++.
EamonnMR 7y ago
Notice that they omitted the "highly productive" claim thy applied to Dart and Go.
zelly 7y ago
There isn't a lot of good software written in Rust, open source or not. It's a lot of small and half-finished stuff here and there. The actual software out there is the ultimate, unforgiving, unfraudable review of a language, not what people say. 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.
- dodobirdlord 7y ago
  > There isn't a lot of good software written in Rust, open source or not. It's a lot of small and half-finished stuff here and there. 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.
  - zelly 7y ago
    > half-finished 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.
    - kick 7y ago
      There is literally no Rust in the main repo: https://github.com/linkerd/linkerd2 https://github.com/linkerd/linkerd2 https://github.com/linkerd/linkerd 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.

sk0g 7y ago

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 7y ago
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.
- nine_k 7y ago
  Not "stupid" but "inexperienced". Rather obviously, people who implement OSes are usually the opposite.
- throwaway894345 7y ago
  You might not agree, but the idea is that you should devote your cognitive resources to the problem you’re solving and not working around complexities in your language (such that brilliant developers such as yourself and “stupid” developers like me can be even more productive than we would be with C++ or Haskell or whathaveyou) or choosing stylistic standards for how contributors are to program (because the language is so expressive that the solution space is astronomical). “Go programmers are stupid” is a deliberately uncharitable interpretation.
  - dnautics 7y ago
    You might not agree, but there are programming languages that, unlike Go, don't take a "programmers are stupid" opinion, that are incredibly productive. Here are some other ways you can make developers productive (just off the top of my head): 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.

anthm1988 7y ago

What's the fucking point of developing a language like rust if people like this are too cowardly to use it.

nine_k 7y ago

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 7y ago
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 7y ago
  Neat, I didn't know about seL4. Can you point me to how they define the proof for it?
  - monocasa 7y ago
    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.
  - reirob 7y ago
    FOSDEM speach video [1] about the status of seL4, I really enjoyed. [1]: https://fosdem.org/2020/schedule/event/uk_sel4/ https://fosdem.org/2020/schedule/event/uk_sel4/
- adamnemecek 7y ago

madmax96 7y ago

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.

beart 7y ago
If I could eliminate 17% of the bugs in a future code base by choosing to use a different language, I would need a strong reason not to.
- madmax96 7y ago
  The strong reason is given in the linked article. C is better supported, more stable, has more developers, and is better understood. Meanwhile many of these bugs could be caught by testing, which you should be doing anyway. You can also survive the effects of the bugs with other tools like stackguard with extremely low overhead, while still having the vast benefits of C described in the original article.
  - pjmlp 7y ago
    We have been hearing that matra for 40 years now, thankfully companies are finally getting wiser.
tomesco 7y ago
>I think the effects of memory bugs on security are often overstated. How often?
liamdiprose 7y ago
> 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-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

lawrenceyan 7y ago

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

clSTophEjUdRanu 7y ago
The Mullvad VPN app is written in Rust.
ehsankia 7y ago
I know Discord is migrating a lot of their stuff from Go to Rust. Not sure how major you consider Discord.
Groxx 7y ago
Some: https://www.jonathanturner.org/2018/07/snapshot-of-rust-popularity.html#rusts-commercial-users https://www.jonathanturner.org/2018/07/snapshot-of-rust-popu... As far as "using it in a substantial portion of their product", dunno.
PudgePacket 7y ago
just a sample: dropbox, cloudflare, canonical, sentry, atlassian, npm, ibm, xero https://www.rust-lang.org/production https://www.rust-lang.org/production https://www.rust-lang.org/production/users https://www.rust-lang.org/production/users
brson 7y ago
There are. Here is a copy of my notes on the subject: https://gist.github.com/brson/9422a92791062ac52d9e08f0ba7d48cf https://gist.github.com/brson/9422a92791062ac52d9e08f0ba7d48... Sorry it's not more organized and detailed.
- steveklabnik 7y ago
  Another recent big user is 1password, both on the Windows desktop and in the browser with wasm. Great notes!
kgersen 7y ago

fiddlerwoaroof 7y ago

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 7y ago
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 7y ago
  > 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.
  - terminaljunkid 7y ago
    Support means all APIs have first class support by Google, just like how Kotlin has first class support on Android.
  - _-___________-_ 7y ago
    They have no means to enforce that. They're talking about what they provide support for, not what is possible.
    - fiddlerwoaroof 7y ago
      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.

swiley 7y ago

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.

franciscop 7y ago
All of the current mobile OS. I also prefer seeing it formalized than hidden.
- swiley 7y ago
  Those are models now?? I'll trade my laptop for an abacus before I trade it for a pixel.
Gaelan 7y ago
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.
- swiley 7y ago
  A lot of Linux OSes define protocols and interfaces with matching implementations. The kernel has syscalls, the GUI has a socket protocol etc. 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.
  - anthk 7y ago
    In Unix, C is THE API.
- throwaway17_17 7y ago
  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.

maximilianroos 7y ago

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.

est31 7y ago

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/5c13979043e760a597a019999d5602de/raw/acd8458ab45ebac186dc1a0e700985fb68d663db/gistfile1.txt https://gist.githubusercontent.com/est31/5c13979043e760a597a... 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/5c13979043e760a597a019999d5602de/raw/5e770560cb9dbdfa6e5d95d7bb741334f29e7aff/gistfile2.txt 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).

bluejekyll 7y ago
does the src directory include any vendored software for the other languages? Or is that also only fuchsia code?
- est31 7y ago
  Could you clarify your question? The fuchsia subdir contains various user space components of the OS, like a network stack, bluetooth, graphics drivers, etc. Also some tools and test code. Rust is used in most of the components I looked at.
  - bluejekyll 7y ago
    Edited my comment. Didn’t notice that vendored got spelling corrected to censored :(
    - 7y ago

scoutt 7y ago

> 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 7y ago
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.
- scoutt 7y ago
  Sorry, I thought I read somewhere that a foundation might be started eventually. Edit: here: https://news.ycombinator.com/item?id=22008887 https://news.ycombinator.com/item?id=22008887 but I think it's not official.
- rob74 7y ago
  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?
steveklabnik 7y ago
While the other commentors are correct that there's no Rust foundation, it is true that a member of the Fuchsia team is on the Rust language team, which does decide the direction of the language. 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 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.

sproketboy 7y ago

All GAY languages. Like fags on this web site.

stewbrew 7y ago

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.

titzer 7y ago
I saw that too, but there is another bullet point about the implementation experience of trying to use Go to implement some system services. Sounds like they had a bad experience.
DenseComet 7y ago
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.
kirbyfan64sos 7y ago
They're used for pretty different things. Dart with Flutter is used for the UIs, which Go wouldn't really do well at, and for system services that's where the con list really comes into play.

alphachloride 7y ago

For Dart: > Pro: People using the language are highly productive. Ok you convinced me.

moksly 7y ago
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 7y ago
  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.

lerax 7y ago

Basically... Dart and C++ only?

_-___________-_ 7y ago
That is really far from an accurate summary of the document.
____Sash---701_ 7y ago
Pretty much, dart-ffi is used for C/C++ interop. Rust is mainly just mem-safe business logic. Dart is a lovely language and with Flutter you can target any OS/device.

mythz 7y ago

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.

pjmlp 7y ago
NVidia has decided to embrace Ada/SPARK after a study with Ada, Frama-C and Rust, and there is a Webinar with their decision rational. They also had similar reasons, however lack of ISO standard and certified compilers also played a role.
- cpeterso 7y ago
  Link to NVIDIA's "Securing the Future of Safety and Security of Embedded Software" webinar about Ada/Spark: https://www.adacore.com/webinars/securing-future-of-embedded-software https://www.adacore.com/webinars/securing-future-of-embedded...
tonyedgecombe 7y ago
but because of their negative experiences it's been blacklisted with all code except netstack needing to be migrated to an approved language. Have you got a reference for that, it seems pretty damning if it's true.

pier25 7y ago

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 7y ago
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 7y ago
  I agree, I always expected it to replace Android and Chrome OS into a single OS.

Gonzih 7y ago

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

steveklabnik 7y ago
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 7y ago

> 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 7y ago
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 7y ago
  Fuchsia exposes services via FIDL, so the lack of stable ABI isn't as big of a deal.
kelnos 7y ago
Not supported, but I expect that some enterprising individuals, if there's enough interest, will write some rust bindings. They'll support a C ABI for end-developers, and rust's C interop story is just fine. And there's no telling about the future; the Fuchsia team is certainly allowed to change their minds later and add supported SDKs.

walkerbrown 7y ago

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#definitions https://fuchsia.dev/fuchsia-src/concepts/api/council#definit...

dotasm 7y ago

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 7y ago
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 7y ago
  To be fair to Go compile times, with them using C++ and Rust, that wouldn't be a show stopper.

pyb 7y ago

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

numlock86 7y ago
> [...] 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 7y ago
  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.
esjeon 7y ago
It's not that they don't like Go. Go isn't designed for projects like this in the first place. Dart and Go are much more biased than C/C++ and Rust, and, even worse, Go is biased towards building services.

dvfjsdhgfv 7y ago

> Con: Rust is not a widely used language. and then: > Decision: Rust is not supported for end-developers.

nnq 7y ago

> 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 7y ago
I seriously thought Dart was abandoned. Is it actually being used outside of Google?
- pjmlp 7y ago
  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 7y ago
    Quoting HN rules: > Be kind. Don't be snarky. Your comment would have been quite helpful if you just removed the first line.
    - pjmlp 7y ago
      Noted.

flohofwoe 7y ago

> ...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 7y ago
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.

The_rationalist 7y ago

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

wffurr 7y ago
Really? There no support for those on iOS either and it's hardly vapor ware.
- The_rationalist 7y ago
  iOS already has an existing multi billion software ecosystem. Did your brain forgot to take into account this little information?
  - pjmlp 7y ago
    With the easiness that Google kills anything that isn't search, it wouldn't surprise me.
  - wffurr 7y ago
    Now the size of an ecosystem might be a valid reason to consider something vaporware, rather than an arbitrary choice of programming language. Although if anything iOS proves you can build a billion dollar software ecosystem on a niche language: Objective-C. Also, are you always this rude or is it just internet comments that you disagree with? Not only does this site have guideline, the people you are writing to are people, like you, not just pixels on a screen.
    - The_rationalist 7y ago
      Although if anything iOS proves you can build a billion dollar software ecosystem on a niche language: Objective-C. Here the key information is that you can build a billion dollar software ecosystem for smartphones with any turing complete language, IF you are the first on the smartphone market. Such a situation will no longer happen in mankind history. Also, are you always this rude or is it just internet comments that you disagree with? Firstly I must say that I'm pretty tired of low intellectual efforts comments, especially when they increase or maintain a common erroneous/suboptimal opinion. As such, I highly consider information pollution and I want to protect people from this and their cognitive biases. Also, It require a big chunk of wisdom, but if you really think about it: Did your brain forgot to take into account this little information? Is not rude at all. This statememt is true and I didn't use imperative mood but conditional grammatical mood. Also some truths hurts ego indeed. But being hurt by information showing that our brain has limitations is irrational, we as humans make thinking errors as a daily routine, myself included. Such information allow you and readers to progress (iff they bypass their ego and the backfire effect). Personally I exclude myself from my past brain and my statements, I visualize them as beings outside of myself so when someone attack (without fallacies) what I said, they didn't attack ME, they attacked only what I said: that is, an intellectual product that could have been malformed due to limitations such as lacking knowledge or cognitive biases or presence of logical fallacies. My comment could show you there is a path to intellectual progress and I could give you some useful links (such as lesswrong.com ) if you're interested in it. Thanks for reading, human not made of pixels.

dhodell 7y ago

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 7y ago
Is there anything (in the plans) to make fidl cross platform?
- dhodell 7y ago
  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 7y ago
    Thanks! I was more going about the ecosystem - like grpc/protobuf have and support across languages/runtimes/systems.
    - raggi 7y ago

snarfy 7y ago

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 7y ago
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 7y ago
  We should be encouraging vendors to release the source to their binary blobs instead of making it easier for them.
  - int_19h 7y ago
    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.

emilfihlman 7y ago

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

adir1 7y ago

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

jillesvangurp 7y ago

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.