Bare-metal Rust in Android • Hacker News Board

Re: Bare-metal Rust in Android

#51

Post by izacus » Mon, Oct 09, 2023, 10:13 PM UTC

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…

[flagged]

Re: Bare-metal Rust in Android

#52

Post by gpm » Mon, Oct 09, 2023, 10:16 PM UTC

asrael_io wrote: post #32

SuaveSteve wrote: post #20

The Doom of programming languages? Rust must be run everywhere with no irony.

Yeah but does Doom run on rust-analyzer?

Rust analzyer type checks rust and type checking is turing complete... it's only a matter of time.

Re: Bare-metal Rust in Android

#53

Post by digdugdirk » Mon, Oct 09, 2023, 10:29 PM UTC

izacus wrote: post #48

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.

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?

Re: Bare-metal Rust in Android

#54

Post by pix128 » Mon, Oct 09, 2023, 10:34 PM UTC

digdugdirk wrote: post #53

izacus wrote: post #48

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

Go is garage collected

Re: Bare-metal Rust in Android

#55

Post by sangnoir » Mon, Oct 09, 2023, 10:36 PM UTC

digdugdirk wrote: post #53

izacus wrote: post #48

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

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.

Re: Bare-metal Rust in Android

#56

Post by izacus » Mon, Oct 09, 2023, 10:45 PM UTC

digdugdirk wrote: post #53

izacus wrote: post #48

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

The non-JVM code used in mentioned context will run in environments where yet another GC fighting the JVM GC isn't desired or have to be a shared library talking to existing JVM code. While you can use Go to build libraries with C calling convention, it's not the most supported use case and it shows in ergonomics. This also includes standard Go types and standard library which don't fit nicely into a model where code needs to talk a lot with JVM world.

It's possible... But it feels like screwing screws with a knife. It's doable, but noone from the language designers, stl designers and library developers are really thinking about that use case.

Rust on the other hand fits very well into the model where it needs to be just a piece of a bigger whole - it's been built that way ("system" programming language) and it doesn't come with GC that will fight with JVM or Binder lifetimes, compatible type system and plenty of libraries that help develop libraries on an embedded platform. When building the language, Rust designers consider this as one of the main use cases of the language and it shows with how much less hassle it is to work with.

The fact that it easily fits into existing C/C++ codebases helps too.

Re: Bare-metal Rust in Android

#57

Post by kupopuffs » Mon, Oct 09, 2023, 10:50 PM UTC

1f60c wrote: post #15

Ideally, Android wouldn’t have any security vulnerabilities, but that’s not realistic. Rust won’t prevent every bug (and it’s even possible to cause segmentation faults in an ostensibly safe language like Python), but “better” is still a huge leap forward.

just.... no more buffers overflown

Re: Bare-metal Rust in Android

#58

Post by adastra22 » Mon, Oct 09, 2023, 11:04 PM UTC

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

Swift is a different class than rust though.

Re: Bare-metal Rust in Android

#59

Post by adastra22 » Mon, Oct 09, 2023, 11:15 PM UTC

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?

You can though? I maintain a rust-only app.

Re: Bare-metal Rust in Android

#60

Post by vitiral » Mon, Oct 09, 2023, 11:39 PM UTC

kupopuffs wrote: post #57

1f60c wrote: post #15

Ideally, Android wouldn’t have any security vulnerabilities, but that’s not realistic. Rust won’t prevent every bug (and it’s even possible to cause segmentation faults in an ostensibly safe language like Python), but “better” is still a huge leap forward.

just.... no more buffers overflown

Or dead pointers used, or race conditions