I found adoption of Rust being slow, but it has started to grow.
It's incredibly fast compared to most programming languages.
Bare-metal Rust in Android
61–70 of 124 posts
Re: Bare-metal Rust in Android
#62The Doom of programming languages? Rust must be run everywhere with no irony.
People want to replace C, which runs anywhere. Rust must also be able to.
Re: Bare-metal Rust in Android
#63Earlier quoted context omitted.
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 thin…
[flagged]
[deleted]
Re: Bare-metal Rust in Android
#64I don't get mailing lists. See this https://lists.denx.de/pipermail/u-boot/2022-March/478466.htm...
So where is the patch?
Re: Bare-metal Rust in Android
#65Earlier quoted context omitted.
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://g…
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…
> 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.
Re: Bare-metal Rust in Android
#66Earlier quoted context omitted.
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://g…
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 thin…
> 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.
Re: Bare-metal Rust in Android
#67Earlier quoted context omitted.
No, Go isn't appropriate for these things. Use the best tool for the job
Can you please explain why Go isn't appropriate here?
Not just garbage collection but also the way hardware work is done with languages that allow you to write one-to-one memory representations in order to be able to drive raw interfaces of hardware. A GC language almost always comes with a reference based type system that hides the very interfaces you'd like to access (fast) and adds deserialization overhead which has visible performance and battery life effects.
The other reason is C interoperation. All of the common systems rely on C. C is not just a programming language. Since 80s everybody designs systems on top of C. We ended up with OSes written in C that ship their tightly integrated C compiler that outputs binaries optimized for C's memory layout and primitives that the very same OS runs on silicon that's optimized to run C fast. C unfortunately became the meta-language of the low level APIs.
Go's interoperability with C is out of hell. Its green-thread scheduler doesn't play well with C. The foreign function interface is defined in the comments (!) of a source file and making CGo work on custom cross toolchains is full of hard to solve compiler errors.
Rust can operate at the same level as C easily and it has all the low level primitives. C interoperability is a core language function that's part of the syntax and standard library. It solves many gotchas of C without compromising speed.
Re: Bare-metal Rust in Android
#68I don't get mailing lists. See this https://lists.denx.de/pipermail/u-boot/2022-March/478466.htm... So where is the patch?
the git-send-email format for a patch series is the cover letter (the one you are looking at) and then one message per commit (subsequent emails in the thread).
mailman is not the best interface for reading these; people would normally use their mail client, or specialised tools like patchwork.
e.g. this series on patchwork: https://patchwork.ozlabs.org/project/uboot/cover/20220320114...
(click 'expand' in the 'series' line)
Re: Bare-metal Rust in Android
#69I don't get mailing lists. See this https://lists.denx.de/pipermail/u-boot/2022-March/478466.htm... So where is the patch?
00/12 is the description. The rest of them are 01, 02, etc...
It all works great if you are actually subscribed to the mailing list. The kernel "lore" site has a better interface to the mailing lists and can download stuff as mbox files - https://lore.kernel.org/all/20220329165900.1139885-1-ascull@...
There is also a service called "patchwork" that collects these patches in a web page format
Re: Bare-metal Rust in Android
#70Earlier quoted context omitted.
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…
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.
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.