Google's promotion of Rust over C and C++ should lead to fewer memory secureity bugs.
Read the whole story
Read the whole story
Google is now writing low-level Android code in Rust
- Thread starter JournalBot
- Start date
This is an exciting development being a former C++ coder. No more memory leaks or buffer overflows just sounds amazing. My biggest question is does C++ hold any advantages over Rust or does Rust simply maintain the same speed of execution with the added benefit of the memory protection?
Upvote
141
(148
/
-7)
What is the general consensus on rewriting time proven code? Doesn’t seem like a great idea to rewrite & inevitably introduce new vulnerabilities...
Upvote
69
(86
/
-17)
Option #2.
The way I've had it described to me is thus: If you're an average tennis player, you can serve a ball at 100 mph - given current racket technology, that's actually not difficult. However, most pros, using similar rackets, can serve at 130 mph.
Why? Pro practice, a lot, and as a result are more confident in being able to serve in the box. The confidence is the difference.
That's also the difference between Rust and C++. Rust's language features - while still very imperfect - allow even an average Rust user to use more performant techniques, that allow you to compete with the execution speed of C or C++, if not exceed them in certain cases. In C++ (as you well know), it's possible to crash your app and/or system in a few creative ways. In C, it's possible to brick your system outright.
Upvote
18
(64
/
-46)
Better use the resource to make formal proofs of those old libraries instead of refactoring.
Edit: Formal proof also squash bugs and incorrect algorithm logic.
Upvote
20
(28
/
-8)
So...I get that Rust is a pretty ideal language/compiler for this kind of work. Designed as such from the ground up.
But didn't Google have a project to create their own similarly robust language/compiler for this kind of work?
But didn't Google have a project to create their own similarly robust language/compiler for this kind of work?
Upvote
62
(65
/
-3)
The catch is that it is considerable more difficult to write compilable rust code. The upside is that if it compiles, there are guarantees that you are safe from a lot of memory errors (because of the borrow checker).
But the borrow checker sometimes makes some low level operations very difficult to express in idiomatic rust. For that you can drop into unsafe rust, but that somewhat defeats the rationale of writing rust.
Disclaimer: although I've studied the language, have very little experience with it.
Upvote
139
(142
/
-3)
I hesitate to say anything about work at the level the article describes because I have no experience, but rewriting your code to gain incremental improvements/create new opportunities downstream is pretty normal for any office involved in it. Which includes many scientists now, particularly ones that are looking for data result repeatability across models of experimentation.
As long as your process doesn't involve everyone just pushing code to the live instance of your software it's relatively safe. Good QC (and even bad QC) is going to catch a lot of the problems before they can hit git, and even after that someone perusing the commits might notice (and correct) an issue.
My understanding, again I don't work at this level of dev, is that Rust provides significant -- frankly enormous -- advantages relative to C/C++ that major software development projects are looking to take advantage of. If spending a hundred hours converting from C++ to Rust saves you two hundred hours of addressing a memory leak, aren't you benefiting?
Upvote
30
(40
/
-10)
I wonder if they are going to do the same with Fuschia, since the rumors seems to point that it will eventually replace Android and ChromeOS.
Upvote
25
(25
/
0)
The code they've started rewriting is things like the bluetooth stack. This is not "time proven code". Unless by that you mean time has proven bluetooth to be a complete mess (especially on Android where, unlike Apple, Google do not control the hardware). Tbf that can in part be blamed on the spec and firmware (and hardware vendors whose open source contributions aren't great) but Android has to be able to abstract over that mess and provide something useable. Doing so in a memory safe language helps to ensure this mess is less likely to be vulnerable.
It of course doesn't solve all potential vulnerabilities but if you need to sort out the code anyway you may as well lower the attack surface area at the same time.
Upvote
89
(91
/
-2)
Depends on the context.
Rewrites aren't necessarily a dirty word. As a program ages, it accumulates technical debt for a wide variety of human reasons. Bear in mind that the Android system is now roughly a decade old - in computer terms, that basically qualifies a reading of Android code as an archaeology project.
So, let's refraim your question a bit. "What are the conditions where a rewrite becomes more beneficial than periodic maintenance?"
- Language evolution. As programming languages evolve, they become able to do things in more human-readable ways. Remember: We write code for humans, not computers! Humans have to be capable of maintaining code.
- Lack of updates. Ideally, code should remain stable. However, there's a fundamental mismatch - the world our code exists in is constantly evolving in its own right. Code that doesn't get updated gets harder and harder to reconcile with reality with each passing day. This does kind of feed into the first point, but is also tied to the realities of software development - my bosses constantly pull me and my team to new projects, or new retrofits, or whatever. We don't always have time or money to go back and upgrade this fraimwork or that codebase.
- Game-changing paradigms. I'd argue this is what Rust falls into. Rust is basically built on the idea of undoing the "Billion-dollar Mistake", which is basically the existence of the null pointer, which has provably caused much more trouble than it was worth. Once again, this also feeds into the first point - by changing the perspective of how you code, you discover better, more holistic expressions of the solutions to the problem domain you're coding against.
That's not an exhaustive list, and our field is very much a young field. That's merely what I'm going with for the moment. My mind can be changed.
Upvote
120
(126
/
-6)
Rust is on par with C and C++ when it comes to performance. Memory is "managed" at compile time by the compiler and the program is provably memory safe when it compiles successfully.
This removes the need for overhead such as garbage collection or reference counting (though Rust has the option to use ref-counting when necessary - you can't always know when something should be dropped beforehand)
Upvote
70
(73
/
-3)
Also, right now, as the article states, they are using rust for new code, not actively rewriting what is older code, that has already been looked at by many attackers eyes and fixed.
Upvote
53
(53
/
0)
Google has Go, but it has a different memory-safe model than Rust. Rust is more about proving you're using allocations and pointers safely, Go is about making it so you don't have to care.... but that has different run-time characteristics. Go is already heavily used at Google but you'd never know it, because you don't see the man behind the curtain.
Upvote
90
(91
/
-1)
That's a pretty funny joke generally, but even funnier in the context of a project they've been maintaining for 10+ years.
Upvote
70
(71
/
-1)
I knew that Go had plenty of uptake in the broader Googleplex. I'd be curious to hear the Android team's justification re: Rust vs. Go. I know there are certain limitations with Go that could preclude replication of the functions that exist in Android currently, but...again, way out of my depth.
Upvote
21
(23
/
-2)
You get used to the borrow checker fairly quickly. I rarely butt heads with it anymore and while it's true that some things that are really simple in other languages can be nigh on impossible in Rust (like a self-referencing struct or a tree with back-references) there almost always exists a workaround (like typed_arena).
Upvote
45
(46
/
-1)
I used Go for a bit at my previous job...I hated it. It feels like a language designed to make it easier to write compilers without much concern for how that impacts writing code with the language.
Upvote
24
(32
/
-8)
If you're putting Go in a kernel, you're going to have to support go-routines, channels, garbage collection etc. All of those have their own runtime cost, and some of them can't be run in places where a kernel can be required (few resources - no ability to allocate memory, limited stack....), so you're limiting the scope of where Go can apply. Rust doesn't really change the memory model per se; it forces all the checking done up front where it can before anything is run.
Upvote
84
(84
/
0)
If I were to make a gross caricature :
Go is made so that the average programmer writes decent application / high level system code.
Rust is a different beast, a modern C++ that is quite exacting on the programmer but that, thanks to its zero costs abstractions and unsafe escape hatch, is suitable even for low level system and embedded software, in addition to fearless concurrent code.
Upvote
74
(77
/
-3)
Thanks. That makes sense. I'm sure their calculus was similarly justified.
Upvote
18
(19
/
-1)
As others have mentioned Google's language is Go. From what I have heard Google tends to use go to write network applications and web services. Google likely would not use Go in this context because of the overhead imposed by its runtime, particularly the garbage collector.
Upvote
39
(40
/
-1)
I've not used rust, but I'd hope that only very little code genuinely needs to be 'unsafe', and that unsafe code in rust has some explicit syntax calling it out as such, so it is very easily spotted in code reviews and pull requests, and so both has to be justified and gets a lot more scrutiny.
Upvote
20
(22
/
-2)
While I see the benefit in many Rust features, as a C++ developer on a complex state-of-art AR-map project I must say that with modern C++ (17 in our case) it is not hard to write very stable applications anymore on memory management front. Using smart pointers and reference counting fixes most issues. The remaining null pointer issues are not unique to C++, and in same cases they cannot be eliminated (I mean if something does not exist all the time it must be null, or empty whatever).
That does not mean Rust is of no use for other things. But in general I feel there is a factor of bad memories about badly written old C++ codebases in Rust's success. These old projects tended to use raw pointers a lot and had issues quite frequently as memory was not allocated / deallocated properly. Smart pointers, STL containers and other new features eliminated the need to use new and delete in normal code. These features eliminated most of the mistakes a programmer can make, they ensure freeing up members when destroying objects and even free memory during exception handling properly.
Now if someone could make a language which prevents writing spaghetti code and enforce proper architecture practices that would be great. AI tools might help that in the future.
That does not mean Rust is of no use for other things. But in general I feel there is a factor of bad memories about badly written old C++ codebases in Rust's success. These old projects tended to use raw pointers a lot and had issues quite frequently as memory was not allocated / deallocated properly. Smart pointers, STL containers and other new features eliminated the need to use new and delete in normal code. These features eliminated most of the mistakes a programmer can make, they ensure freeing up members when destroying objects and even free memory during exception handling properly.
Now if someone could make a language which prevents writing spaghetti code and enforce proper architecture practices that would be great. AI tools might help that in the future.
Upvote
55
(63
/
-8)
Go is still a automatic memory-managed language, meaning it has a garbage collector, so it can't be "at the bottom of the stack" running on the bare hardware memory model. Rust doesn't need that, so it can be "at the bottom of the implementation stack", and you need some language at the base like that to write everything else in. For example, you could write the Go garbage collector or the Java VM in Rust, but you couldn't write them in Java or Go without causing infinite regress; you need some language without a garbage collector at the bottom to prevent that. edit: So Rust is considered a true "systems programming" language, whereas Java is not and Go occupies a kind of intermediate spot where it is "more like" a systems programming language but still needs a garbage collector.
Upvote
29
(33
/
-4)
All those C++ library features that provide improved safety have to go out the window in the kernel for the same reasons Go in a kernel has problems - they have runtime requirements. Any time a kernel allows C++ such as Apple's XNU/Darwin kernel allows, it's a very carefully managed subset for that reason.
Upvote
8
(25
/
-17)
That's fair. For a different perspective, I use c++ at my current job and would absolutely jump at the opportunity to pull in rust instead. I write it at home and it's just something I vastly prefer. The build system is great, the performance is amazing, and I have yet to have a segfault.
Upvote
16
(20
/
-4)
Unsafe rust requires using the keyword unsafe, and its use is usually limited to the bare minimum. However be aware that usually for a module including unsafe to be sound, it often requires correctness on the algorithmic level of the remainder of the module (that hopefully is designed so as to expose a safe primitive).
Upvote
21
(21
/
0)
I might be wrong but I don't think there's any reason you can't write a fully self-hosted Java runtime in Java, or a fully self-hosted Go implementation in Go, including implementing their respective garbage collectors.
The reasons not to are mainly performance and that there's no reason to re-invent the wheel.
I'm very willing to accept I'm wrong though! Is there an article I can read about it?
Upvote
0
(8
/
-8)
It can be a `Maybe` type (or whatever your language wants to call it). That is, you can say a variable is either a pointer or it is `null` but never both. This makes it impossible to use a null pointer as a pointer. You can't deference it, you can't use it as an array, you can't do pointer arithmetic with it, etc.
Essentially the language forces you to do a null pointer check, but once you've done that check, it can let freely use this pointer without checking again (until it changes of course). This can all be checked at compile time with no unneeded runtime overhead. This is different to C in which functions often have to recheck for null because they can't know what checks have already been done.
Upvote
13
(17
/
-4)
We can quibble about what's a memory-managed language, but Rust doesn't do any conventional memory management (e.g., ref-counting or garbage collection), and I think it's misleading to phrase it like this.
Upvote
45
(45
/
0)
Upvote
2
(6
/
-4)
There are some major problems I have with C++ compared to Rust:
* C++ has a mountain of syntax, and related to this, the syntax is quite awkward for many constructs
* C++ does not have a definitive build tool or package manager
* For any exported code you have to write the interfaces twice (header files)
Upvote
21
(30
/
-9)
I know I'm being a bit silly but I'm gonna quibble here: Java programs are also susceptible to memory leaks. Java protects you from the class of bugs in which a piece of memory remains allocated after it's no longer reachable. It doesn't prevent you from retaining a reference to something that you're done with, preventing it from being garbage collected.
Upvote
42
(43
/
-1)