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?
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://gioui.org/
All this Java/Kotlin bashing is getting really old, especially for a forum like this one.
I know that tailscale's android application is written in it but i don't think gioui is great for android apps.
> Tell me you've never done any Android development, without telling me...All this Java/Kotlin bashing is getting really old, especially for a forum like this one.
Ok, this one hurts. Why are you attacking me instead of defending your stance. All are allowed to have opinions and I am allowed to have one(It's sad to explain this to someone on forum like this one). I dream of Linux-desktop kinda situation where you can program in any language you want, where you are not hindered by any platform/framework, where you have complete freedom and where you don't want to be bothered/(vendor locked-in) by Bigcorps(looking at you Google services framework).
> write GUIs in a non-GC language like Rust which _has_ to run on what's essentially a Java VM (ART).
Haha, non-GC languages power the GUIs on Android fyi. Jetpack compose is powered by Skia. Chromium is powered by Skia. Skia is C++.
Please do your own research before commenting low-effort replies.
Skia is not something you use to write apps: it's a graphics engine, essentially something you use to draw polygons on the screen.
> Why are you attacking me instead of defending your stance. All are allowed to have opinions and I am allowed to have one
I apologize if any of this sounded like an attack. I was trying to be funny with that meme-like sentence formation, but I don't profess to disparage anyone's skills or opinions.
> I dream of Linux-desktop kinda situation where you can program in any language you want, where you are not hindered by any platform/framework, where you have complete freedom
Linux desktop is certainly not the dream world you describe. Practically, you _have_ to pick a toolkit: one of GTK / KDE / Qt / electron / etc. Maybe it helps to think of Android's toolkit (Views or Compose) as one of those.
So, AOSP team can obviously create Rust framework ontop of Skia(or tinyskia,femtovg,etc.), make Android APIs available in Rust, Create proper widget framework and let us create Android Applications written entirely in Rust.
> Linux desktop is certainly not the dream world you describe. Practically, you _have_ to pick a toolkit: one of GTK / KDE / Qt / electron / etc. Maybe it helps to think of Android's toolkit (Views or Compose) as one of those.
I know what I am talking about. This is exactly the freedom that I was talking about. I am able to choose any framework/toolkit I want. If i don't want any framework, that's fine too. You don't have that freedom in Android. Everything has to be routed via Java ecosystem that AOSP constructed.
Please do your own research on how AOSP is actually implemented.
> behind JNI walls, and even NDK code is obliged to make use of JNI to call into them.
What i originally told was "enable us to let create Android Applications entirely in Rust (including the GUI)" . Surely Google and AOSP projects can remove the restrictions that you mentioned and provide us alternative to Kotlin/Java ecosystem which is what i really want and hope them to do. Smartphones powered by Android are capable computers and freedom for App development is appreciated.
Please don't mention once again that "X is not implemented in AOSP. Y is required to make use of JNI calls into them". You know that this is superficial barrier and can be overcome/corrected if they wanted to.
Android Brillo demise already proved that isn't what Google cares about.
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.
Gio UI is an immediate-mode UI, and immediate-mode UIs map very nicely to Rust. egui is quite expressive and easy to use. https://www.egui.rs/
If you had pointed at something like GTK, then yes, there is a big impedance mismatch there.
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.
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.
And for that same reason, you don't see many apps do the same thing. Any time Chrome needs to request a permission (access files, location, etc), it _has_ to use the system-provided Java APIs.
> Even Google's own Flutter uses a C++ engine to run Dart applications.
As do most games, so you can essentially think of Flutter as a game engine that renders apps.
> Android's JVM system is a collection of Java wrappers around C++ libraries.
As others have mentioned, this is very much not the case.
My original comment was against this. Why should this be the case?
Yea, security is not a concern. Apparently.
Sorry, what does the idea of a user interface have to do with garbage collection? They seem entirely unrelated at first blush, and it's not difficult to find GUI code written in rust.
Here's all the APIs you get: https://developer.android.com/ndk/reference?hl=en
However, this would be a terrible idea because usually the android api is stable at the Java wrappers (I.e. ActivityManager), not at the aidl level, which would make this very fragile for app development across a multitude of devices and platform versions.
Some do, but most don't.
https://github.com/rust-mobile/ndk
Which has the tools to do this.
Does anyone have any experience creating production apps with Tauri? Seems like a sane alternative to Electron, especially if they can target all major platforms and keep the promise of smaller footprints.
(fka Apache Cordova, fka PhoneGap)
Haven’t android apps been compiled to native code since like 2012? (I actually don’t know, I left android a while ago and stopped caring what they do)
Kotlin is just Java with extra steps.
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.
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.
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.
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.
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 better runtime performance than AOT compiled code, but in practice that usually turns out as wishful thinking.
In practice, people should learn how Android actually works.
JIT + AOT with PGO data shared across all Android devices on the planet, gets the best of both worlds.