Live data from Hacker News

Memory Safe Languages in Android 13

security.googleblog.com

171–180 of 606 posts

Re: Memory Safe Languages in Android 13

#171

Earlier quoted context omitted.

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.

    let mut line = String::new();
    stdin().read_line(&mut line)?;
This is what I'm talking about. This is so ugly and clunky and needlessly verbose like Java compared to C++ where you can do

    std::string input;
    std::cin >> input;
and have it Just Work. Why can't Rust do something similar?

Re: Memory Safe Languages in Android 13

#172

> This matches the expectations published in our blog post 2 years ago about the age of memory safety vulnerabilities and why our focus should be on new code, not rewriting existing components. and > As we noted in the original announcement, our goal is not to convert existing C/C++ to Rust, but rather to shift development of new code to memory safe languages over time. For those working on C/C++ code bases, how does…

Brave Browser has some Rust components too (e.g. the adblocking engine). Rust in C++ works very well for components with a small, well-defined API surface that involve a lot of logic. You only need to build a small FFI layer for the direct interfaces between the two languages. CXX [1] makes this even easier, too.

Brave is definitely not aiming to convert the entire browser to Rust, but it's increasingly chosen for new development.

[1] https://cxx.rs/

Re: Memory Safe Languages in Android 13

#173
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.

The "Rust way" is very close to the safe variety of the "experienced C++ way", so many people adapt promptly.

Re: Memory Safe Languages in Android 13

#174

Earlier quoted context omitted.

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.

there's almost no bounds checking in rust code before the optimizer even looks at it because we use iterators and not goofy manually indexed for loops that are begging you to make a typo that crashes your code :)

Re: Memory Safe Languages in Android 13

#175

Earlier quoted context omitted.

There's been many, for example Ada/SPARK, D, Nim, Java, Kotlin, Swift.

- Ada: good example, has substantial uses in certain areas. However, certain things are quite difficult, e.g. compile-time checked pointers (a la Rust's borrow-checked references). - D, Nim: neither provide strong memory safety guarantees. D has a safe subset, but it's not default (see https://news.ycombinator.com/item?id=12391720 ). Nim allows you to turn checks off at runtime. Both Nim and D generally use a GC. - J…

>> Ada: good example, but not usually used for low-level systems programming. Has substantial uses in certain areas.

Ada is primarily used for low-level systems programming and embedded systems:

https://learn.adacore.com/courses/intro-to-ada/chapters/intr...

Substantial portions of the Ada standard deal with systems programming and low-level representation on hardware:

http://www.ada-auth.org/standards/22rm/html/RM-C.html

http://www.ada-auth.org/standards/22rm/html/RM-13-1.html

Re: Memory Safe Languages in Android 13

#176

Earlier quoted context omitted.

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.

Trivially, anything using the Iterator trait.

I don't know that I've ever actually manually indexed an array over years of using Rust.

Re: Memory Safe Languages in Android 13

#177

Earlier quoted context omitted.

Beyond the above, IIRC Android ships with integer overflow enabled (but can't find where I read this).

Not that it's important, but just a note that unless you recompile the standard library yourself, integer overflow will still be off for that code since it ships compiled. (Correct me if I'm wrong, that's my recollection).

The Android project compiles the standard library themselves: https://android.googlesource.com/platform/prebuilts/rust/+/a...

Re: Memory Safe Languages in Android 13

#178

Earlier quoted context omitted.

>Rust didn't protect me from that, and those are the kind of vulnerabilities that we'll continue seeing regardless of language I'm still thinking about how we could integrate something like that in a language or the languages package manager. I'm unsure if it's possible.

How about in the OS? This sounds like exactly the type of thin SELinux is meant to handle

Yeah, I think the thing is... path traversal is pretty trivial to solve. If you have a single tenancy app and you just don't want the service accessing shit it shouldn't just throw it in docker. If you have a multi-tenancy app just put every user behind a uuid.

Re: Memory Safe Languages in Android 13

#179

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…

So many complaints above surface-level syntax here. > press "shift 3 bracket shift 9 shift 0 bracket" at the top of my structs Just use an IDE and you can press alt+enter. Same thing you do in Java when writing getters and setters for your AbstractFactoryBeans. > "let mut" could have been "var" The "mut" does not belong to the "let", it belongs to the variable name. let (read_only, mut read_write) = (1, 2); > Passing…

> Explicit is better than implicit.

Not only that, but in Rust it actually has a meaning. Self can be &self or &mut self, which impacts the calling conventions.

The alternative would be fully typing anything but owned method calls which would just not have a self parameter, which would be incredibly weird.

It also shows that as in Python (and really even more so) "methods" are little more than syntactic sugar for functions. It would also require a new and separate syntax to declare non-instance methods.

Re: Memory Safe Languages in Android 13

#180

Earlier quoted context omitted.

"It should have two compilers" is a pretty arbitrary benchmark for production readiness. I'd suggest the benchmark be based on, idk, something with any fucking meaning.

>something with any fucking meaning So you claim to have a better metric, feel free to share it? site broken and wont let me reply any more: "shipped into production" is meaningless, compilers are directly related to language community and complexity.

How about numerous companies shipping Rust to production for years? That metric is actually related to risk with regards to shipping rust in production, unlike number of compilers, which signifies nothing.
Post reply on HN