5 ms·

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 someth

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]
- rohandhruva 3y ago
  > 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.
  - ireallywantthat 3y ago
    > 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.
- pjmlp 3y ago
  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.
  - ireallywantthat 3y ago
    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.
    - pjmlp 3y ago
      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.
voxl 3y ago
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
- ncruces 3y ago
  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.
  - pjmlp 3y ago
    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.
lcfcjs 3y ago
[dead]
ForkMeOnTinder 3y ago
> At least with a language like Go, it somewhat makes sense, and has been attempted: https://gioui.org/ 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/ https://www.egui.rs/ If you had pointed at something like GTK, then yes, there is a big impedance mismatch there.
jeroenhd 3y ago
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.
- izacus 3y ago
  > 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.
- rohandhruva 3y ago
  > 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.
  - ireallywantthat 3y ago
    > it _has_ to use the system-provided Java APIs. My original comment was against this. Why should this be the case?
- diogenes4 3y ago
  > There's a reason Chrome is mostly written in C++ Yea, security is not a concern. Apparently.
diogenes4 3y ago
> 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.
- kaba0 3y ago
  Immediate mode vs retained mode. It is not a hard requirement, but the borrow checker definitely makes the latter more complex.

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]
rohandhruva 3y ago
> 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.
- ireallywantthat 3y ago
  > 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.
pjmlp 3y ago
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.
- ireallywantthat 3y ago
  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.
  - pjmlp 3y ago
    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.

voxl 3y ago

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

ncruces 3y ago
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.
- pjmlp 3y ago
  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.

lcfcjs 3y ago

[dead]

ForkMeOnTinder 3y ago

> At least with a language like Go, it somewhat makes sense, and has been attempted: https://gioui.org/ 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/ https://www.egui.rs/ If you had pointed at something like GTK, then yes, there is a big impedance mismatch there.

jeroenhd 3y ago

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.

izacus 3y ago
> 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.
rohandhruva 3y ago
> 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.
- ireallywantthat 3y ago
  > it _has_ to use the system-provided Java APIs. My original comment was against this. Why should this be the case?
diogenes4 3y ago
> There's a reason Chrome is mostly written in C++ Yea, security is not a concern. Apparently.

diogenes4 3y ago

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

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