10 ms·

Rust in the Android Platform

262 points by theafh 6y ago

thesuperbigfrog 6y ago
>> 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.)
- steveklabnik 6y ago
  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!
  - k__ 6y ago
    Shouldn't Rust be able to hook into the NDK already anyways?
    - steveklabnik 6y ago
      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.
    - david_allison 6y ago
      Yep: https://github.com/mozilla/rust-android-gradle https://github.com/mozilla/rust-android-gradle
  - larsberg 6y ago
    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.
  - tialaramex 6y ago
    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.
- souldeux 6y ago
  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 https://kotlinlang.org/docs/native-overview.html
  - The_rationalist 6y ago
    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.
    - pjmlp 6y ago
      Kotlin/Native is also being redone after being proven that not following the same memory model as the JVM was a bad decision.
- nindalf 6y ago
  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.
  - berkes 6y ago
    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".
    - Argorak 6y ago
      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 https://mozilla.github.io/glean/book/index.html
      - berkes 6y ago
        > 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.
        Argorak 6y ago
        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.
- stusmall 6y ago
  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.
- username_my1 6y ago
  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 ...)
  - carlhjerpe 6y ago
    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.
    - throwaway189262 6y ago
      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
    - steveklabnik 6y ago
      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.
    - pjmlp 6y ago
      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.html https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020.... https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021.html https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....
- kitsunesoba 6y ago
  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.
  - throwaway189262 6y ago
    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.
ed25519FUUU 6y ago
One of the good things about putting Rust in android is that it's a great way to encourage AARCH64 support in the language.
- steveklabnik 6y ago
  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.html 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.
  - yjftsjthsd-h 6y ago
    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).
    - steveklabnik 6y ago
      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.
scoopr 6y ago
The android new bluetooth stack rust rewrite was discussed recently[0] [0] https://news.ycombinator.com/item?id=26647981 https://news.ycombinator.com/item?id=26647981
domano 6y ago
Is Fuchsia (and Flutter by Extension) dead since the Oracle thing has worked out now?
- bluejekyll 6y ago
  What, if anything, do these have to do with each other?
  - deleted 6y ago
    [deleted]
  - tialaramex 6y ago
    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.
    - CameronNemo 6y ago
      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.
      - rektide 6y ago
        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-borrowing-from-android/ https://9to5google.com/2018/11/09/fuchsia-friday-java-borrow... [2] https://fuchsia.dev/fuchsia-src/concepts https://fuchsia.dev/fuchsia-src/concepts
Dowwie 6y ago
> 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.
pritish16 6y ago
Why not use Go?
- elihu 6y ago
  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++.
  - pjmlp 6y ago
    Depends on the anti-GC bias, https://www.f-secure.com/en/consulting/foundry https://www.f-secure.com/en/consulting/foundry https://tinygo.org/ https://tinygo.org/
    - dexterlemmer 6y ago
      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.
      - pjmlp 6y ago
rektide 6y ago
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 https://github.com/denoland/rusty_v8/pull/270
scoutt 6y ago
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.
- bschwindHN 6y ago
  > 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.
- 3836293648 6y ago
  Rust won't make solving the bugs easier, but it will prevent almost all memory safety bugs from compiling at all.

262 points by theafh 6y ago

>> 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.)

steveklabnik 6y ago
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!
- k__ 6y ago
  Shouldn't Rust be able to hook into the NDK already anyways?
  - steveklabnik 6y ago
    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.
  - david_allison 6y ago
    Yep: https://github.com/mozilla/rust-android-gradle https://github.com/mozilla/rust-android-gradle
- larsberg 6y ago
  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.
- tialaramex 6y ago
  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.
souldeux 6y ago
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 https://kotlinlang.org/docs/native-overview.html
- The_rationalist 6y ago
  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.
  - pjmlp 6y ago
    Kotlin/Native is also being redone after being proven that not following the same memory model as the JVM was a bad decision.
nindalf 6y ago
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.
- berkes 6y ago
  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".
  - Argorak 6y ago
    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 https://mozilla.github.io/glean/book/index.html
    - berkes 6y ago
      > 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.
      - Argorak 6y ago
        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.
stusmall 6y ago
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.
username_my1 6y ago
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 ...)
- carlhjerpe 6y ago
  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.
  - throwaway189262 6y ago
    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
  - steveklabnik 6y ago
    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.
  - pjmlp 6y ago
    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.html https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020.... https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021.html https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....
kitsunesoba 6y ago
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.
- throwaway189262 6y ago
  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.

ed25519FUUU 6y ago

One of the good things about putting Rust in android is that it's a great way to encourage AARCH64 support in the language.

steveklabnik 6y ago
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.html 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.
- yjftsjthsd-h 6y ago
  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).
  - steveklabnik 6y ago
    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.

scoopr 6y ago

The android new bluetooth stack rust rewrite was discussed recently[0] [0] https://news.ycombinator.com/item?id=26647981 https://news.ycombinator.com/item?id=26647981

domano 6y ago

Is Fuchsia (and Flutter by Extension) dead since the Oracle thing has worked out now?

bluejekyll 6y ago
What, if anything, do these have to do with each other?
- deleted 6y ago
  [deleted]
- tialaramex 6y ago
  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.
  - CameronNemo 6y ago
    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.
    - rektide 6y ago
      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-borrowing-from-android/ https://9to5google.com/2018/11/09/fuchsia-friday-java-borrow... [2] https://fuchsia.dev/fuchsia-src/concepts https://fuchsia.dev/fuchsia-src/concepts

Dowwie 6y ago

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

pritish16 6y ago

Why not use Go?

elihu 6y ago
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++.
- pjmlp 6y ago
  Depends on the anti-GC bias, https://www.f-secure.com/en/consulting/foundry https://www.f-secure.com/en/consulting/foundry https://tinygo.org/ https://tinygo.org/
  - dexterlemmer 6y ago
    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.
    - pjmlp 6y ago

rektide 6y ago

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 https://github.com/denoland/rusty_v8/pull/270

scoutt 6y ago

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.

bschwindHN 6y ago
> 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.
3836293648 6y ago
Rust won't make solving the bugs easier, but it will prevent almost all memory safety bugs from compiling at all.