Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Safe Languages in Android 13

security.googleblog.com

Post reply on HN
Print view View original

131–140 of 606 posts

Re: Memory Safe Languages in Android 13

#131

Post by kllrnohj »

dahfizz wrote: post #77
burntsushi wrote: post #25

Earlier quoted context omitted.

Is there any practical programming language that is memory safe in its "entirety"? Python, for example, certainly is not. It has unsafe escape hatches (via ffi, at the very least). Yet, everyone I know of says and thinks of Python as a memory safe language. I do as well. > which makes it easier for developers to compartmentalize code to achieve memory-safety The problem here is that this is incomplete. Many many many…

I think a distinction can be made in that you never really need to use unsafe operations in python or Java. In rust, you need unsafe. Just about every data structure in the stdlib uses unsafe. I think it's fair to call Rust a memory safe language. But I don't think it's on the same tier as a fully managed language like python.

> I think a distinction can be made in that you never really need to use unsafe operations in python or Java.

You can't write any code at all in Python or Java without relying on unsafe operations. Both of them have their runtimes written in C/C++.

So based off of this unusual line of reasoning, Rust is strictly more memory safe than either of those as it's at least possible to have a Rust program without any unsafe code. That program will be of questionable value, sure, but it can at least exist at all whereas it can't for Python or Java.

Re: Memory Safe Languages in Android 13

#132

Post by IshKebab »

mk89 wrote: post #104

I am not a Rust or C++ fanboy, and I am happy that we are moving towards a future where there are less memory bugs, but… are we really? - https://www.infoq.com/news/2021/11/rudra-rust-safety/ - https://cve.report/vendor/rust-lang And you can find online similar links and research on the topic. All it takes is that you use that specific piece of code at the wrong time, and that’s it: your system which you once believe…

Did you read this bit?

> It could appear that these results undermine the belief that Rust safety model represents an improvement over other languages, e.g. C++, but this would not be correct, say the researchers behind Rudra, who still consider Rust safety a supreme improvement.

They found ~100 security issues in 45k packages. That's clearly better than C++.

Re: Memory Safe Languages in Android 13

#133

Post by dragonwriter »

jfengel wrote: post #126

I'm surprised that Kotlin is such a small fraction. I thought Google was trying to make Kotlin preferred over Java for Android development. (Not that it's easy to tell from the pie chart, which colors one orange and the other red, in similar shades. Do better, guys.)

Development of Android and development for Android are different domains.

Re: Memory Safe Languages in Android 13

#134

Post by dahfizz »

Ar-Curunir wrote: post #90
dahfizz wrote: post #77

Earlier quoted context omitted.

I think a distinction can be made in that you never really need to use unsafe operations in python or Java. In rust, you need unsafe. Just about every data structure in the stdlib uses unsafe. I think it's fair to call Rust a memory safe language. But I don't think it's on the same tier as a fully managed language like python.

One could implement many data structures without unsafe, but with less efficiency. E.g. using an arena allocator

Sure, but that is kind of what I mean. Safety in rust is something you actively have to think about and work around (at least some of the time). It doesn't just come for free like in python.

Re: Memory Safe Languages in Android 13

#135

Post by IshKebab »

lawn wrote: post #48
heather45879 wrote: post #24

Earlier quoted context omitted.

The problem with Rust is the language syntax is ugly. It has a ton of visual noise. I think folks who write languages should have a typographer on their team because something like this: use std::collections::HashMap Is a typographic nightmare. While I understand “form follows function”, it’s tough to be excited to program in something like this.

I do agree that Rust sometimes has a lot of visual noise. But that use statement is not a good example of it, and if that's the biggest criticism then Rust is faring fantastically well.

Yeah I agree. Rust is a mildly ugly language, but not because of `use`! It's all the lifetime annotations, turbofish, and macros that make it ugly.

Re: Memory Safe Languages in Android 13

#136

Post by vbarrielle »

kccqzy wrote: post #123
LAC-Tech wrote: post #33

For me the biggest features of rust are: - great standard library, especially all the iter methods. having 'obscure' stuff like `try_for_each` just makes me so happy as a dev - unit tests built into the lang - tooling is great - docs are top notch The memory safety aspect is... sometimes helpful, sometimes irritating. I prefer zig solution (BYO allocator, special one for testing that reports errors) over rusts, which…

Sorry to disappoint you but if Rust had adopted higher-kinded types they wouldn't need to write a function `try_for_each` because it would just be a generic fold-and-collect-effect function that works for all effects not just Try: traverse_ :: Foldable t => (a -> ExceptT e IO b) -> t a -> ExceptT e IO () Of course I'm not saying Rust should have this (there are good reasons why this isn't a good fit for Rust, see htt…

In my opinion a very good point about Rust is that it is built by people who know these functional programming concepts and why they are yseful, but are pragmatic enough to give them names that are easier to grasp for folks who don't know these concepts.

And it's possible the lack of higher kinded types, forcing reimplementation, actually gave the opportunity to look for frindlier names.

Re: Memory Safe Languages in Android 13

#137

Post by dahfizz »

burntsushi wrote: post #85
dahfizz wrote: post #77

Earlier quoted context omitted.

I think a distinction can be made in that you never really need to use unsafe operations in python or Java. In rust, you need unsafe. Just about every data structure in the stdlib uses unsafe. I think it's fair to call Rust a memory safe language. But I don't think it's on the same tier as a fully managed language like python.

I suppose reasonable people can disagree, but I don't think it's anywhere near as clear cut as you seem to be implying. You talk about data structures in std using unsafe, but you don't mention the heaps and piles of C code used to implement CPython's standard library. It's not like you need `unsafe` in Rust to build every data structure. I build oodles of data structures on top of the fundamental primitives provided…

You make a good point that much of pythong stdlib is implemented in C. But you could implement python's list in pure python, safely. You can't implement something like that in rust without unsafe.

Re: Memory Safe Languages in Android 13

#138

Post by chc »

dist1ll wrote: post #110
Ar-Curunir wrote: post #84

Earlier quoted context omitted.

That directly contradicts in-progress efforts to make `const` better. Things like `const trait`, `const Allocators`, etc are all in progress.

Some const features seem like big anti-patterns though. One example is the unstable feature `generic_const_exprs` which I think is a bit short-sighted.

What seems short-sighted about that to you? I'm not super familiar, but it seems like something you'd want if you're using const generics.

Re: Memory Safe Languages in Android 13

#139

Post by kllrnohj »

GuB-42 wrote: post #80

I didn't realize there was so much C and C++ in Android, I thought most of it was Java. Maybe they are just talking about the core system (including the Linux kernel and Java runtime) and not all the builtin apps.

Much of the graphics, camera, media, bluetooth, wifi, input handling, etc... stacks are native. There's a massive amount of native code in Android below the veneer of the Java API that apps are given.

Many of the higher level constructs are then in Java/Kotlin, though, like the builtin apps, system ui, activity & window managers, etc...

Re: Memory Safe Languages in Android 13

#140

Post by kllrnohj »

bluGill wrote: post #130
kllrnohj wrote: post #120

Earlier quoted context omitted.

No it isn't. It's just evidence that it's a trade-off you might want to make in order to achieve some other goal, specifically security. But if "security" isn't remotely a concern for a given project (like almost anything graphics / gaming related), this is not at all evidence for changing anything. It could be that Rust's optimizer eliminates the bounds checking so regularly as to be a moot point, but this isn't say…

I take it the opposite: C programmers out of abundance of caution of putting in bounds checks for code that will never be called with out of bound data. As such rust is eliminating code that is being manually written. If you don't write the bounds check in C, and rust for the equivalent determines that the bounds check isn't needed the code should be the same (to the assembly level). However if you write a bounds che…

Can you point to any such bounds check in C that an optimizer cannot eliminate but it can eliminate the equivalent one in Rust?

I'm sure it's possible to construct such a thing, but I cannot imagine it ever being common enough to show up on any sort of head to head comparison.

Post reply on HN