7 ms·
>> 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
by 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 agoThey 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 agoShouldn't Rust be able to hook into the NDK already anyways?
- steveklabnik 6y agoI 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 agoYep: https://github.com/mozilla/rust-android-gradle https://github.com/mozilla/rust-android-gradle
- larsberg 6y agoThat'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 agoRight, 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 agoI 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 agoGraalVM 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 agoKotlin/Native is also being redone after being proven that not following the same memory model as the JVM was a bad decision.
- nindalf 6y agoThe 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 agoWhile 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 agoThe 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 agoWell, 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 agoIf 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 agoI 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 agoWhat 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 agoMulti 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 agoMany 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 agoThe 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 agoI 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 agoNewer 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.