5 ms·
They talk about "memory safe languages (MSL)" plural, as if there is more than one, but only explicitly name Rust as the MSL they're transitioning to and improv
by SkyMarshal 2y ago
They talk about "memory safe languages (MSL)" plural, as if there is more than one, but only explicitly name Rust as the MSL they're transitioning to and improving interoperability with. They also mention Kotlin in the context of improving Rust<>Kotlin interop, which also has some memory-safe features but maybe not to same extent as Rust. Are those the only two Google uses, or are there others they could be referring to?
- steveklabnik 2y agoA 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]
- alpire 2y agoAndroid talked more about the memory-safe languages they're using in a previous blog post: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language... Google also published their perspective on memory safety in https://security.googleblog.com/2024/03/secure-by-design-googles-perspective-on.html 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.
- dgacmu 2y agoThere are many and google uses several - rust, python, java, and go among them. But low-level code for Android has historically been in c++ and Rust is the primary memory-safe replacement for the stuff they're building.
- jnwatson 2y agoJava and Kotlin are used for apps. Rust is used for new system software. Across Google, Go is used for some system software, but I haven't seen it used in Android.
- GeekyBear 2y agoGoogle attempted to write a network stack in Go for their Fuchsia OS, but it had to be ripped out and rewritten for performance reasons. https://news.ycombinator.com/item?id=22409838 https://news.ycombinator.com/item?id=22409838
- nightpool 2y agoIt's not just Rust—rewriting a C network service into Java or Python or Go is also an example of transitioning to memory safe languages. The point is that you're not exposed to memory safety bugs in your own code. Arguably it's much better to choose a language without Rust-like manual memory management when you don't absolutely need it.
- pdimitar 2y agoI have chosen Rust over Golang on a number of occasions for a much more boring reason: Golang lacks enums / tagged unions / sum types. When you have to manually eyeball your code to ensure exhaustiveness, it gets old and tiring really fast. 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.
- tialaramex 2y agoIf you need concurrency then depending on exactly what you're doing with it Rust still looks like the right choice. If you can just have it magically work no worries, but the moment you need synchronization primitives or phrases like "thread safe" come into the conversation you're much more likely to get it wrong in the other languages.
- NoahKAndrews 2y agoKotlin is memory-safe. It runs with a GC.
- adgjlsfhk1 2y agoGC is memory-safe.
- saagarjha 2y agoThat's what they said.
- adgjlsfhk1 2y agoI can't read. oops.
- wmf 2y agoGoogle has always tried to use a small set of languages. For Android they try to use C/C++, Java/Kotlin, and now Rust. The same lessons still apply in rampantly polyglot environments though.
- jeffbee 2y agoPerhaps they are even considering carbon to be memory safe
- _ph_ 2y agoThat is the separation between abstract considerations and a given projects constraints. In a given project there might be few choices, but if you talk about fundamental phenomena, you have to reason about arbitrary projects. And of course, there are plenty of alternatives to Rust. Even limited to Android, there are several choices, even if they might be a smaller set.
- pdimitar 2y agoIt's impractical to increase the surface of complexity even further. I for one approve that they settled on just one memory-safe language for their new code.
- _ph_ 2y agoOh sure, for the Linux kernel, Rust makes a lot of sense and one would try to keep the number of languages used minimal. But I was speaking about an abstract context. There are plenty of memory safe languages which could be used. But eventually, one has to decide for one.
- throwaway2037 2y ago> memory safe languages I would say anything that runs on JVM and CLR, and scripting langs, like Python, Perl, Ruby, etc. Edit: I forgot Golang!
- GeekyBear 2y agoThere are many memory safe languages, but not many of those are compiled and able to offer performance that is in the same ballpark as C. 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.
- Narishma 2y agoI was under the impression that Swift was more in the Go/C# bucket rather than Rust/C++ in terms of performance.
- pjmlp 2y agoSwift's long term roadmap is to be usable in all scenarios Apple currently uses C, Objective-C and C++ for, it is even on its official documentation and product description site. How much it gets there, depends on squizzing juice out of LLVM backend for Swift code.
- GeekyBear 2y agoGiven that the person who created LLVM also created Swift, the ability to be used as a systems programming language was always there. 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-ios17/ 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. https://atp.fm/205-chris-lattner-interview-transcript#gc https://atp.fm/205-chris-lattner-interview-transcript#gc