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 memory consumption. It's not exactly great for runtime performance as it takes away some key optimizations.

Another benefit of rust assuming you are distributing binaries is you'll be able to use the latest version of Rust rather than being pinned to older versions of the SDK with partial support based on the whims of google.

>mainly because android is multiplatform and rust, by it's nature, is only available for what it's built for

Android is one platform: android. I thought rust worked across multiple operating systems.

>Rust doesn't have a GC so it'd (likely) have a lower memory consumption and could possibly be lighter on the CPU.

So what? I have never used G.C.

>Native compilation helps mainly with startup time and memory consumption. It's not exactly great for runtime performance as it takes away some key optimizations.

That is fair I suppose

I think the main benefit of rust/c++/ndk on android is that I can just port desktop programs and I don't have to learn android's java/kotlin and sdk.

> Android is one platform: android. I thought rust worked across multiple operating systems.

Operating systems, not architectures. You'd have to cross-compile your application 4 times if you want to support all arms and x86s.

> I think the main benefit of rust/c++/ndk on android is that I can just port desktop programs and I don't have to learn android's java/kotlin and sdk.

It's not "just" port desktop programs. Android doesn't even use glibc.

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.

> 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 some key optimizations.

In theory a JIT might produce faster code than AOT compiled code, but in practice that usually turns out as wishful thinking.

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.

This just seems to prove my point that AOT is usually better than JIT?

Not really, because not only it uses PGO, which most people using AOT languages never bother to learn, it only AOT compiles the code paths that JIT validated as being used, instead of the whole application.

JIT + AOT with PGO data shared across all Android devices on the planet, gets the best of both worlds.

Not having to use Java or any of its weird derivatives.

I implore you to try Kotlin; it’s a fantastic language and is a wonder to code in

Kotlin is what I meant by "weird derivatives"

But anyway I have used it. Didn't understand why it existed then. Still don't.

All these weird languages and UI frameworks where you write hundreds of lines of code just do simple UI layouts, no thanks.