[eggsnbacon1]

Do they really need to access thousands of C++ API calls from Rust? Doesn't this defeat the purpose of writing safe code in Rust? This smells of "not invented here" which applies to Google projects pretty often.

They should focus on integrating Rust in portions of the API instead of exposing a gigantic unsafe API surface, essentially making all their code unsafe. Unless the Chrome codebase is really such a mess that they can't do anything without exposing this giant API surface. In that case they should rewrite it to... not do that.

"We can't use Rust unless it allows us to write all our code in C++ without showing unsafe warnings"

[nitsky]

> Doesn't this defeat the purpose of writing safe code in Rust?

While the Chrome authors will not be protected from memory unsafety in the wrapped C++ APIs, the usage of those APIs in the new code they write on top will be safe, which is better than nothing. Similarly, much of the Rust standard library and many popular crates are "safe" wrappers around unsafe code, like calls to libc, winapi, openssl, etc. If there is a memory unsafety issue in one of those libraries, Rust won't save you.

[outworlder]

> Do they really need to access thousands of C++ API calls from Rust?

Yes. It's turtles all the way down. Applying this line of thought to its logical conclusion, it wouldn't be worth it until we have written the OS itself and all firmware in Rust.

[Ericson2314]

Just within the process. Between processes or process and kernel, there are already runtime checks, so Rust isn't contributing safety so much quality.