I didn't bash Java/Kotlin. In fact, I have written few android apps in Kotlin, Java and I also have fiddled with Jetpack compose, JNI and NDK (I have also played with mpv's Opengl/Vulkan's rendering on Android if that matters to you). I don't want to share the projects of mine because i don't want to reveal my identity.

> https://gioui.org/

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.

He's attacking you because you're spewing things that are fundamentally misguided without even seeming to try to look at basic structure of how Android is put together.

Show some basic ability if you want people to engage with your takes, there's already too much ignorant opinions spewed out with assumed authority on this site.

> Haha, non-GC languages power the GUIs on Android fyi. Jetpack compose is powered by Skia. Chromium is powered by Skia. Skia is C++.

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.

> Skia is not something you use to write apps: it's a graphics engine, essentially something you use to draw polygons on the screen.

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.

Calm down with that "Haha", all those native libraries powering Android are behind JNI walls, and even NDK code is obliged to make use of JNI to call into them.

Please do your own research on how AOSP is actually implemented.

Calmed down.

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

If you want freedom for app development buy a Pinephone or Librem 5 device.

Android Brillo demise already proved that isn't what Google cares about.

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

Actually there was such OS, Android Brillo and the OEM market said no, hence why it got replaced with Android Things, which re-introduced Java again.

> At least with a language like Go, it somewhat makes sense, and has been attempted: https://gioui.org/

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.

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.

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

> There's a reason Chrome is mostly written in C++.

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.

> it _has_ to use the system-provided Java APIs.

My original comment was against this. Why should this be the case?

> There's a reason Chrome is mostly written in C++

Yea, security is not a concern. Apparently.

They didn't have Rust around when they started.

That doesn't change anything. Security was simply never what chrome (or webkit to be fair) was built around compared to speed of the insanely inefficient browser stack.

At the same time, GUIs really don’t work nicely/as idiomatically without a GC. Most Rust GUIs do immediate mode only, which is a much more easier problem, and you won’t have to “argue” with the borrow checker constantly. But it would drain the battery of a phone in an hour (it would be the equivalent of running a proper 3D game as your notes app or whatever).

> There's a high amount of impedance mismatch trying to write GUIs in a non-GC language like Rust

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.

Immediate mode vs retained mode. It is not a hard requirement, but the borrow checker definitely makes the latter more complex.