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

Rust in Android: move fast and fix things

security.googleblog.com

Post reply on HN
Print view View original

61–70 of 430 posts

Re: Rust in Android: move fast and fix things

#61

Post by stocksinsmocks »

delusional wrote: post #35

I don't understand the graphs presented here. On the first graph showing "New Memory Unsafe Code" and "Memory safety Vulns" we don't have any steady state. The amount of both "unsafe code" and "memory safety vulns" had apparently already been dropping before 2019. None the matter though, we see a great big drop at 2022 in both. Then in the next graph, showing "Rust" and "C++", we see that the amount of C++ code writt…

I’m a little perplexed why every time something in rust compiles, there’s a blog post about it. I was under the impression Ada, especially when using provers, has been around much longer and is more robust. I just can’t decide if the massive Rust evangelism budget is a red flag or just a curious sociological case study, but I wish I knew the truth.

Re: Rust in Android: move fast and fix things

#62

Post by gpm »

pizlonator wrote: post #58
dwattttt wrote: post #47

Earlier quoted context omitted.

> And then the rest of us have a data point that we think we can trust, when in reality, it's just cherry picked data being used to convey an opinion. Calling what Google did here "science" and cherry picked is quite a disservice. It's observational data, but do you have any objection to the methodology they used? Or just (assumed?) bad vibes?

In science, you go out of your way to control for confounding factors. This isn't that.

> In science, you go out of your way to control for confounding factors.

There's tons of observational science done in a very similar fashion to the article where there is simply no way to control for confounding factors for the same reason that there is simply no way to properly control for it in the data available.

Re: Rust in Android: move fast and fix things

#63

Post by danudey »

bluGill wrote: post #51
tux3 wrote: post #37

Earlier quoted context omitted.

>I think cargo is better than cmake That is an understatement. I can't think of a build system that has spawned more attempts to find something better than CMake has. There have been so many people trying to make their own C/C++ build system and/or package manager out of sheer spite for CMake that it's frankly hard to keep track. In fairness to them and to CMake, it's not a simple problem to solve. To truly know CMak…

You seem to forget about autotools. Cmake is ugly but I'll take it over autotools.

As an end user: at least with autotools it's easy for me to see the available configuration options with ./configure --help in a nicely readable way. cmake has -LAH but it's still... kind of awful.

At least it knows how to use ninja though.

Re: Rust in Android: move fast and fix things

#64

Post by baq »

mk89 wrote: post #30
beeflet wrote: post #13

Earlier quoted context omitted.

rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better. It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write. I would like to use rust to write android apps. I don't really like the whole android studio java thing.

I cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like. But I agree that the tooling that cargo introduced is a breath of fresh air in a world dominated by huge makefiles, libraries copied in the repository (I know, there is Conan, vcpkg etc)...

No need to like it. It isn’t brainfck and does the job.

Re: Rust in Android: move fast and fix things

#66

Post by girvo »

kridsdale1 wrote: post #55
nixpulvis wrote: post #21

Earlier quoted context omitted.

Funny, another commenter on this post was saying the opposite, that Rust was likely being used to just port existing features and that was easier because there were probably good tests for it already. If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.

I’d say the same applies for Swift vs ObjC. Let’s end the C era.

While the C calling convention continues to rule operating systems and FFIs, I think it’ll continue to limp along. Hopefully one day that can be fixed, it’s annoying that C is what I have to reach for to call SomeLib no matter what language I’m using

Re: Rust in Android: move fast and fix things

#67

Post by flohofwoe »

pjmlp wrote: post #60
dwattttt wrote: post #56

Earlier quoted context omitted.

By first party support, would you be expecting a Rust toolchain shipped in the NDK, or maybe Rust bindings shipped in the NDK? I could see the latter, although I'd still question whether they should be special cased in terms of a Rust dependency compared to bindings being hosted on crates.io. Or maybe they should ship scripts that shell out to an existing Rust toolchain.

I expect Rust being documented here, https://developer.android.com/ndk I expect the whole Rust build process being part of Android Studio, including mixed language debugging between Java, Kotlin and Rust. I expect all NDK APIs to have Rust bidding crates. I expect that Android developer forums also care to support devs using Rust. And anything else that I forgot to mentioned, that is provided for Java, Kotlin, C and…

The Android NDK just barely supports C and C++ either, unless you're ok with 1990's tooling standards. The whole thing feels like it's maintained by two dudes locked in a Google basement somewhere. I doubt they have the capacity to deal with Rust support in the NDK, unless there's a big strategic change in Android tooling.

Re: Rust in Android: move fast and fix things

#68

Post by danudey »

nixpulvis wrote: post #21
bla3 wrote: post #11

Earlier quoted context omitted.

If they use Rust for new code and C++ changes are all in old code, this could be explained just by older code being more risky to change.

Funny, another commenter on this post was saying the opposite, that Rust was likely being used to just port existing features and that was easier because there were probably good tests for it already. If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.

As a relatively novice programmer who's worked in tech for decades but not as a software developer: I take issue with the idea that you need to write considerable amounts of Rust and C++ for these statistics to be expected. In fact, despite Rust's initial vertical learning curve I'd say that any junior developer trying to implement anything with any degree of complexity at all in Rust and C++ would see the benefits.

At the very least, the fact that IDE integration can tell you all kinds of stuff about what you're doing/doing wrong and why accelerates things greatly when you're starting out.

Re: Rust in Android: move fast and fix things

#70

Post by vlovich123 »

kridsdale1 wrote: post #53
gpm wrote: post #17

Earlier quoted context omitted.

> I think cargo is better than cmake I expect that Google is using neither of these for most of their own code, but rather their own build system (which I think is the same between the languages). I absolutely agree if you aren't Google though.

Google3 uses Blaze which is an internal Bazel. And it’s fantastic. I like Facebook’s BUCK too but it’s basically the same thing. If I were to go to another company I’d promote using either of the above.

What does Android do for Rust?
Post reply on HN