Rust in the Android Platform(security.googleblog.com)
security.googleblog.com
Rust in the Android Platform
https://security.googleblog.com/2021/04/rust-in-android-platform.html
86 comments
>> For the past 18 months we have been adding Rust support to the Android Open Source Project, and we have a few early adopter projects that we will be sharing in the coming months. Scaling this to more of the OS is a multi-year project. Stay tuned, we will be posting more updates on this blog.
Patiently waiting for the Rust APIs to arrive . . .
Java feels so heavy, so getting to use Rust would be a breath of fresh air.
(Kotlin has been better, but it also requires the JVM.)
Patiently waiting for the Rust APIs to arrive . . .
Java feels so heavy, so getting to use Rust would be a breath of fresh air.
(Kotlin has been better, but it also requires the JVM.)
The third paragraph says
> Managed languages like Java and Kotlin are the best option for Android app development. These languages are designed for ease of use, portability, and safety.
You're not going to write Android Activities in Rust. Nothing is stopping you from adding Rust code to your Java/Kotlin app though.
> Managed languages like Java and Kotlin are the best option for Android app development. These languages are designed for ease of use, portability, and safety.
You're not going to write Android Activities in Rust. Nothing is stopping you from adding Rust code to your Java/Kotlin app though.
There's already an API for native activities. While I doubt that Google will be the one to release the framework to write Rust applications, there's no reason why it would be impossible to interface app-level Rust with the Android SDK.
The big problem with such a setup, of course, is that the application itself would be running inside a JVM/Dalvik VM, so the app would constantly be switching between Java and native, which can't be great for performance. However, it can be done; thankfully, Chrome and Firefox aren't completely compiled to byte code, the JIT and rendering code is written in native code. With Mozilla's use of Rust in their browser, that means that there's already a significant Rust runtime running on Android, at least.
If the app uses Rust and a library to hook the draw call, it should be fairly easy to write the app like a video game and render everything in Rust. This would come bundled with a tonne of accessibility problems, of course, as every rendered control would be a non-standard one.
The big problem with such a setup, of course, is that the application itself would be running inside a JVM/Dalvik VM, so the app would constantly be switching between Java and native, which can't be great for performance. However, it can be done; thankfully, Chrome and Firefox aren't completely compiled to byte code, the JIT and rendering code is written in native code. With Mozilla's use of Rust in their browser, that means that there's already a significant Rust runtime running on Android, at least.
If the app uses Rust and a library to hook the draw call, it should be fairly easy to write the app like a video game and render everything in Rust. This would come bundled with a tonne of accessibility problems, of course, as every rendered control would be a non-standard one.
Java is a better fit for high level code, and you can already use Rust where performance matters.
I've put a lot of time into learning Rust and I still reach for Java for high level stuff. GC is just wonderful for developer productivity. Lifetimes are way better than C but still a PITA.
Especially when you mix with threading, you end up using Reference Counting anyways which is just shitty GC.
I've put a lot of time into learning Rust and I still reach for Java for high level stuff. GC is just wonderful for developer productivity. Lifetimes are way better than C but still a PITA.
Especially when you mix with threading, you end up using Reference Counting anyways which is just shitty GC.
I think another problem is that native binaries for multiple architectures would grow the binary, one per arch; aarch64 is not the only thing android runs on. Maybe some people would also forget that and not bother targeting others.
Honestly, between the magic Kotlin adds on top of Java and Rust, I prefer Rust. At least it’s not doing stuff behind my back.
C++ is better. Rust is a cargo cult language (same with Kotlin, Kotlin especially is a corporate language to sell more IDEs and Google was bribed by JetBraine to adopt it). Rust is just a bad attempt at reinventing the wheel.
Rust is a fantastic attempt at reinventing C++. It works really well. I've been writing production code in it for the last few years and it's an utter delight to use.
I maybe break out rust-gdb once a year. My code has fewer bugs than ever, thanks to extensive use of the high-quality modeling tools (types and lifetimes) provided by the language. My main project for the last year has had a grand total of one logic bug that was caught after release.
It also has an inclusive community: at the last RustConf, half the speakers were nonbinary and/or transgender. I fit both those criteria and feel more welcome in the Rust community than in that of any other language, meaning that I can do my best work in Rust.
I maybe break out rust-gdb once a year. My code has fewer bugs than ever, thanks to extensive use of the high-quality modeling tools (types and lifetimes) provided by the language. My main project for the last year has had a grand total of one logic bug that was caught after release.
It also has an inclusive community: at the last RustConf, half the speakers were nonbinary and/or transgender. I fit both those criteria and feel more welcome in the Rust community than in that of any other language, meaning that I can do my best work in Rust.
Considering way less than 50% of developers are nonbinary/transgender, don't you get the impression that they're then trying to fill quotas rather than picking the best speakers? Not saying they weren't the best, just that either rust is a very unique community or something is "up" with the selection.
Just to clarify, I'm asking with good intent.
Just to clarify, I'm asking with good intent.
There's a selection effect: people like me experience so much ambient hostility in society that we gravitate towards communities that welcome us and that already have people like us in leadership positions. So the correct metric is not % of all developers as a whole but just the ones involved in the Rust community.
The Rust community has many nonbinary and transgender people in it, and speakers are selected from the community. The selection process for RustConf is blind so the talks were picked for their merit: it just so happened that half of the speakers weren't cis.
> rust is a very unique community
Yes, this is true in my experience.
The Rust community has many nonbinary and transgender people in it, and speakers are selected from the community. The selection process for RustConf is blind so the talks were picked for their merit: it just so happened that half of the speakers weren't cis.
> rust is a very unique community
Yes, this is true in my experience.
I've been thinking about a good answer, but these days it's a fine line to talk about these things. I'm happy the rust community is so open while being widely successful. Might shine some light into the rest of the world. I'm from Sweden,where this kind of hostility probably exists, but I never see it (gay people are very well accepted, trans I'm not as certain, only have a pool of 1 friend so not enough data).
I'm not Swedish so I don't know much about what it's like to be a Swedish trans person.
One thing I will say is that my general impression from afar is that Europeans are generally a lot more tolerant of the state interfering in personal identity issues than the liberal parts of the US. Iceland used to have a fixed list of approved baby names for example, something unimaginable in the US.
The situation was made better in 2019: https://www.icelandreview.com/news/icelandic-names-will-no-l...
One thing I will say is that my general impression from afar is that Europeans are generally a lot more tolerant of the state interfering in personal identity issues than the liberal parts of the US. Iceland used to have a fixed list of approved baby names for example, something unimaginable in the US.
The situation was made better in 2019: https://www.icelandreview.com/news/icelandic-names-will-no-l...
I think the discussion gets a bit blurred around what acceptance means.
It varies from acceptance of an adult just being trans, of trans babies, of schools preaching medical transition without parent approval, and of issue of bathroom usage and sex-segregated prisons.
Regardless of the political questions presumably Swedes are fairly liberal about someone's personal choices.
It varies from acceptance of an adult just being trans, of trans babies, of schools preaching medical transition without parent approval, and of issue of bathroom usage and sex-segregated prisons.
Regardless of the political questions presumably Swedes are fairly liberal about someone's personal choices.
It might be that people from disadvantaged communities _need_ to have more talent & insight to become experts than people like me (straight, white, male, speaks English, went to college, ...) and (I assume) you. And even more so to become _recognized_ experts. Also, they might feel more of a need to demonstrate that they should be allowed in the "club".
Put another way and exaggerated wildly for hopeful clarity, if person A became an expert despite being shoved away, and person B was wooed into the group, had tutors, friends,... I'd be more interested in A's talk than B's.
Put another way and exaggerated wildly for hopeful clarity, if person A became an expert despite being shoved away, and person B was wooed into the group, had tutors, friends,... I'd be more interested in A's talk than B's.
Good insight, it seems like the reply below said the talks were submitted blindly though, so that's even better. They're just accepted and doing really well!
Somehow, queer people are subconsciously attracted to each other (not necessarily in a romantic or sexual way). While 50% non-cis is surprising, when we are represented we tend to be overrepresented.
Rust is a bad attempt at reinventing C++? That's a unique take.
Memory safety is a big deal for writing secure programs, which has been repeatedly shown to be impossible to do at scale in C++. Provably safe parallelism and concurrency is key for performance on multi core devices, also extremely difficult to do safely and correctly in C++.
If C++ is the wheel being reinvented, it's not much of a wheel.
Memory safety is a big deal for writing secure programs, which has been repeatedly shown to be impossible to do at scale in C++. Provably safe parallelism and concurrency is key for performance on multi core devices, also extremely difficult to do safely and correctly in C++.
If C++ is the wheel being reinvented, it's not much of a wheel.
No way. Rust is great, trust me.
I'm not even going to say why because it would be a huge rant. It improves on C++ in virtually every way. Every feature you have in C++, Rust does it better. Every feature you wish C++ had, Rust has it.
I agree with you on Kotlin. It's better than Java on paper, but in much the same ways Groovy already was. And the advantages are shrinking in new versions of Java, especially if you use Lombok.
I'm not even going to say why because it would be a huge rant. It improves on C++ in virtually every way. Every feature you have in C++, Rust does it better. Every feature you wish C++ had, Rust has it.
I agree with you on Kotlin. It's better than Java on paper, but in much the same ways Groovy already was. And the advantages are shrinking in new versions of Java, especially if you use Lombok.
"Every feature you have in C++, Rust does it better"
How does one perform generic fold expressions in Rust lang ? (Possible in C++ 17 and above)
https://foonathan.net/2020/05/fold-tricks/ https://en.cppreference.com/w/cpp/language/fold
How does one perform generic fold expressions in Rust lang ? (Possible in C++ 17 and above)
https://foonathan.net/2020/05/fold-tricks/ https://en.cppreference.com/w/cpp/language/fold
Macros baby
AFAIK, macros are only applicable to a subset of problems. Anyways, I found that variadic generics is a draft RFC: https://github.com/rust-lang/rfcs/issues/376
>Every feature you have in C++, Rust does it better.
IDK. I miss variadic functions (not macros) and being able to do certain simple things without resorting to strange paradigms, like arbitrarily closing an std::fs::File without needing to go out of scope or calling drop. Things like that.
IDK. I miss variadic functions (not macros) and being able to do certain simple things without resorting to strange paradigms, like arbitrarily closing an std::fs::File without needing to go out of scope or calling drop. Things like that.
How is calling drop any different from calling close?
For the practical case is not different. But is not coherent. It’s weird. And opening/closing files is an historical concept.
Why “drop” is the opposite of “open”? Let’s change “open” for “lift” or “notdrop”.
Why “drop” is the opposite of “open”? Let’s change “open” for “lift” or “notdrop”.
Google was bribed by JetBraine to adopt it
It's hard not being sarcastic in reply to this. But no, this did not happen.
It's hard not being sarcastic in reply to this. But no, this did not happen.
While it feels terribly hacky, one could probably write an Android-wrapper around Rust in Java. A rather big undertaking, I'd guess, since it means exposing all APIs to rust somehow.
An other approach would be to employ one of many thin webview wrappers, in which your app is HTML+Js+CSS. When such a webview wrapper supports WASM, the JS part could be written in rust.
Not something I'd do other than "to prove it can be done".
An other approach would be to employ one of many thin webview wrappers, in which your app is HTML+Js+CSS. When such a webview wrapper supports WASM, the JS part could be written in rust.
Not something I'd do other than "to prove it can be done".
The "cargo apk" tool already exists to bundle Rust code into a NativeActivity that can be run without needing to write any additional Java code. The API surface so provided is more limited than the full toolkit, but could be useful in many domains. It's currently mostly used for games. I am using it for the Android port of piet-gpu, and it's working pretty well.
The biggest problem here is that in Android, Java "owns" the app, so you will have to invert a lot of lines to make "develop a whole app in Rust" feel awesome.
But, TBH, I think Kotlin and Java are _indeed_ fine application languages.
What Rust is already quite often used for is for libraries that work on both iOS and Android. For a public example, see the Glean SDK: https://mozilla.github.io/glean/book/index.html
But, TBH, I think Kotlin and Java are _indeed_ fine application languages.
What Rust is already quite often used for is for libraries that work on both iOS and Android. For a public example, see the Glean SDK: https://mozilla.github.io/glean/book/index.html
> But, TBH, I think Kotlin and Java
I agree wholeheartedly.
But there will be a demographic of people who know Rust and not Java, but who might want to build an app. Somewhat similar to how there is an apparent need for "HTML+JS+CSS"-devs to build native apps.
I agree wholeheartedly.
But there will be a demographic of people who know Rust and not Java, but who might want to build an app. Somewhat similar to how there is an apparent need for "HTML+JS+CSS"-devs to build native apps.
Well, this is always a tradeoff: the cost of being away from the mainstream may outweigh familiarity with a programming language at some point.
I'm not sure if the argument for "HTML+JS+CSS" is purely familiarity, there's also technical arguments like portability and future-compatibility. But I _do_ hope that the portability story will become better in the coming years beyond just this stack.
I'm not sure if the argument for "HTML+JS+CSS" is purely familiarity, there's also technical arguments like portability and future-compatibility. But I _do_ hope that the portability story will become better in the coming years beyond just this stack.
They say earlier
> now supports the Rust programming language for developing the OS itself.
So, this seems to be about in Android, not building apps for Android.
Guess we'll see with more posts!
> now supports the Rust programming language for developing the OS itself.
So, this seems to be about in Android, not building apps for Android.
Guess we'll see with more posts!
Right, as with other complicated low level systems, Android sees an annoying but seemingly unending stream of bugs that would be either impossible or unlikely if you used Rust.
I expect replacing low-level C++ with Rust to result in improved platform reliability as well as reduced security bugs.
For every weird memory safety bug that is usefully exploitable there are a hundred more that just mysteriously break things and may be very difficult for a human to spot. My WebAuthn tests broke on my Pixel 2 on Saturday, I spent about an hour trying to debug the problem, wondering why it was happening now but not before and why it didn't affect other platforms - then I rebooted the phone and it went from reporting a "NotReadableError" about the secure local storage to just working.
I expect replacing low-level C++ with Rust to result in improved platform reliability as well as reduced security bugs.
For every weird memory safety bug that is usefully exploitable there are a hundred more that just mysteriously break things and may be very difficult for a human to spot. My WebAuthn tests broke on my Pixel 2 on Saturday, I spent about an hour trying to debug the problem, wondering why it was happening now but not before and why it didn't affect other platforms - then I rebooted the phone and it went from reporting a "NotReadableError" about the secure local storage to just working.
Shouldn't Rust be able to hook into the NDK already anyways?
I haven't personally done it, but given Rust can call C and be called like C, I don't know why not. I do know that Rust is being used in Android apps like Cloudflare's 1.1.1.1 app, but I don't know if those make ndk calls or not.
That's exactly right. Today, the focus is on making it possible to use Rust to write pieces of the Android platform itself.
Certainly, there are some _apps_ on Android today that use Rust (shout-out to my Firefox friends!), but that's not something I'm investing in right now.
Certainly, there are some _apps_ on Android today that use Rust (shout-out to my Firefox friends!), but that's not something I'm investing in right now.
I think you can do 60fps on android with kotlin easily ... in fact you can do that with RN (if you're careful).
Rust is not a UI programming language and shouldn't be.
but writing your own native modules in rust might be fun (VR, Audio processing, AI ...)
Rust is not a UI programming language and shouldn't be.
but writing your own native modules in rust might be fun (VR, Audio processing, AI ...)
What prevents Rust(as a language) from being used to write UI? Qt is implemented in C++, which rust seems to aim to replace.
Rust seems like an excellent contender for the future.
Rust seems like an excellent contender for the future.
The borrow checker.
UIs tend to have designs that require graph based structures and self referencial references, so in the end you get either lots of Rc<RefCell<>> and clone() calls, or have to bind the whole stack to fit into Rust's memory model.
Have a look at,
https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020....
https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....
UIs tend to have designs that require graph based structures and self referencial references, so in the end you get either lots of Rc<RefCell<>> and clone() calls, or have to bind the whole stack to fit into Rust's memory model.
Have a look at,
https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020....
https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....
Many UI toolkits use shared ownership and callbacks, and that's annoying in Rust. Some bindings make it work. There's a bunch of folks working on interesting architectures. But the classic styles just clash with Rust's default way of doing things.
Multi threading sanely requires Arc, and reference counting is a crappy form of GC.
If you have enough threads passing stuff around and can deal with the ~50% performance loss between Java and Rust, it's much easier to use a language with GC.
There's talk of adding a quality GC to rust and dedicated GC types. If/when that happens, Rust will be a contender for a bunch of higher level systems
If you have enough threads passing stuff around and can deal with the ~50% performance loss between Java and Rust, it's much easier to use a language with GC.
There's talk of adding a quality GC to rust and dedicated GC types. If/when that happens, Rust will be a contender for a bunch of higher level systems
If official* APIs come then they will probably come via ndk. It's been a while since I've heavily done Android dev but historically those APIs have lagged behind a lot. At one point there was a major push to catch them up but they were still pretty second class.
I'd still much rather use the standard SDK and kotlin and I absolutely adore rust.
*There are already unofficial ndk crates for rust.
I'd still much rather use the standard SDK and kotlin and I absolutely adore rust.
*There are already unofficial ndk crates for rust.
I don’t mind Kotlin itself so much, but the Java baggage it brings and the general weirdness that is possible when developing for Android in Java/Kotlin can get irritating. If not Rust, it’d be nice to be able to instead write Swift or some other modern compiled language suitable for UI work.
This is actually an area where iOS is more flexible. Because UIKit is C-accessible, it’s feasible to develop bindings to it for other languages, and even autogenerate them. It’s too bad the same isn’t true of Android Framework.
This is actually an area where iOS is more flexible. Because UIKit is C-accessible, it’s feasible to develop bindings to it for other languages, and even autogenerate them. It’s too bad the same isn’t true of Android Framework.
Newer versions of Java are better, but Android is stuck on a hacky version of Java 7 from a decade ago.
Google is planning to fix this eventually.
Android's API is also atrocious.
Google is planning to fix this eventually.
Android's API is also atrocious.
I don't know enough about Kotlin to know if it's useful or not to point out Kotlin/Native: https://kotlinlang.org/docs/native-overview.html
GraalVM native is generally better than Kotlin native as it maintain Java-kotlin interop. Kotlin native is more for niche use cases like objective-C/Swift interop.
Kotlin/Native is also being redone after being proven that not following the same memory model as the JVM was a bad decision.
I build Android almost every day, and now it takes forever on a dedicated build machine with SSDs and 32GB RAM.
I hope this doesn't increment build time, otherwise it'll be a true pain.
>For complex C/C++ code bases, often there are only a handful of people capable of developing and reviewing the fix
I don't see why the Rust alternative would make solving bugs easier. It's ugly and hard to read, hard to parse and hard to follow (IMHO). If before there was "only a handful of people capable", now it will be less.
I hope this doesn't increment build time, otherwise it'll be a true pain.
>For complex C/C++ code bases, often there are only a handful of people capable of developing and reviewing the fix
I don't see why the Rust alternative would make solving bugs easier. It's ugly and hard to read, hard to parse and hard to follow (IMHO). If before there was "only a handful of people capable", now it will be less.
> It's ugly and hard to read, hard to parse and hard to follow (IMHO)
I could say the same about C++, it usually comes down to what you learned first.
But I disagree about less people being capable of writing it. I don't have any stats to back this up but for developers new to systems programming, Rust is more approachable than C++. The compiler does much more work in ensuring you don't screw up.
I could say the same about C++, it usually comes down to what you learned first.
But I disagree about less people being capable of writing it. I don't have any stats to back this up but for developers new to systems programming, Rust is more approachable than C++. The compiler does much more work in ensuring you don't screw up.
Rust won't make solving the bugs easier, but it will prevent almost all memory safety bugs from compiling at all.
> Managed languages like Java and Kotlin are the best option for Android app development.
I've read accounts of Rust used in mobile along with Flutter UI. Not sure how successful that work has been.
I've read accounts of Rust used in mobile along with Flutter UI. Not sure how successful that work has been.
if anyone at Google wants a fantastic canary-in-the-coal-mine to test Rust support, my absolute #1 most go-to target would be to figure out how you can do a good job supporting Rusty_v8 and Deno in general. denoland@rusty_v8#270 awaits![1] onwards & upward!
[1] https://github.com/denoland/rusty_v8/pull/270
[1] https://github.com/denoland/rusty_v8/pull/270
Why not use Go?
Go uses garbage collection, which is why for some low-level systems programming tasks it's not really a suitable replacement for C or C++.
Depends on the anti-GC bias,
https://www.f-secure.com/en/consulting/foundry
https://tinygo.org/
https://www.f-secure.com/en/consulting/foundry
https://tinygo.org/
It's not just the GC, Go's Interfaces are very heavy weight (including in TinyGo). Its green threads are very heavy weight (including in TinyGo)... Oh. And a GC is really unacceptable in a kernel (though not necessarily in the rest of an OS) for all sorts of reasons, not just throughput but also latency and severe issues with FFI and concurrency and frankly how the heck are you even supposed to run a GC without a runtime in the first place? And speaking of which: TinyGo has a massive runtime that requires a sophisticated OS like FreeRTOS already installed on the system, not just for GC but for greenthreads, and, well, everything.
Just because nowadays even MCU's are so powerful that you can just waste an insane amount of resources on TamaGo and just because TamaGo seems to run on custom hardware/firmware that specifically provides it what it needs to directly run on the hardware without help from C/C++/Rust, doesn't mean Go is particularly viable for Android today.
Even more importantly. Google actually wants to use a safe language for Android. Go isn't safe the moment you go parallel/concurrent/async. Go also isn't memory safe for important OS tasks like direct memory access. Go also isn't null safe. Go also isn't typestate safe... Rust have all of the above mentioned safety in all of the above mentioned situations.
Just because nowadays even MCU's are so powerful that you can just waste an insane amount of resources on TamaGo and just because TamaGo seems to run on custom hardware/firmware that specifically provides it what it needs to directly run on the hardware without help from C/C++/Rust, doesn't mean Go is particularly viable for Android today.
Even more importantly. Google actually wants to use a safe language for Android. Go isn't safe the moment you go parallel/concurrent/async. Go also isn't memory safe for important OS tasks like direct memory access. Go also isn't null safe. Go also isn't typestate safe... Rust have all of the above mentioned safety in all of the above mentioned situations.
Ah the Rust advocay.
- Direct memory access requires unsafe.
- Rust is also not null safe, unless you validate all unsafe code blocks
- Rust is also not typestate safe, unless explicitly programmed that way
As for GC being or not acceptable on kernel, plenty of worksation OSes have proven it works, only politics have hindered their further development.
Go was just the example at hand, I would have used D or any other better prepared GC systems programming language.
And then there are those bare metal JVM and Erlang runtimes deployed into production, even in matters of life and death like weapon control systems in battleships and missile tracking radars.
- Direct memory access requires unsafe.
- Rust is also not null safe, unless you validate all unsafe code blocks
- Rust is also not typestate safe, unless explicitly programmed that way
As for GC being or not acceptable on kernel, plenty of worksation OSes have proven it works, only politics have hindered their further development.
Go was just the example at hand, I would have used D or any other better prepared GC systems programming language.
And then there are those bare metal JVM and Erlang runtimes deployed into production, even in matters of life and death like weapon control systems in battleships and missile tracking radars.
Is Fuchsia (and Flutter by Extension) dead since the Oracle thing has worked out now?
No. Fuschia would not have helped - they would still have to license Oracle APIs in order to maintain compatibility with their own, derived APIs.
Google's actual workaround to Oracle's lawsuit was to use OpenJDK, which also massively improved their Java compatibility. OpenJDK is produced by Oracle and under GPL, so using it (or just relicensing Apache Harmony as GPL) cuts off the API copyright claims (as you now have a license).
Google's actual workaround to Oracle's lawsuit was to use OpenJDK, which also massively improved their Java compatibility. OpenJDK is produced by Oracle and under GPL, so using it (or just relicensing Apache Harmony as GPL) cuts off the API copyright claims (as you now have a license).
What, if anything, do these have to do with each other?
Some people have imagined that Fuchsia's destiny is to replace Android, and some of them believe that's because Android is tainted by Java and Google will want to sidestep. This obviously made more sense in a world where Oracle gets billions of dollars "royalties" from Google for the fact that Android apps are written in Java, which the US Supreme Court decided is maybe one step crazier than they felt ready for.
I don't understand this thought process. Java and Kotlin apps run just fine on Fuchsia (or so I have heard). Fuchsia is only relevant for lower layers of the stack. Notably device drivers.
Please re-read the parent more closely. What you are talking about has no bearing on the scenario presented. The parent said:
> Some people have imagined that Fuchsia's destiny is to replace Android, and some of them believe that's because Android is tainted by Java and Google will want to sidestep.
Whether or not Fuchsia can or might run Java or Kotlin apps, as you talk about, is not what this scenario is about. The apocalyptic scenario some believed about Fuchsia was that it existed as an OS that didn't need Java. If it can host & run Java or Kotlin apps? That might have had to go, that might have had to be cut. But Fuchsia could have survived.
Fuchsia is independent of Java and Kotlin. To run a Zircon kernel, to run a Fuchsia OS required no Java technologies. One maybe could/can use Java to write apps (having trouble stablishing this premise), but Java is not a dependency for this OS. With Fuchsia, Google could have given up Java, if they had to. What you @CameronNemo are talking about- the ability to use Java and Kotlin to write Fuchia apps, if true[1], is something that could have been sacrificed without affecting the rest of Fuchsia. I'd also point out that Fuchsia does not advertise Java or Kotlin support[2], regardless of whatever you may have heard, but it was at least once rumored of, so I can sympathize.
This is 99.9998% a conspiracy theory & in my estimation you'd have to be daft to think Fuchsia was only an escape hatch (there's a ton of great technical work breaking from Linux & more in it), but the "Fuchsia is only to escape Java if we have to" scenario sketched was at least technically plausible & sound, checked out. It has no Java dependencies.
[1] https://9to5google.com/2018/11/09/fuchsia-friday-java-borrow...
[2] https://fuchsia.dev/fuchsia-src/concepts
> Some people have imagined that Fuchsia's destiny is to replace Android, and some of them believe that's because Android is tainted by Java and Google will want to sidestep.
Whether or not Fuchsia can or might run Java or Kotlin apps, as you talk about, is not what this scenario is about. The apocalyptic scenario some believed about Fuchsia was that it existed as an OS that didn't need Java. If it can host & run Java or Kotlin apps? That might have had to go, that might have had to be cut. But Fuchsia could have survived.
Fuchsia is independent of Java and Kotlin. To run a Zircon kernel, to run a Fuchsia OS required no Java technologies. One maybe could/can use Java to write apps (having trouble stablishing this premise), but Java is not a dependency for this OS. With Fuchsia, Google could have given up Java, if they had to. What you @CameronNemo are talking about- the ability to use Java and Kotlin to write Fuchia apps, if true[1], is something that could have been sacrificed without affecting the rest of Fuchsia. I'd also point out that Fuchsia does not advertise Java or Kotlin support[2], regardless of whatever you may have heard, but it was at least once rumored of, so I can sympathize.
This is 99.9998% a conspiracy theory & in my estimation you'd have to be daft to think Fuchsia was only an escape hatch (there's a ton of great technical work breaking from Linux & more in it), but the "Fuchsia is only to escape Java if we have to" scenario sketched was at least technically plausible & sound, checked out. It has no Java dependencies.
[1] https://9to5google.com/2018/11/09/fuchsia-friday-java-borrow...
[2] https://fuchsia.dev/fuchsia-src/concepts
Escaping Java doesn't make sense to me now that the Oracle stuff is resolved. Java is a great choice for phone apps. Huge developer base with good productivity. And it's quite fast for a high level language.
And the backwards compatibility. One of the codebases I work on has loads of untouched 15 year old code that runs fine on Java 16. Good luck doing that in JS, Python, or really any other popular language besides C/C++
And the backwards compatibility. One of the codebases I work on has loads of untouched 15 year old code that runs fine on Java 16. Good luck doing that in JS, Python, or really any other popular language besides C/C++
ok but it got resolved less than 2 days ago.
far far more so, leaping to javas defense doesn't feel related to what this thread has been about. the thread has been about strategy & tactics, about escaping with something if the legal situation did go bad.
and as I stated, it doesn't seem like Google's Fuchsia does support Java. it might have been an idle notion, a legacy Android compatibility layer, but Java does not seem to be part of the modern Fuchsia attempt. at all. from what I can find. whatever pluses Java has, it doesn't seem like it's relevant enough to warrant any modern Fuchsia support. and the legacy Android support seems dubious / maybe non existent.
again I think the "fuchsia was just an escape hatch if Google had to have a non java based os" folks are a bit whack. but it was also a legit thread. even post Oracle trial, a break from 15 years of legacy & an underlying >2x as old posix api, for a more security conscious premise, sounds great, long long overdue.
Java has upsides but I don't think this thread should have to suffer that radical change in discussion. it muddies what was being talked about.
far far more so, leaping to javas defense doesn't feel related to what this thread has been about. the thread has been about strategy & tactics, about escaping with something if the legal situation did go bad.
and as I stated, it doesn't seem like Google's Fuchsia does support Java. it might have been an idle notion, a legacy Android compatibility layer, but Java does not seem to be part of the modern Fuchsia attempt. at all. from what I can find. whatever pluses Java has, it doesn't seem like it's relevant enough to warrant any modern Fuchsia support. and the legacy Android support seems dubious / maybe non existent.
again I think the "fuchsia was just an escape hatch if Google had to have a non java based os" folks are a bit whack. but it was also a legit thread. even post Oracle trial, a break from 15 years of legacy & an underlying >2x as old posix api, for a more security conscious premise, sounds great, long long overdue.
Java has upsides but I don't think this thread should have to suffer that radical change in discussion. it muddies what was being talked about.
Then downvote and move on. Nobody is forcing you to read replies buried at the bottom of the thread going off on tangents.
Fuscia and Java are both Android and tech related, don't see the problem. And the previous comment about Fuscia is just as off topic as mine, if not moreso. Java is at the core of Android and Fuscia hasn't made it out of the lab
Fuscia and Java are both Android and tech related, don't see the problem. And the previous comment about Fuscia is just as off topic as mine, if not moreso. Java is at the core of Android and Fuscia hasn't made it out of the lab
Google is also porting Android Runtime to Fuchsia, just like they did with ChromeOS.
Also this never made sense, if Google really wanted to go down that path, they could have already replaced Android with ChromeOS for quite some time now.
Also this never made sense, if Google really wanted to go down that path, they could have already replaced Android with ChromeOS for quite some time now.
> they could have already replaced Android with ChromeOS for quite some time now.
ChromeOS is only partly their platform. They don't really maintain control over it. Because, like the iphone 1, it's web. It's a shared platform.
Also, why just escape Java when you can escape the GPL Linux kernel too!! Bonus!
Fuchsia OS really is an existential hedge, a fallback position unlike all else. I still am willing to guess though that it was argued & sold on it's technics. If anything, allowing good engineers a great attractive project: that's what it takes to attract & retain talent in the competitive tech world, giving some of your engineers really wild greenfield chances. Ideally in a highly visible manner. But a capabilities based OS free from Java, free from GPL: it's a good corporate-safe technically-strong starting point to "organize the world's information, make it accessible and useful" (yet secure).
ChromeOS is only partly their platform. They don't really maintain control over it. Because, like the iphone 1, it's web. It's a shared platform.
Also, why just escape Java when you can escape the GPL Linux kernel too!! Bonus!
Fuchsia OS really is an existential hedge, a fallback position unlike all else. I still am willing to guess though that it was argued & sold on it's technics. If anything, allowing good engineers a great attractive project: that's what it takes to attract & retain talent in the competitive tech world, giving some of your engineers really wild greenfield chances. Ideally in a highly visible manner. But a capabilities based OS free from Java, free from GPL: it's a good corporate-safe technically-strong starting point to "organize the world's information, make it accessible and useful" (yet secure).
The Web is slowly being turned into ChromeOS, Firefox hardly matters, and Safari is only relevant in a couple of countries where iOS has market presence.
Besides ChromeOS has its own specific APIs as well anyway.
Besides ChromeOS has its own specific APIs as well anyway.
But Linux does not need Java either... The kernel/OS is orthogonal to the app layer.
:rolleyes: we were talking about Android. Almost all Android apps are Java. Java & Kotlin are the official languages of Android. Large parts of Android are written in Java.
We've explained again and again and again how the theory present is that Google needed an escape hatch from Java. The crude theory of Fuchsia being an escape hatch for Google, a way to get off Java, is at least true, in that it would help them get off Java. Which their most successful OS, Android, is extremely reliant upon.
Yes, underneath, Android uses Linux. Until recently it's been a fairly mangled, hacked up Linux, but allegedly Android keeps getting closer to being able to run on mainline Linux. But Android is not Linux. Android is Linux plus lots and lots and lots of subsystems: display & audio subsystems, all sorts of other stuff, endless apis & platform & device subsystems. A huge amount of them being written in Java. Google's #1 OS was extremely coupled to Java. This is in no way debateable? Spend a couple minutes doing the most cursory of investigations & you should see: Google was extremely tied to Java. Still are.
We've explained again and again and again how the theory present is that Google needed an escape hatch from Java. The crude theory of Fuchsia being an escape hatch for Google, a way to get off Java, is at least true, in that it would help them get off Java. Which their most successful OS, Android, is extremely reliant upon.
Yes, underneath, Android uses Linux. Until recently it's been a fairly mangled, hacked up Linux, but allegedly Android keeps getting closer to being able to run on mainline Linux. But Android is not Linux. Android is Linux plus lots and lots and lots of subsystems: display & audio subsystems, all sorts of other stuff, endless apis & platform & device subsystems. A huge amount of them being written in Java. Google's #1 OS was extremely coupled to Java. This is in no way debateable? Spend a couple minutes doing the most cursory of investigations & you should see: Google was extremely tied to Java. Still are.
That escapte hatch already existed and they ported Android Runtime to run alognside ChromeOS, instead of bringing ChromeOS to the phones.
Just like they have been porting Android Runtime to Fuchsia during the last couple of years.
Just like they have been porting Android Runtime to Fuchsia during the last couple of years.
> :rolleyes:
The sass is not appreciated. This entire thread has been quite frustrating. I feel like we are arguing past each other. I don't think this is a useful use of my time.
The sass is not appreciated. This entire thread has been quite frustrating. I feel like we are arguing past each other. I don't think this is a useful use of my time.
It has been frustrating. My frustration blew over, apologies.
I think it has been useful. I'm sorry you are still unmoved. The situation seems clear to me, and quite heavily elaborated. I still don't see what your points are. There seems to be a fixation on Fuchsia as only a low level thing, but that's just Zircon, the smallest piece; Flutter & IPC & other subsystems make up a very different higher level system that is clearly attempting to be a new native app stack owned entirely by Google with licensing they control.
I think it has been useful. I'm sorry you are still unmoved. The situation seems clear to me, and quite heavily elaborated. I still don't see what your points are. There seems to be a fixation on Fuchsia as only a low level thing, but that's just Zircon, the smallest piece; Flutter & IPC & other subsystems make up a very different higher level system that is clearly attempting to be a new native app stack owned entirely by Google with licensing they control.
[deleted]
[deleted]
The Fuchsia security model is a significant departure from classical Unix derivatives. They will presumably want to keep it going for that benefit alone.
Those people keep forgetting that Google has been porting Android Runtime (ART) to run on Fuschia for a while now.
[deleted]
One of the good things about putting Rust in android is that it's a great way to encourage AARCH64 support in the language.
ARM themselves helped do the legwork here; aarch64-unknown-linux-gnu is already a Tier 1 supported platform thanks to their work https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
But it is true that there are other aarch64-* triples that could move up (including aarch64-linux-android). Getting to Tier 1 is extremely hard due to the CI requirements.
But it is true that there are other aarch64-* triples that could move up (including aarch64-linux-android). Getting to Tier 1 is extremely hard due to the CI requirements.
What's hard about CI? I would naively expect it to be just a virtual machine that you spin up and run jobs on, and Android doesn't seem hard to virtualize (Google's official tools even include this).
For Android, specifically, that might be okay. I was speaking more generally. I am not sure if the compiler team has a specific "real hardware for tier 1" policy or not; we do use virtualization for some platforms, I believe. Probably a useful thing to clarify either way.
There's also second order effects; the CI has to succeed on all tests on all platforms, which means that if your PR breaks on a platform you don't have expertise with, you need help, and we need to be prepared to give that help to you in a timely manner. Again, probably easier on Android, but a general barrier.
There's also second order effects; the CI has to succeed on all tests on all platforms, which means that if your PR breaks on a platform you don't have expertise with, you need help, and we need to be prepared to give that help to you in a timely manner. Again, probably easier on Android, but a general barrier.
[0] https://news.ycombinator.com/item?id=26647981