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

81–90 of 124 posts

Re: Bare-metal Rust in Android

#81

Post by diogenes4 »

jeroenhd wrote: post #45
rohandhruva wrote: post #19

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

Yea, security is not a concern. Apparently.

Re: Bare-metal Rust in Android

#82

Post by tialaramex »

vitiral wrote: post #60
kupopuffs wrote: post #57

Earlier quoted context omitted.

just.... no more buffers overflown

Or dead pointers used, or race conditions

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

Data races are because it's not possible to deliver what you intuitively expect from a computer which is capable of multiple notionally simultaneous operations. They have no analogue in our real world experience, which is why they're baffling for real programmers on non-trivial software. The world stops making sense.

Most programming languages which allow parallel computation have data races. In C and C++ they're just Undefined Behaviour. Game over. In Go they're sometimes not Undefined Behaviour if your race only touches very simple things like integers. In Java, interestingly, they're always defined behaviour but it doesn't help very much because the behaviour is extremely hard to reason about. Still, your program does do at least something sane even if your head hurts when you think about it. In safe Rust this never happens.

Re: Bare-metal Rust in Android

#83

Post by jon_richards »

tialaramex wrote: post #82
vitiral wrote: post #60

Earlier quoted context omitted.

Or dead pointers used, or race conditions

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.

Re: Bare-metal Rust in Android

#84

Post by pjmlp »

adastra22 wrote: post #58
pjmlp wrote: post #40

Earlier quoted context omitted.

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

Swift is a different class than rust though.

Not for Apple,

> Swift was designed from the outset to be safer than C-based languages, and eliminates entire classes of unsafe code.

-- https://www.swift.org/about/

> Swift is a successor to the C, C++, and Objective-C languages

-- https://developer.apple.com/swift/

Re: Bare-metal Rust in Android

#85

Post by pjmlp »

diogenes4 wrote: post #79
pjmlp wrote: post #40

Earlier quoted context omitted.

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?

Swift is Apple's answer to replacing C derived languages, they don't need Rust.

> Swift is a successor to the C, C++, and Objective-C languages -- https://developer.apple.com/swift/

They also mention plans for kernel and firmware targets on that talk.

Re: Bare-metal Rust in Android

#86

Post by pjmlp »

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.

Not at all, it was only relevant to UNIX users.

Re: Bare-metal Rust in Android

#87

Post by pjmlp »

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…

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

Re: Bare-metal Rust in Android

#89

Post by pjmlp »

ireallywantthat wrote: post #23
rohandhruva wrote: post #19

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

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.

Re: Bare-metal Rust in Android

#90

Post by pjmlp »

ncruces wrote: post #44
voxl wrote: post #24

Earlier quoted context omitted.

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

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.

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.
Post reply on HN