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...
The difference I think is that Dart is a dependency they have already accepted on the level of "we'll maintain it if necessary" (probably in the form of the intra-Google equivalent of an acqui-hire, I wouldn't even be surprise if Dart/Flutter were already reporting to Fuchsia, while publicly still appearing as equal peers), whereas Rust is a big scary NIH.
And still the decision on Rust reads very much like a "we'd love to extend the scope of the time is right" whereas the dismissal of Go is surprisingly brutal, almost reads as if there was a cold civil war going on between the two garbage collected Google languages and Fuchsia people feel need to to demonstrate loyalty to their Darters. Might even just mirror an equal dismissal regarding server side Dart.
> Might even just mirror an equal dismissal regarding server side Dart.
That'd be my guess. Given the nature of Flutter and its co-development with Dart it's not surprising that Fuchsia prioritizes it. After all, you need to implement the UI in something. Meanwhile I have literally never heard of a UI implemented in Go, and outside of the UI I can see why they don't want to use garbage collected languages in their OS.
> I have literally never heard of a UI implemented in Go
I expect it has the same issue as UI in Rust: UI is one of the domain where OO inheritance is most convenient and most deeply embedded. So langages which don’t do inheritance are hard sells.
Newer “declarative” UI frameworks less so but they’re probably not mature enough conceptually that you’d want to bet your OS’s core UI system on them, right now they’d be used as an overlay on the core stateful UI system (see bodil’s vgtk for example).
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.
They don't seem to be betting on Dart by itself as much as they are betting on Flutter, which is already reasonably successful and relies on familiar reactive component concepts popular on the web and well tested in Google's own web frameworks (Polymer, Angular).
I agree with you, the point I was trying to convey is that Google isn't betting on Dart as a pioneering, untested technology as Rust is.
Flutter demonstrates Dart is a good choice; it gives you a successful declarative UI framework that effectively builds on Dart as a fairly straightforward upgrade of the most tried and true UI scripting language ever made: Javascript.
To answer the GP comment, betting the house on Dart for the UI doesn't seem like a strange or risky decision in that light.
That you like Dart and that it's a good fit for UI development doesn't make it less risky.
It still seems incongruous that widespread usage is portrayed as an important criterion for Fuschia PLs, but they bet big on Flutter which forces them to adopt Dart, a language which has very little uptake outside Flutter.
I'm not sure how you got "I like Dart" from my two comments. I'm clearly saying that Dart & Flutter are based on very popular and well tested concepts/structures, therefore it is not very risky. Dart & Flutter by themselves may not be very widespread, but it's very familiar and easy to adopt to anyone who has done declarative UI web development in Javascript or Javascript-like language, which are widespread.
Rust, on the other hand, is treading new ground with the unusual core concept of a borrow checker.
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.
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.
I don't know what "conspiracy" you might be referring to. There's a natural tendency for organizations to gravitate toward tools, such as programming languages, that originated there. That's just human nature, though, not anything nefarious.
> They're trying to build something huge that's of immense strategic importance looking forward potentially decades.
This seems like an exaggeration. Maybe Fuchsia will turn out to be important, maybe it won't. As of right now, it's another Google vanity project that makes them no money.
It could turn out to be enormously strategically important by allowing Google to drive a stake through the heart of Linux on consumer devices...or just as easily get killed tomorrow.
