Rust and C++ Interoperability in Chrome

I didn't want to suggest it's undefined, I said weird. In C++, it's reverse declaration order, and that's important because destruction exactly mirrors construction. Arguably, Rust is completely wrong here, but my experience is that this problem doesn't come up in idiomatic Rust all that often because fields can't depend on each other anyway. And I'm wildly speculating of course, but something like that might be more of an issue if a lot of unsafe C++ objects are instantiated from within Rust.

Most of the fun stuff your computer is doing right now is the direct result of C and C++ code (browser, kernel, web server, games, etc.). Replacing all that code in one go isn't going to happen. Still, Rust solves some real problems with C++, so we shouldn't ignore it. If we can't replace the world all at once, why not do it piecemeal while targeting the highest value components?

> The bar for safety is lower than you might expect, for example, crashing with a “panic” in case of an error is completely fine, that’s not considered unsafe.

Yes, because "safety" in English is not analogous to "unsafe" in Rust in any real manner. They are linked only in the loosest conceptual way. Rust's "safety" and "unsafe" are well defined and exact, and can be objectively determined. In the English language it is by its nature subjective.

> The usual understanding is that an unsafe function is any function that can, if passed the wrong arguments, cause Undefined Behavior.

That is, specifically AFAIK, not what it means in Rust. It's well defined there, so there's no need to resort to "the usual understanding". This causes a lot of confusion, but it doesn't need to. If someone is talking about the unsafe keyword in Rust, they're talking about Rust's definition of it and what it entails, or they're using incorrect terminology.

> Presumably, the C++ wrappers suggested here would not even be safe in that sense. They would use a lot of pointers, and cause UB if passed the wrong one.

Then there's not a lot of point in using Rust if they refuse to change that usage. It's not about using Rust to check off a box that you use some buzzword technology, it's about leveraging what it can provide that other languages can't, or can't do as well.

If someone finally decides to put a firewall in front of a server but decides its' too hard to actually limit traffic in any way so allows 0.0.0.0/0 any port, you don't congratulate them on their firewall, you tell them they just wasted everyone's time and money.

> The article argues that using unsafe correctly is impractical for Chromium because basically every Rust function would have to be marked unsafe to call into these raw C++ APIs.

To my knowledge, the way Firefox did it was to pick a system or library, provide a Rust replacement that C/C++ could call, and allow it to be moved into place. That's sane. Using rust and C++ functions on the same memory and expecting Rust to deal with C++'s pointer shenanigans may not be, in the same way I wouldn't expect mixing small amounts of Java in the JVM into a big C++ would just work unless you had hard rules about who controlled what memory/objects and made sure you never broke them.

I can't help but feel they're approach is likely to cause them more problems than needed because they're not willing to commit the sane minimal amount to make a lot of these problems not matter (replace a small self contained system). If they don't actually have any small self contained system, and they really are just passing stuff around and using some complex pointer control, and aren't willing to change that, maybe Rust isn't a good candidate to extend their project languages with.

If only a certain foundation's corporate half didn't fire its Rust browser developers.

> So building Chromium becomes even more complex.

Suck it up and get used to it. Rust is absolutely the future of systems development; every major C or C++ project -- including the kernel -- is going to have a Rust interoperability story, and eventually, major components that implement desirable features written entirely in Rust, so in the interim, until the desirable but currently unrealistic goal of migrating all extant C and C++ code to Rust is achieved, you will need to have both C(++) and Rust tooling (and whatever else) to build the project.