Welcome to Comprehensive Rust

Most system APIs are only exposed in the JVM environment without native equivalents. You do need a JVM language to do anything meaningful. Either that, or you'll have to use JNI.

This. Rust is quite pleasant to use and once some barriers are overcome quite productive. Not Python fast dev speed, but easily Go levels of productive for me. I rarely fight the borrow checker unless building tricky data structures. It will still stump me once in a while with lifetimes, but the trade off is so worth it to have memory safety guarantees and know there are no foot guns like C code would have. And if you are just cranking something out you can write code a little less idiomatically and of efficiently for quick scripts or smaller throwaway CLI tools. Rust prefers a more functional style but you can just as easily make it not so.

The bash timing exploit makes everyone focus just on how cleverly evil it can be, and forget the big picture that it's about trusting the Rust org not to screw you.

(BTW, you can run `curl | sh` in a VM or with a modified bash to intercept the code and catch the bash script in the act, so it's not actually as sneaky as people believe).

If you think the Rust org is going to pwn you in a clever sneaky way, then you can't use Rust or any Rust-containing products.

In the end, you're pulling hundreds of MBs of binaries that you won't review, they're compiled from over 15 million lines of code that I don't believe you'd ever review either. Reviewing just the first 10 lines of code gives you nothing. A smoke test in a sandbox is also worthless, since a binary could detect being run that way, or delay the attack, or attack by specifically miscompiling your code (see Reflections on Trusting Trust).

In the end, you have to trust the Rust org, all of it.

I dont have first hand knowledge, but I've been in the space for 10 years and wrote Go, Java, Kotlin, so here is my take.

Kotlin made a huge effort to stay compatible with Java. You can call Kotlin code from Java and Java code from Kotlin, so orgs could migrate their apps piece by piece. The only real incompatibilities that I've experienced were when going from C code via JNI into Kotlin. All sorts of really weird issues creep up.

There was no boiling the ocean in any of the large apps I worked on at Amazon and Meta - just add Kotlin and see how it goes, it's a really easy sell to tech VPs. First we added Kotlin just for the unit tests, then for small features and eventually with Google releasing Jetpack with Kotlin extensions, for all new apps and features.

Kotlin also improved upon existing painpoints in Java and provided a ton of syntactic sugar for things that were tedious in Java. For example, proper get/set syntax for fields, data classes with autogenerated equals/hashcode, explicit nullability for types, val with 'final' semantics to get rid of all the final variables, fields in interfaces, top level functions, etc. All the functional stuff in it is nice too.

Go is much leaner than Kotlin. The VM or performance is not an issue - Kotlin generates entire classes for simple syntax, to make things convenient and compatible, but the bytecode is pretty bloated.

I imagine that Google had sufficient resources to make a GoJava translation layer (though Go would have needed generics) but transitioning a huge API like Android is already a large effort, and if the language isn't fully compatible with the existing code, it would have added an order of magnitude of complexity, so Kotlin was a much easier sell.

In my opinion, migrating to Dart would have been more practical than Go (as evidenced by Flutter), so thats the real head-scratcher. It would have been easy for Java devs to learn Dart because the OOP concepts translate directly.

Other factors:

Google already had a relationship with JetBrains because of Android Studio.

The Oracle Google lawsuit was happening at the time and I speculate that Google needed to show to Oracle they can move off of Java. Kotlin happened to be available.