Rust in Android: move fast and fix things

If I were to go to another company I’d promote using either of the above.

Proprietary code uses the internal version of Bazel: https://bazel.build/

But if I was working in C++ and had a choice of C++ or Rust, I’d go Rust based on this.

I’m sorry if this comes across as dismissive, but I find it hard to take people seriously with complaints about syntax like this. Learning new syntax is really easy. Like, if you’re familiar with C & Go, you could probably learn all the syntax of rust in under an hour. The only surprising part of rust’s syntax is all the weird variants of match expressions.

Rust has some surprising semantics. Like how lifetimes work (and when you need to specify them explicitly). That stuff is legitimately difficult. But learning that if statements don’t need parenthesis is like - seriously whatever dude. If you want to spend your career never learning new stuff, software isn’t for you.

I picked up objective C about 15 years ago. The only thing most of my friends knew about it was that it had “that weird syntax”. It took no time at all to adjust. It’s just not that hard to type [] characters.

I’ve found it a joy to use compared to CMake and friends. How does it make it harder to consume something downstream? Seems easy enough to me - just share the source crate.

Are you trying to distribute pre compiled code or something like that? I can see how that would be harder - cargo doesn’t really support that use case.

How would you improve cargo?

"Absolutely awful" strikes me as wild hyperbole -- you also meant it this way as well, right? What toolchains are not absolutely awful in your mind?

Cargo isn't perfect by any stretch of the imagination -- there are a few common complaints that people have and a bunch of sharp edges (most of which have a github issue that has been open for years), but... "absolutely awful" has to be hyperbole.

But that's just not how Rust works: it's trying to fit a square peg in a round hole, and it isn't Cargo's fault that you have trouble with it.

Cargo is a blessing for any source-available project. All bundled up, a `cargo build` away. Because don't you dare say CMake or autotools are better, that's just the stockholm syndrome kicking in because you're familiar with it.

Seriously, how a CMakeLists.txt can even be compared to a Cargo.toml file? One is imperative full of arcane conditions everywhere filled with boilerplate, while Cargo.toml is a declarative manifest of the package?

Though there is one very sore point when distributing software, and that is for distribution package maintainers, because the whole ecosystem has been built around the C model and dynamic linking. That is not even the fault of cargo, since Rust's ABI is not stable thus dynamic linking would not work most of the time. Another thorn is generic stuff, which needs to be monomorphized, and as such don't work with dynamic linking (without Box<dyn>); C++ actually has the same issue and is why there are so many "header only" libraries for it.

I'd call it casting thought technically maybe it's not you might want to call it something else? You don't need transmute or leak. The issue is only 10 years old now https://github.com/rust-lang/rust/issues/25860

The only way around this would be to have a absolutely strict type system that defines the finite sets of data that memory can hold.

But for compile time checks, its not hard. For example, the I would do it C is that every pointer gets an optional permission id through some syntax when created. Any expression involving modifying that pointer needs to have the appropriate permission id stated, any dereference operation needs to have the appropriate permission stated, and free is only limited to the function where the pointer was created with malloc. Then any pointer created in assignment from an expression involving that pointer inherits the permission id.

So you simply have a system of tracing where memory gets used.

But all of this is overkill tbh, when you can just use existing static memory analyzers that pretty much do the same thing. And coupled with dynamic memory analyzers like valgrind with appropriate testing, you don't even need to do runtime checks within your code.

Let’s end the C era.

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.

This is just a matter of tooling. (On that note, here is a free business idea, prompt engineer an LLM agent that sets this up for you)

While the compiler does do a lot of things for you, you still end up with things that you should check because compiler doesn't understand your program logic. If Rust was a absolutely strict typed language, where basically everything had a type that defined what data it could hold, then it would be a different story. For example, when parsing a json into an object, instead of strings/numbers/bools, every single field has a finite set of values that it can hold. Then the compiler can figure out a lot of things. For example, if you try to convert a string to int, if the string field type doesn't have a defined regex expression it must match, then the compiler can catch this.

Anything less then that, you are better of writing the validation system once and reusing it for all your code bases now and in the future.

I see you sir haven’t had experience with writing drivers for prerelease hardware. You’re right in these cases of course, you just aren’t right enough - the real fun starts when you can trust neither the hardware, nor the BIOS, nor the OS in addition to all the above.

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.

> Rewriting SymCrypt in Rust to modernize Microsoft’s cryptographic library

https://www.microsoft.com/en-us/research/blog/rewriting-symc...

I think they're trying to avoid rewriting things for no reason though. The things being rewritten tend to have a history of security problems or other issues that would be cause for a rewrite even if it wasn't in Rust.

  Chromium: Parsers for PNG, JSON, and web fonts have been replaced with memory-safe implementations in Rust

2. You can still write bugs in Rust but the point is you are far less likely to.

In other words, they're upset that a new thing isn't popular so they're trying to think of any argument against it, but none of their arguments are relevant. Yes, you can still write bugs in Rust; of course you can. What you can't do is write memory safety bugs in Rust, which are a huge proportion of security bugs that occur. Rust gives you a massive decrease in attack surface automatically.

This is ignoring the ecosystem, which is full of better tooling, better library packaging, better testing, and just in general an overall better language, but instead of trying to argue the language on its merits they're trying to argue that it's not perfect so why bother.

I've also heard the same arguments about C++; 'anything you can do in C++ you can do in C!', which is technically true but ignores the fact that if I want to do something C++ does it usually makes more sense to use C++ to do it rather than e.g. trying to hack the concept of objects, private methods, templates, etc. into C myself.

Lol, this is actually very ironic considering Rust is handholding you because you don't have the skills to write memory safe code.

Like I said in my other posts, Rust makes sense in very niche situations. The article just proves that it works for the niche case where its applicable. That doesn't mean Rust automatically wins.

I mean, the linux kernel is a pretty good example. Static analyzers and things like valgrind exist for a reason.

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?