Eliminating Memory Safety Vulnerabilities at the Source

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]