28 ms·

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

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?

wredue 3y ago
What would rust achieve aside from just enabling another, entirely distinct from the existing workflow, language? 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)
- cogman10 3y ago
  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.
  - shopvaccer 3y ago
    >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.
    - wiseowise 3y ago
      > 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.
  - galangalalgol 3y ago
    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.
    - pjmlp 3y ago
      Managed languages also exist in AOT with PGO data.
  - flohofwoe 3y ago
    > 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 better runtime performance than AOT compiled code, but in practice that usually turns out as wishful thinking.
    - pjmlp 3y ago
      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.
      - flohofwoe 3y ago
        This just seems to prove my point that AOT is usually better than JIT?
        pjmlp 3y ago
        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.
- rstat1 3y ago
  Not having to use Java or any of its weird derivatives.
  - smith7018 3y ago
    I implore you to try Kotlin; it’s a fantastic language and is a wonder to code in
    - rstat1 3y ago
      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.
    - TheDesolate0 3y ago
      I implore you to try Rust. Kotlin is just Java with extra steps.
grishka 3y ago
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 other apps' activities. Here's all the APIs you get: https://developer.android.com/ndk/reference?hl=en https://developer.android.com/ndk/reference?hl=en
- nologic01 3y ago
  You can also "outsource" the Java based interaction with Android to somebody else, Qt style? https://doc.qt.io/qt-6/android-getting-started.html https://doc.qt.io/qt-6/android-getting-started.html
- flohofwoe 3y ago
  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.
  - grishka 3y ago
    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.
- izacus 3y ago
  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.
  - okanat 3y ago
    In theory it is possible to write raw Binder calls to various Android services, skipping JNI in many places. However, it is basically rewriting the entire OS API and structure from scratch.
azemetre 3y ago
Isn't this what Tauri wants to achieve? At least it's on the roadmap I mean. https://tauri.app/ https://tauri.app/ 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.
- asrael_io 3y ago
  Not quite production, but I was on a paid contract on a PoC. I would say back at 1.0, mobile was pretty painful and signing of any binary dependencies was up to you. It looks like they addressed signing in 1.5 and I haven't picked it back up to check out the mobile experience.
- flohofwoe 3y ago
  The traditional alternative to Electron on mobile platforms is Capacitor (which uses the system webview, so in that sense it's closer to Tauri): https://capacitorjs.com/ https://capacitorjs.com/ (fka Apache Cordova, fka PhoneGap)
Vt71fcAqt7 3y ago
You can already. The ndk allows any language to be compiled to android. For rust see https://github.com/rust-mobile/ndk https://github.com/rust-mobile/ndk Which has the tools to do this.
rohandhruva 3y ago
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://gioui.org/ https://gioui.org/ All this Java/Kotlin bashing is getting really old, especially for a forum like this one.
- ireallywantthat 3y ago
  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/ 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.
  - izacus 3y ago
    [flagged]
    - deleted 3y ago
      [deleted]
deleted 3y ago
[deleted]
wiseowise 3y ago
Why?
adastra22 3y ago
You can though? I maintain a rust-only app.
Thorrez 3y ago
While not a bad idea, it doesn't have the urgency of C->Rust because Java is already memory safe.

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?

wredue 3y ago

What would rust achieve aside from just enabling another, entirely distinct from the existing workflow, language? 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)

cogman10 3y ago
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.
- shopvaccer 3y ago
  >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.
  - wiseowise 3y ago
    > 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.
- galangalalgol 3y ago
  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.
  - pjmlp 3y ago
    Managed languages also exist in AOT with PGO data.
- flohofwoe 3y ago
  > 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 better runtime performance than AOT compiled code, but in practice that usually turns out as wishful thinking.
  - pjmlp 3y ago
    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.
    - flohofwoe 3y ago
      This just seems to prove my point that AOT is usually better than JIT?
      - pjmlp 3y ago
        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.
rstat1 3y ago
Not having to use Java or any of its weird derivatives.
- smith7018 3y ago
  I implore you to try Kotlin; it’s a fantastic language and is a wonder to code in
  - rstat1 3y ago
    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.
  - TheDesolate0 3y ago
    I implore you to try Rust. Kotlin is just Java with extra steps.

grishka 3y ago

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 other apps' activities. Here's all the APIs you get: https://developer.android.com/ndk/reference?hl=en https://developer.android.com/ndk/reference?hl=en

nologic01 3y ago
You can also "outsource" the Java based interaction with Android to somebody else, Qt style? https://doc.qt.io/qt-6/android-getting-started.html https://doc.qt.io/qt-6/android-getting-started.html
flohofwoe 3y ago
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.
- grishka 3y ago
  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.
izacus 3y ago
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.
- okanat 3y ago
  In theory it is possible to write raw Binder calls to various Android services, skipping JNI in many places. However, it is basically rewriting the entire OS API and structure from scratch.

azemetre 3y ago

Isn't this what Tauri wants to achieve? At least it's on the roadmap I mean. https://tauri.app/ https://tauri.app/ 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.

asrael_io 3y ago
Not quite production, but I was on a paid contract on a PoC. I would say back at 1.0, mobile was pretty painful and signing of any binary dependencies was up to you. It looks like they addressed signing in 1.5 and I haven't picked it back up to check out the mobile experience.
flohofwoe 3y ago
The traditional alternative to Electron on mobile platforms is Capacitor (which uses the system webview, so in that sense it's closer to Tauri): https://capacitorjs.com/ https://capacitorjs.com/ (fka Apache Cordova, fka PhoneGap)

Vt71fcAqt7 3y ago

You can already. The ndk allows any language to be compiled to android. For rust see https://github.com/rust-mobile/ndk https://github.com/rust-mobile/ndk Which has the tools to do this.

rohandhruva 3y ago

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://gioui.org/ https://gioui.org/ All this Java/Kotlin bashing is getting really old, especially for a forum like this one.

ireallywantthat 3y ago
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/ 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.
- izacus 3y ago
  [flagged]
  - deleted 3y ago
    [deleted]

deleted 3y ago

[deleted]

wiseowise 3y ago

Why?

adastra22 3y ago

You can though? I maintain a rust-only app.

Thorrez 3y ago

While not a bad idea, it doesn't have the urgency of C->Rust because Java is already memory safe.