People who care about this issue, especially in the last few years, have been leaning into a "memory safe language" vs "non memory safe language" framing. This is because it gets at the root of the issue, which is safe by default vs not safe by default. It tries to avoid pointing fingers at, or giving recommendations for, particular languages, by instead putting the focus on the root cause.
In the specific case of Android, the subject of this post, I'm not aware of attempts to move into other MSLs than those. But I also don't follow Android development generally, but I do follow these posts pretty closely, and I don't remember any of them talking about stuff other than Rust or Kotlin.
Don’t forget the old, boring one: Java.
I assume the reason that Go doesn’t show up so much is that most Android processes have their managed, GC’d Java-ish-virtual-machine world and their native C/C++ world. Kotlin fits in with the former and Rust fits in with the latter. Go is somewhat of its own thing.
Google also published their perspective on memory safety in https://security.googleblog.com/2024/03/secure-by-design-goo..., which also goes over some of the memory-safe languages in use like Java, Go and Rust.
For that reason I'd use OCaml as well even though it has GC, because it has sum types. That is, if I ever learn OCaml properly.
Across Google, Go is used for some system software, but I haven't seen it used in Android.
> memory safe languages
Edit: I forgot Golang!
Rust and Swift are the two most widely used.
Interestingly, Swift had interoperating with C as an explicit design goal, while Rust had data race safety as a design goal.
Now we have data race safety added in the latest version of Swift, and Rust looking to improve interoperability with C.
How much it gets there, depends on squizzing juice out of LLVM backend for Swift code.
Chris Lattner, the creator of both LLVM and Swift, has referred to Swift as “syntactic sugar for LLVM.” They are deeply tied together.
The amount of Swift code in Apple's operating systems has increased every year.
https://blog.timac.org/2023/1019-state-of-swift-and-swiftui-...
Lattner gave an interview looking at the advantages of reference counting over the sort of garbage collection used in languages like Java, C#, and Go while still avoiding error-prone manual memory management.
> ARC has clear advantages in terms of allowing Swift to scale down to systems that can’t tolerate having a garbage collector, for example, if you want to write firmware in Swift. I think that it does provide a better programming model where programmers think just a little bit about memory.
Apple has also optimized their custom ARM core to further reduce the cost.
> retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1
https://blog.metaobject.com/2020/11/m1-memory-and-performanc...
That said, Swift is working toward adding a future opt-in Rust inspired approache to memory management for those who need it.
https://forums.swift.org/t/manifesto-ownership/5212
https://forums.swift.org/t/a-roadmap-for-improving-swift-per...