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

111–120 of 124 posts

Re: Bare-metal Rust in Android

#111

Post by flohofwoe »

pjmlp wrote: post #41
flohofwoe wrote: post #35

Earlier quoted context omitted.

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

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.

This just seems to prove my point that AOT is usually better than JIT?

Re: Bare-metal Rust in Android

#112

Post by tempaccount420 »

diogenes4 wrote: post #81
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++ Yea, security is not a concern. Apparently.

They didn't have Rust around when they started.

Re: Bare-metal Rust in Android

#113

Post by sureglymop »

kaba0 wrote: post #106
az09mugen wrote: post #47

I may have wrong assumptions, but I find it funny they didn't use Golang. Is it not capable of doing the same thing ? Anyway, happy to see rust being adopted for that usage.

Go is not a low-level language. They already have Java which sits at the exact same level.

They have kotlin which can even compile to native binaries that run without a VM.

Re: Bare-metal Rust in Android

#114

Post by kaba0 »

sureglymop wrote: post #113
kaba0 wrote: post #106

Earlier quoted context omitted.

Go is not a low-level language. They already have Java which sits at the exact same level.

They have kotlin which can even compile to native binaries that run without a VM.

That can only compile a very limited subset of normal code.

But no need for that, Android already does AOT.

Re: Bare-metal Rust in Android

#115

Post by pjmlp »

flohofwoe wrote: post #111
pjmlp wrote: post #41

Earlier quoted context omitted.

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.

This just seems to prove my point that AOT is usually better than JIT?

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.

Re: Bare-metal Rust in Android

#116

Post by pjmlp »

sangnoir wrote: post #55
digdugdirk wrote: post #53

Earlier quoted context omitted.

Can you please explain why Go isn't appropriate here?

Binary size, for one. The blog mentions a binary file grew from 220kb (C) to over 400kb (Rust). I also doubt a garbage-collected language work very well for drivers that require precise timing (MMIO) and/or control over memory allocation.

It worked rather well for Xerox PARC, TI, Genera and others, had they not mismanaged their products, or fighting against workstations being built with a free beer OS.

Re: Bare-metal Rust in Android

#117

Post by sigsev_251 »

jonpalmisc wrote: post #28
dagmx wrote: post #4

Earlier quoted context omitted.

Specifically a dialect called Firebloom (supposedly anyway) https://saaramar.github.io/iBoot_firebloom/

Firebloom is more of a custom compiler/toolchain than a dialect of C—apart from annotations to relate pointer+length parameters, etc., it is still just C.

I mean, the annotations are supposed to be simple C attributes wrapped in macros, so even them are just C

Re: Bare-metal Rust in Android

#118

Post by samus »

sangnoir wrote: post #55
digdugdirk wrote: post #53

Earlier quoted context omitted.

Can you please explain why Go isn't appropriate here?

Binary size, for one. The blog mentions a binary file grew from 220kb (C) to over 400kb (Rust). I also doubt a garbage-collected language work very well for drivers that require precise timing (MMIO) and/or control over memory allocation.

The blog immediately put that statement into context, stating that the binary file actually ended up replacing most of their stack. At the end of the day, they ended up with about the same size binary size. Also, they were not even really trying to optimize for size.

Re: Bare-metal Rust in Android

#119

Post by samus »

jon_richards wrote: post #83
tialaramex wrote: post #82

Earlier quoted context omitted.

Nope. Race conditions are an ordinary fact about our universe, Rust has those. (Safe) Rust doesn't have data races which are much stranger. Race conditions are just an ordinary effect where several actors are doing things and you need to be careful to ensure that they're co-ordinated properly if that's important. If Alice and Bob both conclude there's no milk, both then go to the store and buy milk, now there is too…

Speaking of race conditions, I recently looked into the current state of “make sure something is in the db and then retrieve it”. Absolutely bonkers that “on conflict do select” still doesn’t exist.

PostgreSQL's `INSERT... ON CONFLICT DO NOTHING` gets you there most of the way. You can add a `RETURNING` clause which will return the record that it inserted. But the manual reads like nothing will be returned if no insertion actually happened. So you'd have to follow up with a `SELECT`.
Post reply on HN