3 ms·
A few thoughts: People who care about this issue, especially in the last few years, have been leaning into a "memory safe language" vs "non memory safe languag
by steveklabnik 2y ago
A few thoughts:
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.
- amluto 2y ago> 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.
- vvanders 2y agoAndroid has a surprising amount of core OS functionality in boring managed Java code. ART/Dalvik are quite impressive combined with a few other clever tricks to make a system that ran in a pretty small footprint.
- pjmlp 2y agoIncluding mixed mode JIT/AOT compilation with PGO feedback, which many still aren't aware of.
- pdimitar 2y agoI would think one of the reasons that Golang is not utilized is its lack of tagged unions. Another might be that it has a runtime and a GC which is typically undesirable for systems (as in: very close to the metal) software.
- deleted 2y ago[deleted]
- pjmlp 2y agoGo doesn't have any role on Android, other than being used on a build system that uses Go as its DSL.
- deleted 2y ago[deleted]