Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bare-metal Rust in Android

security.googleblog.com

Post reply on HN
Print view View original

91–100 of 124 posts

Re: Bare-metal Rust in Android

#91

Post by defrost »

pjmlp wrote: post #87
okanat wrote: post #67

Earlier quoted context omitted.

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 o…

> Since 80s everybody designs systems on top of C. More like since the 1990's, as outside UNIX during the 1980's no one cared about C, and mostly thanks to the GNU Manifesto and FOSS uptake that took the steam out of C++ adoption being pushed by Apple, IBM and Microsoft. There is firmware in production written in Go, https://www.withsecure.com/en/solutions/innovative-security-...

I did a lot of cross platform development work from 1982 onwards and 1987 was very much the year of C for Intel | DOS machines - they were cheap (comparitively), widely available and Borlands Turbo C was a fully integrated IDE that was affordable (and|or pirated) with some outstanding manuals.

Between that and their ASM for low level work, C took off in a big way and Pascal sharply dwindled in popularity (although it still hung on for a long time, even up to the present).

https://en.wikipedia.org/wiki/Borland_Turbo_C

There were better more expensive tools, but that was the product that planted a flag for widespread C development.

Re: Bare-metal Rust in Android

#92

Post by pjmlp »

defrost wrote: post #91
pjmlp wrote: post #87

Earlier quoted context omitted.

> Since 80s everybody designs systems on top of C. More like since the 1990's, as outside UNIX during the 1980's no one cared about C, and mostly thanks to the GNU Manifesto and FOSS uptake that took the steam out of C++ adoption being pushed by Apple, IBM and Microsoft. There is firmware in production written in Go, https://www.withsecure.com/en/solutions/innovative-security-...

I did a lot of cross platform development work from 1982 onwards and 1987 was very much the year of C for Intel | DOS machines - they were cheap (comparitively), widely available and Borlands Turbo C was a fully integrated IDE that was affordable (and|or pirated) with some outstanding manuals. Between that and their ASM for low level work, C took off in a big way and Pascal sharply dwindled in popularity (although it…

In Europe, in a MS-DOS world without cross-platform considerations, it took until Windows 3.x release, and Watcom C++ with its DOS extender for folks to really care about C and C++.

In fact, we used Turbo C 2.0 to prepare our code samples to deploy them into a single Xenix computer shared across the whole school, and that was it, nothing else.

Re: Bare-metal Rust in Android

#93

Post by izacus »

okanat wrote: post #70
izacus wrote: post #49

Earlier quoted context omitted.

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.

Sure, and some NDK APIs do exactly that. But you're still just using IPC to call into services written in Java, just using a different approach.

Re: Bare-metal Rust in Android

#94

Post by lormayna »

outworlder wrote: post #62
SuaveSteve wrote: post #20

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

Rust is a replacement for C++; if you look for a C replacement you should look on Zig

Re: Bare-metal Rust in Android

#95

Post by samus »

trealira wrote: post #72
outworlder wrote: post #61

Earlier quoted context omitted.

It's incredibly fast compared to most programming languages.

I wasn't around for it, but didn't C grow fast during the 70s and 80s? And didn't Java and JavaScript also spread pretty fast? Of course, Java was explicitly promoted and advertised by Sun, and JavaScript played off of Java's popularity and later became a web standard.

JavaScript was a web standard right from the beginning. Its popularity grew together with the web itself by virtue of being the only programming language that could be counted on to be available on websites.

Flash and Java both required plugins, didn't integrate well with the rest of the website, were quite heavyweight, and frequently got bad publicity due to security bugs.

Of course, browsers themselves also had them aplenty, but at the end of the day one can't use the internet without one :)

Re: Bare-metal Rust in Android

#96

Post by ireallywantthat »

pjmlp wrote: post #89
ireallywantthat wrote: post #23

Earlier 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…

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.

Re: Bare-metal Rust in Android

#97

Post by ireallywantthat »

rohandhruva wrote: post #66
ireallywantthat wrote: post #23

Earlier 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…

> 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 sound…

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

Re: Bare-metal Rust in Android

#98

Post by ireallywantthat »

rohandhruva wrote: post #65
jeroenhd wrote: post #45

Earlier quoted context omitted.

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…

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

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

Re: Bare-metal Rust in Android

#99

Post by pjmlp »

ireallywantthat wrote: post #96
pjmlp wrote: post #89

Earlier quoted context omitted.

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 Andr…

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.

Re: Bare-metal Rust in Android

#100

Post by kramerger »

outworlder wrote: post #61
theusus wrote: post #7

I found adoption of Rust being slow, but it has started to grow.

It's incredibly fast compared to most programming languages.

I think Java was much faster.

Rust is 8 years old and is still not fully stable (you need nightly for a lot of projects). Projects are planning and adding support but not many are actually using it yet.

Java was the hotest thing on the job market after only 3-4 years.

Post reply on HN