Google Now Supports Rust for Underlying Android OS Development (9to5google.com) 28
For the past few years, Google has been encouraging developers to write Android apps with Kotlin. The underlying OS still uses C and C++, though Google today announced Android Open Source Project (AOSP) support for Rust. From a report: This is part of Google's work to address memory safety bugs in the operating system: "We invest a great deal of effort and resources into detecting, fixing, and mitigating this class of bugs, and these efforts are effective in preventing a large number of bugs from making it into Android releases. Yet in spite of these efforts, memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android's high severity security vulnerabilities."
The company believes that memory-safe languages, like Rust, are the "most cost-effective means for preventing memory bugs" in the bootloader, fastboot, kernel, and other low-level parts of the OS. Unlike C and C++, where developers manage memory lifetime, Rust "provides memory safety guarantees by using a combination of compile-time checks to enforce object lifetime/ownership and runtime checks to ensure that memory accesses are valid." Google has been working to add this support to AOSP for the past 18 months. Performance is equivalent to the existing languages, while increasing the effectiveness of current sandboxing and reducing the overall need for it. This allows for "new features that are both safer and lighter on resources." Other improvements include data concurrency, a more expressive type system, and safer integer handling.
The company believes that memory-safe languages, like Rust, are the "most cost-effective means for preventing memory bugs" in the bootloader, fastboot, kernel, and other low-level parts of the OS. Unlike C and C++, where developers manage memory lifetime, Rust "provides memory safety guarantees by using a combination of compile-time checks to enforce object lifetime/ownership and runtime checks to ensure that memory accesses are valid." Google has been working to add this support to AOSP for the past 18 months. Performance is equivalent to the existing languages, while increasing the effectiveness of current sandboxing and reducing the overall need for it. This allows for "new features that are both safer and lighter on resources." Other improvements include data concurrency, a more expressive type system, and safer integer handling.
More shoving Rust where it dosen’t belong (Score:1)
RustemD has ruined the fun of Linux for me.
Re: (Score:2)
The implementation may worse than the benefits of the solved problem (see most "new" functional languages for many examples), but thats a separate matter.
As far as dependencies... there are always tradeoffs when picking and choosing. If you dont like the outcome, its because you made the wrong trades, yes?
Re: (Score:1)
The most problematic trade in question was to (re-)write rustc in Rust, leading to a bootstrapping problem. I almost think someone heard that "only perl can parse Perl" -- lower-case perl being the standard version of the interpreter, upper-case Perl being the language -- and decide that that would be a good thing for a systems programming language.
To pick a contrasting example, Go's official compiler is written in Go, but gccgo actively tracks the Go specification, making the bootstrapping problem much le
Re: (Score:2)
Yes, the fact that there are other decent (even good) C and C++ compilers is a very big practical difference. In that situation, you can use alternative compilers to defeat the Thompson hack (to an arbitrarily high degree of confidence). The fact that somebody *could* write a competing compiler for Rust doesn't change the essence of the trade, because a theoretical possibility doesn't simplify actual bootstrapping -- only the actual existence of another compiler would.
Re: (Score:1)
Re: More shoving Rust where it dosen’t belon (Score:2)
Rust definitely has technical superiority. If becomes quite obvious once you start using it. Anyways, the rust community doesn't advocate rewriting things in rust just for the sake of doing so, though environments where you have to run untrusted code and performance and security is paramount, such as web browsers, are places where it would be a good idea.
Ok Android devs, what do you think? (Score:3, Interesting)
I've done a small amount of Android dev to-date, nothing that would be considered a real app. I've mostly been doing iOS development for quite a while now.
At some point though I'd like to go deeper into Android dev work - do you think someone learning Android might be better off learning Rust for Android dev, or just stick with Kotlin?
From an intuitive standpoint, it seems like Kotlin would be better, since the system and UI libraries are more oriented towards a Java/Kotlin mindset, and probably will not really mesh as well with Rust constructs for a while. Also, Kotlin seems closer to Swift than Rust is (not sure about that).
So, I though it would be interesting to ask what professional Android devs thought.
Re:Ok Android devs, what do you think? (Score:4, Informative)
I've done a small amount of Android dev to-date, nothing that would be considered a real app.
The be clear, TFA is talking about Rust in the AndroidOS, not about using Rust in apps.
Rust is not well supported for Android app development. If you try to use it, you will be way out on the bleeding edge. Since you claim to have little app experience, that would likely be a mistake. You should stick with Kotlin until the Rust ecosystem on Android matures.
I see (Score:1)
The be clear, TFA is talking about Rust in the AndroidOS
Thanks, this is one time I really should have read TFA... I assumed it meant it would also be able to be used for Android development. Oh well, maybe the next mobile platform then.
Re: (Score:2)
Use Lisp, like all the cool emacs users do. It's all pretend anyway, right?
Would any of your iOS development be "considered a real app", I mean by a real programmer?
What does "intuitive standpoint" mean?
I don't think Android apps get you any closer to the front row at the Apple pep rallies. Steve Jobs would not approve.
Google security blog post (Score:5, Informative)
Gimme Lisp (Score:2)
Rust is safe. Hard learning curve. (Score:5, Interesting)
Rust analysis happens at compile time. This in it self reduces the attack window.
Zero garbage collection make it great for embedded and sandbox environments.
Rust to WASM produces very safe code that can run is a browser.
Libraries? I had to fork two projects to get my projects to work.
I think writing in rust is a good idea,
Re: Rust is safe. Hard learning curve. (Score:2)
When it comes to learning rust, the main thing you need to understand is ownership. Once you get past that, the rest is easy, in fact I find it easier to write programs in rust than I do C#, mainly because rust is so much easier to debug. In fact, provided you avoid using unwrap() and you use at least a minimal amount of care when using slices, your program is all but guaranteed to never crash.
Is Rust treally safer? (Score:3)
I'm certain Rust is safer than C. But it will be interesting to see in a few years if Rust is really safer than properly-written C++ (ie using unique_ptr and shared_ptr et al whenever possible). If the code is doing something that still requires raw pointers in C++, it's probably going to require an unsafe section in Rust. Same difference.
Re:Is Rust treally safer? (Score:4, Insightful)
Yes, it is.
I've been a security professional for all my life, and I love Rust, even though I fight with its idiosyncrasies every time I use it. But preventing issues that have plague us for decades is clearly a core design principle for Rust, and that alone puts it in a different class than most (though not all) other common languages.
C++ keeps a lot of the basic principles from C and doesn't solve many of its problems. Don't get me wrong, I love C - but it's a loaded gun without safety. In the right hands, a powerful tool. In the wrong hands... well... the students in C hated me when they tried to submit their code and I made it crash again and again and again until they finally learned to handle input properly.
Rust simply doesn't have many of the problems because the language takes care of it. People simply can't make certain mistakes. And while we can always say that "of course you don't do X", and how C, C++ or whatever your favorite language is are really safe if "properly written", don't forget that most companies who commercially write software will hire the cheapest coders and push the deadlines to the max and cut corners in the pieces the customer doesn't see.
Re: (Score:2)
don't forget that most companies who commercially write software will hire the cheapest coders and push the deadlines to the max and cut corners in the pieces the customer doesn't see.
Those companies will be hiring Javascripters. Hence the unexpected rise of Node.JS on the server. They won't be hiring for C++, but they also won't be hiring for Rust either. Neither are suited for the high-volume/low-quality code that Javascript is.
C++ "written properly" requires much less effort than poorly written C++. "Properly written" C++ can be as simple as Python, especially with modern features that does away most of the boilerplate. I can just as easily write a simple script in C++ for text pro
Re: (Score:3)
Those companies will be hiring Javascripters. Hence the unexpected rise of Node.JS on the server. They won't be hiring for C++, but they also won't be hiring for Rust either. Neither are suited for the high-volume/low-quality code that Javascript is.
I agree with that but it's a temporary assessment. I'm reasonably sure JS and Node.js will be over within a decade or so in the sense that the momentum is elsewhere and a couple companies make good money keeping legacy applications alive.
C++ "written properly" requires much less effort than poorly written C++. "Properly written" C++ can be as simple as Python, especially with modern features that does away most of the boilerplate. I can just as easily write a simple script in C++ for text processing, or I can get a small webserver up and running like what you can with NodeJS.
Probably. I've not written much C++ in my life, and only taught myself Python last year. Without a doubt, both of them outclass JS in any metric except "runs natively in browser" and "has a vast pool of cheap coders available". But the comparison wasn't JS, it was Rust. And
Re: (Score:2)
JS and Node.js will be over within a decade or so
In fact, I hope that Rust and its strong webasm capabilities will be one of the shovels that dig the grave for JS web apps.
Re: Is Rust treally safer? (Score:2)
It's much easier to grep for unsafe sections in rust than C++.
Are there code analysis tools which check guidelines which can give the same guarantees as safe rust as long as the tool says the guidelines were followed? MISRA doesn't seem to have them AFAICS.
Re:Is Rust treally safer? (Score:5, Informative)
But it will be interesting to see in a few years if Rust is really safer than properly-written C++
Let me begin with an appeal to my own authority: I lead the Android team that has written the largest quantity of Rust code in Android, though I personally wrote very little of it, and attribute the success of the project entirely to my colleagues.
By "properly-written C++" you mean "Modern C++", and I think the answer is no. Rust isn't safer than Modern C++ -- assuming the C++ code never deviates from the set of idioms defined by Modern C++, and assuming that the C++ code has exceptions enabled (Android disables them), and all code and libraries are exception-safe. And probably a couple of other caveats that will come to me later.
You get the point, I think.
Rust is essentially the same programming paradigm as modern C++, but with exceptions replaced with a simplified error-return strategy that enforces error checking and makes it pretty painless. Rust is a bit more functional (in the "functional language" sense of the word, not in the "it works" sense), mostly because its standard libraries adopt a more functional approach, which increases the learning curve but isn't a fundamental differentiator, since C++ now has all of the tools needed to be as functional as Rust.
The really big difference is that Rust won't let you do unsafe things outside of an "unsafe" block, whereas C++ allows you to quietly insert unsafe code anywhere you like, and doesn't force you to make it obvious. This means that unsafe blocks in Rust get a lot of scrutiny. Further, approximately all teams writing Rust enforce some norms around unsafe blocks, requiring more documentation and more scrutiny. In theory the same thing could be done in C++ -- isolate and scrutinize unsafe code -- but with Rust the language and compiler help with this in ways that C++ tools do not.
My conclusions are that (a) you're right it will be interesting to see if Rust actually works out to be better than properly-written C++ and (b) even if it isn't, the amount of properly-written C++ in the world is smaller than we would all like to believe, even in shops with highly-qualified engineers and well-developed quality processes, including mandatory code reviews, etc. So I expect that Rust will be better than C++ because C++ is quite likely not to be properly written.
Re: (Score:2)
Indeed, I'm referring to Modern C++ and best practices. Your insight is interesting because of your experience on a Rust team. It's my opinion that is where we'll really find out in a few years if Rust lives up to its billing, as it's on large teams with large codebases and long lifetimes that a language truly gets "tested". If Rust prevents Sally from causing a breaking change in the code base because she just modified something long-gone Sam did two years ago in a subtle way that tests "undefined behaviou
Re: (Score:2)
I posed your question to the engineer who did the largest part of the implementation yesterday, and he disagreed with me. He says in terms of memory safety he thinks strict Modern C++ is roughly equivalent to Rust (though he points out that there are a lot of things Rust checks that C++ does not, even in Rust "unsafe" blocks), but says that C++ doesn't provide anything equivalent to Rust's safe-concurrency infrastructure. You could build it in C++, but that would mean not using STL collections (not without
Re: (Score:2)
But it will be interesting to see in a few years if Rust is really safer than properly-written C++ (ie using unique_ptr and shared_ptr et al whenever possible.
There are several problems with this:
1) No compiler warns you when you use non "properly-written" C++.
2) Idiomatic modern C++ still has plenty of undefined behavior:
* use after move. This is very common especially with unique_ptr
* [] operator in string, arrays, and vectors does not do bound checks, you have to explicitly use the at method instead if you want bounds checks.
* Pass the wrong iterators to stl algorithms and all hell breaks loos
Re: (Score:2)
I find that modern C++ compilers do a good job of warning you when you use non "properly written" C++ if you use the appropriate '-Wall -Werror' sort of flags, and the current standard implements items like the [[fallthrough]] attribute to fix items like your number 4.
I do agree with you and your point 2 that the "undefined behaviour" in C++ (and C) called out explicitly in the C/C++ standard is what gets a lot of programmers into trouble. I have over three decades of C/C++ experience, and undefined behavio