News for hackers. Stuff that matters.
Re:Eliminating Memory Safety Vulnerabilities at the Source by steveklabnik on Wednesday September 25, 2024 @05:48PM (#41652208)
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.

Re:Eliminating Memory Safety Vulnerabilities at the Source by amluto on Wednesday September 25, 2024 @09:47PM (#41653704)
> 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.

Re:Eliminating Memory Safety Vulnerabilities at the Source by vvanders on Wednesday September 25, 2024 @10:15PM (#41653854)
Android 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.
Re:Eliminating Memory Safety Vulnerabilities at the Source by pjmlp on Friday September 27, 2024 @03:28AM (#41667341)
Including mixed mode JIT/AOT compilation with PGO feedback, which many still aren't aware of.
Re:Eliminating Memory Safety Vulnerabilities at the Source by pdimitar on Thursday September 26, 2024 @05:55AM (#41656467)
I 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.
Re:Eliminating Memory Safety Vulnerabilities at the Source by pjmlp on Thursday September 26, 2024 @08:47AM (#41657768)
Go doesn't have any role on Android, other than being used on a build system that uses Go as its DSL.