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

71–80 of 124 posts

Re: Bare-metal Rust in Android

#71

Post by hactually »

okanat wrote: post #67
digdugdirk wrote: post #53

Earlier quoted context omitted.

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

I disagree - working with CGo is really easy and predictable in behaviour.

Cross compilation for Go is no more difficult than cross compiling Rust + .so / .a files

Re: Bare-metal Rust in Android

#72

Post by trealira »

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

Re: Bare-metal Rust in Android

#73

Post by defer »

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.

You can generate binder wrappers from aidl, that would work. This is fairly common when doing platform work (for those like me who work on the operating system rather than on apps).

However, this would be a terrible idea because usually the android api is stable at the Java wrappers (I.e. ActivityManager), not at the aidl level, which would make this very fragile for app development across a multitude of devices and platform versions.

Re: Bare-metal Rust in Android

#74

Post by kibwen »

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.

C was definitely a player in the 70s and 80s (when it (and Unix) still had a lot of healthy competition), but it didn't attain its current veneer of ubiquity until approximately the early 90s (after being standardized in 1989). Javascript was derided as a joke until 2009 brought ECMAScript 5 and Node.js. Java's rise was relatively fast, but Java also had the benefit of the most concerted corporate ad campaign in the history of programming languages (how many programming languages have you seen advertised on TV? https://www.youtube.com/watch?v=FpirOZe1Cgk )

Re: Bare-metal Rust in Android

#75

Post by p4ul »

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.

This is exactly right! I believe C's popularity grew so quickly because of its correlation with the popularity of Unix and its descendants. And yes, Sun pushing Java very hard certainly grew its adoption.

JavaScript is a really interesting case; initially, I don't think it was really taken very seriously. It was mostly tolerated because of its privileged status as part of the web platform. But since so much has moved from desktop application to the browser, that privileged status has proven all the more valuable!

Re: Bare-metal Rust in Android

#76

Post by kllrnohj »

izacus wrote: post #49
grishka wrote: post #11

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

> Those "native" APIs you mention in most cases just call back to Java APIs under the hood

Some do, but most don't.

Re: Bare-metal Rust in Android

#77

Post by tialaramex »

p4ul wrote: post #75
trealira wrote: post #72

Earlier quoted context omitted.

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.

This is exactly right! I believe C's popularity grew so quickly because of its correlation with the popularity of Unix and its descendants. And yes, Sun pushing Java very hard certainly grew its adoption. JavaScript is a really interesting case; initially, I don't think it was really taken very seriously. It was mostly tolerated because of its privileged status as part of the web platform. But since so much has moved…

> with the popularity of Unix and its descendants

and with that the Internet. In 1990 UK higher education sites had "high speed" (megabit sometimes!) networking but they used X.25 "Coloured Book" protocols. There were a handful of well developed applications for services such as email, but experimenting with novel software on X.25 was difficult. In 1991 JANET (the people providing these network services to Universities, then and now) began JIPS, an experiment to try out Internet protocols.

Enthusiasm for JIPS was enormous. You could buy or, since you have an electronics department and an essentially inexhaustible supply of nerds, build, a Unix computer, and just like, write your own BSD sockets software. I hear a guy over a CERN has invented a World Wide Web we should check out... In less than a year JIPS ceased to be an "experiment" and by the time I arrived at a University a few years later X.25 was deprecated and few people cared that it was still technically available somewhere.

Re: Bare-metal Rust in Android

#78

Post by Thorrez »

ireallywantthat wrote: post #5

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?

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

Re: Bare-metal Rust in Android

#79

Post by diogenes4 »

pjmlp wrote: post #40
frankjr wrote: post #2

Is there similar effort from Apple?

Apparently people keep forgetting Swift exists. "CppNow 2023:Introducing a Memory-Safe Successor Language in Large C++ Code Bases" https://www.youtube.com/watch?v=lgivCGdmFrw

Sorry, what does swift have to do with this?

Re: Bare-metal Rust in Android

#80

Post by diogenes4 »

rohandhruva wrote: post #19
ireallywantthat wrote: post #5

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?

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

Post reply on HN