Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bare-metal Rust in Android

security.googleblog.com

Post reply on HN
Print view View original

41–50 of 124 posts

Re: Bare-metal Rust in Android

#41

Post by pjmlp »

flohofwoe wrote: post #35
cogman10 wrote: post #16

Earlier quoted context omitted.

I don't think it's a good idea, mainly because android is multiplatform and rust, by it's nature, is only available for what it's built for. Unless you are giving google your rust code to compile, your app will be limited on it's reach. All that said. Rust doesn't have a GC so it'd (likely) have a lower memory consumption and could possibly be lighter on the CPU. Native compilation helps mainly with startup time and…

> Unless you are giving google your rust code to compile, your app will be limited on it's reach. Android has supported native code in apps for a long time via the Android NDK, mainly to enable game development. The Android team seems to hate the NDK, but the alternative is to have no games on the platform, so they can't simply kill it. > ...[native] ... It's not exactly great for runtime performance as it takes away…

Thankfully ART not only uses JIT, it also has an AOT compiler with PGO data shared across all devices in the ecosystem via the Play Store.

In practice, people should learn how Android actually works.

Re: Bare-metal Rust in Android

#42

Post by pjmlp »

galangalalgol wrote: post #29
cogman10 wrote: post #16

Earlier quoted context omitted.

I don't think it's a good idea, mainly because android is multiplatform and rust, by it's nature, is only available for what it's built for. Unless you are giving google your rust code to compile, your app will be limited on it's reach. All that said. Rust doesn't have a GC so it'd (likely) have a lower memory consumption and could possibly be lighter on the CPU. Native compilation helps mainly with startup time and…

VM warmup isn't consistently a thing, in fact for over a decade there has been plenty of observation of the reverse, that runtime optimization often slows performance. Systems languages (c/c++/rust) consistently outperform warmed up managed languages. And that is ok, it doesn't mean we shouldn't have managed languages, but they are slower.

Managed languages also exist in AOT with PGO data.

Re: Bare-metal Rust in Android

#43

Post by grishka »

flohofwoe wrote: post #38
grishka wrote: post #11

Earlier quoted context omitted.

You can technically create an Android app without any Java code. There are native APIs for graphics and input. However, as these are intended for games, you get a window into which you can draw... something. With OpenGL, for example. You don't get access to Android's regular UI framework. You will also have to go through the Java layer to do many things you might want to do — like requesting permissions or launching…

You can call into any Android Java API from native code using JNI. It's not exactly convenient, but you are not limited to the C APIs exposed by the NDK.

Many Android APIs expect you to extend classes and implement interfaces for things like callbacks. You can't do that with JNI alone, you will have to have a .dex of your own anyway.

Re: Bare-metal Rust in Android

#44

Post by ncruces »

voxl wrote: post #24
rohandhruva wrote: post #19

Earlier quoted context omitted.

Tell me you've never done any Android development, without telling me... This is such a low-effort "take" without any effort to justify _why_ you'd want something like this. There's a high amount of impedance mismatch trying to write GUIs in a non-GC language like Rust which _has_ to run on what's essentially a Java VM (ART). At least with a language like Go, it somewhat makes sense, and has been attempted: https://g…

What does a GC have anything to do with it? You can reference count all the pointers if you want, you can expose JVM pointers in Rust where Rust doesn't manage the heap memory. There are plenty of easy solutions to work with the JVM

If you're willing to work with the JVM (i.e. through JNI), there's really nothing stopping you.

You can 100% make entire apps using nothing but C, C++, or whatever, as long as you're willing to interface with the JVM that's created for you to access Android APIs.

But the Android API is a JVM API. There's no getting around that. At this point, it's another OS (i.e. not Android) if it doesn't have Java in it.

Re: Bare-metal Rust in Android

#45

Post by jeroenhd »

rohandhruva wrote: post #19
ireallywantthat wrote: post #5

Ok, now enable us to let create Android Applications entirely in Rust (including the GUI). Let's get rid of Kotlin/Java monopoly in Android App development. Shall we?

Tell me you've never done any Android development, without telling me... This is such a low-effort "take" without any effort to justify _why_ you'd want something like this. There's a high amount of impedance mismatch trying to write GUIs in a non-GC language like Rust which _has_ to run on what's essentially a Java VM (ART). At least with a language like Go, it somewhat makes sense, and has been attempted: https://g…

There's a reason Chrome is mostly written in C++. Android's JVM system is a collection of Java wrappers around C++ libraries. There's some overhead in that translation layer, and it's unfortunate that you can't skip it. Even Google's own Flutter uses a C++ engine to run Dart applications.

Kotlin (and Java) is fast enough for many applications, but even with the recent advancements in ART, does have overhead compared to pure native code. I can't think of a reason why the API interaction overhead would pose a problem, but if Google themselves can find use cases for almost JVM-less apps, I'm sure there are reasons to give a Rust version a try.

Re: Bare-metal Rust in Android

#46

Post by jd3 »

jonpalmisc wrote: post #28
dagmx wrote: post #4

Earlier quoted context omitted.

Specifically a dialect called Firebloom (supposedly anyway) https://saaramar.github.io/iBoot_firebloom/

Firebloom is more of a custom compiler/toolchain than a dialect of C—apart from annotations to relate pointer+length parameters, etc., it is still just C.

Reminds me of this blurb from djb's qmail security guarantee [0]:

> I've mostly given up on the standard C library. Many of its facilities, particularly stdio, seem designed to encourage bugs. A big chunk of qmail is stolen from a basic C library that I've been developing for several years for a variety of applications. The stralloc concept and getln() make it very easy to avoid buffer overruns, memory leaks, and artificial line length limits.

[0]: http://cr.yp.to/qmail/guarantee.html

Re: Bare-metal Rust in Android

#48

Post by izacus »

az09mugen wrote: post #47

I may have wrong assumptions, but I find it funny they didn't use Golang. Is it not capable of doing the same thing ? Anyway, happy to see rust being adopted for that usage.

No, Go isn't appropriate for these things. Use the best tool for the job

Re: Bare-metal Rust in Android

#49

Post by izacus »

grishka wrote: post #11
ireallywantthat wrote: post #5

Ok, now enable us to let create Android Applications entirely in Rust (including the GUI). Let's get rid of Kotlin/Java monopoly in Android App development. Shall we?

You can technically create an Android app without any Java code. There are native APIs for graphics and input. However, as these are intended for games, you get a window into which you can draw... something. With OpenGL, for example. You don't get access to Android's regular UI framework. You will also have to go through the Java layer to do many things you might want to do — like requesting permissions or launching…

That's not really what's going on. Those "native" APIs you mention in most cases just call back to Java APIs under the hood. For better or worse, most of what Android is is written in Java. There's no hidden "C++" layer of Android to access.

Re: Bare-metal Rust in Android

#50

Post by izacus »

jeroenhd wrote: post #45
rohandhruva wrote: post #19

Earlier quoted context omitted.

Tell me you've never done any Android development, without telling me... This is such a low-effort "take" without any effort to justify _why_ you'd want something like this. There's a high amount of impedance mismatch trying to write GUIs in a non-GC language like Rust which _has_ to run on what's essentially a Java VM (ART). At least with a language like Go, it somewhat makes sense, and has been attempted: https://g…

There's a reason Chrome is mostly written in C++. Android's JVM system is a collection of Java wrappers around C++ libraries. There's some overhead in that translation layer, and it's unfortunate that you can't skip it. Even Google's own Flutter uses a C++ engine to run Dart applications. Kotlin (and Java) is fast enough for many applications, but even with the recent advancements in ART, does have overhead compared…

> Android's JVM system is a collection of Java wrappers around C++ libraries.

This isn't even remotely true and it's obvious if you'd ever looked closely at Android. This take is as bizarre as saying that whole web/JS/React ecosystem is "just" wrappers on top of Skia.

Post reply on HN