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

121–130 of 606 posts

Re: Memory Safe Languages in Android 13

#121

Post by chc »

Mesopropithecus wrote: post #75
pornel wrote: post #62

Earlier quoted context omitted.

Rust does require structuring programs in a "Rust way" to avoid fighting with things it can't prove to be safe. However, I appreciate that Rust tries to achieve safety through improving program correctness, not merely crashing sooner. Of course Rust has run-time panics (hasn't solved the halting problem yet), but it also has many patterns catching problems at compile-time. For example, a hardened allocator can detect…

> Rust does require structuring programs in a "Rust way" to avoid fighting with things it can't prove to be safe. That was my concern that I had when I started learning the language. I think it is true, but I was surprised how quickly I managed to get used to the Rust way.

It's also worth noting that the "Rust way" often ends up being clearer and better structured, in hindsight. Rust forces you to think through questions of ownership and identity more than most languages, and a lot of "structuring programs the Rust way" is just expressing these things.

Of course, that's just "often," not nearly "always." There are many valid programs that the borrow checker struggles with, and in those cases, the "Rust way" is just needlessly convoluted. There are many problems for which the most common answer is "just store all this data in a list and use list indices like pointers." (Thankfully there has been a lot of progress on a new borrow checker that's less easily startled.)

Re: Memory Safe Languages in Android 13

#122

Post by nneonneo »

netr0ute wrote: post #88
optymizer wrote: post #76

As an Android user ever since the T-Mobile G1, I'm a fan of not having my phone remotely exploited via WebView, or with an SMS, or the other million ways there are to interact with a device, so I absolutely celebrate this progress. As an Android developer though, I have to be the one bitter old man yelling at cloud. I was spoiled by Java and Kotlin to the point where I cannot look at Rust and think it's a nice modern…

I had the same experience with Rust too. After trying and failing for hours to trudge through syntax BS, I'm (probably) not touching it again until something big changes. I can't even get user input without making a huge ugly one-liner or importing some dependency.

Unclear what you mean by user input - for arguments, `std::env::args()` exists, and for stdin `std::io::stdin()` exists and provides various read functions.

    let mut line = String::new();
    stdin().read_line(&mut line)?;
    println!("input: {}", line);
I suspect that there _have_ been some changes since you last looked - for example, the ? operator lets you propagate errors in a more compact way.

Re: Memory Safe Languages in Android 13

#123

Post by kccqzy »

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 http://smallcultfollowing.com/babysteps/blog/2016/11/09/asso...) but it really caught my eye that you called `try_for_each` obscure; it could have been an everyday function if it had a bit more expressiveness.

Re: Memory Safe Languages in Android 13

#124

Post by bluGill »

cryptonector wrote: post #38

> Safety measures make memory-unsafe languages slow > > Mobile devices have limited resources and we’re always trying to make better use of them to provide users with a better experience (for example, by optimizing performance, improving battery life, and reducing lag). Using memory unsafe code often means that we have to make tradeoffs between security and performance, such as adding additional sandboxing, sanitizer…

I wonder how much of the positive performance is just because we have not proved that some impossible case is really impossible and so we have if statements checking for a situation that mathematically cannot happen just out of caution. (note that in many cases we don't even have the theoretical tools to prove the code)

Though that makes non-memory safe code more reliable in the case of a bit flip. (this is not a serious advantage - only some bit flips can be prevented this way)

Re: Memory Safe Languages in Android 13

#125

Post by satvikpendem »

Mesopropithecus wrote: post #78
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.

As somebody who appreciates Lisp, I feel your pain. As somebody who also appreciates Rust, I'm curious, what is your baseline?

Brainfuck, clearly /s

Re: Memory Safe Languages in Android 13

#126

Post by jfengel »

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.)

Re: Memory Safe Languages in Android 13

#127

Post by satvikpendem »

pcwalton wrote: post #112
optymizer wrote: post #76

As an Android user ever since the T-Mobile G1, I'm a fan of not having my phone remotely exploited via WebView, or with an SMS, or the other million ways there are to interact with a device, so I absolutely celebrate this progress. As an Android developer though, I have to be the one bitter old man yelling at cloud. I was spoiled by Java and Kotlin to the point where I cannot look at Rust and think it's a nice modern…

> Edit: if you downvote, reply with a link to the last compiler you wrote. https://github.com/rust-lang/rust/

This has to be as good as the "Did you win a Putnam?" comment from 15 years ago [0].

[0] https://news.ycombinator.com/item?id=35079

Re: Memory Safe Languages in Android 13

#128

Post by codedokode »

burntsushi wrote: post #45
codedokode wrote: post #32

Rust doesn't check for overflow in arithmetic operations in release mode so there are lot of opportunities to create vulnerabilities in Rust.

There is some important context missing from your comment here. At least two points anyway: In Rust, overflow is not undefined behavior (neither signed nor unsigned). Today, arithmetic wraps in release mode (panics in debug mode), but it may panic in release mode in the future. The other point is that, since overflow wraps, that may indeed result in logic bugs. And in theory that logic bug could be used to lead to ex…

Wrapping arithmetic operations have been a reason of vulnerabilities in Linux kernel though. Developers need real addition, not addition modulo 2^32.

Re: Memory Safe Languages in Android 13

#129

Post by satvikpendem »

thesuperbigfrog wrote: post #5

"Migrating away from C/C++ is challenging, but we’re making progress. Rust use is growing in the Android platform, but that’s not the end of the story. To meet the goals of improving security, stability, and quality Android-wide, we need to be able to use Rust anywhere in the codebase that native code is required. We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve…

> I plan on doing Advent of Code in Rust this year.

Nice, I'm doing it in chatGPT this year [0].

[0] https://news.ycombinator.com/item?id=33821092

Re: Memory Safe Languages in Android 13

#130

Post by bluGill »

kllrnohj wrote: post #120
cryptonector wrote: post #38

> Safety measures make memory-unsafe languages slow > > Mobile devices have limited resources and we’re always trying to make better use of them to provide users with a better experience (for example, by optimizing performance, improving battery life, and reducing lag). Using memory unsafe code often means that we have to make tradeoffs between security and performance, such as adding additional sandboxing, sanitizer…

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 check in C the optimizer might not eliminate it.
Post reply on HN