Conversation

IMO the Chrome article on why borrow checking is impossible in C++ largely misses the point. The biggest issue is simply that virtually no C++ code is written under the invariants that the borrow check enforces, so C++-plus-borrow-check loses compatibility with existing C++.

231

Replying to

I agree. But my read of the article is it was to serve as a technical rebuttal for people saying “but C++ can do this too.” As written, it is rather effective at preventing C++ stalwarts from pushing an invalid argument!

Replying to

and

If you say “you need to change how you write C++,” people will say “then we’ll change how we write C++.” But if you say “you can’t do this if you tried: here’s the proof/code” it cuts off the debate.

Replying to

Well, I feel like if you modified the language a LOT you could do something that resembles "add borrow checking to C++". But that's my point: such a modification of C++ will by definition have the same restrictions as Rust, including that you can't make mutable shared_ptr.

Replying to

and

I feel like folks working on Chrome have been "trying" forever? Perhaps it is now time to face reality that you can't do it. And the answer is not to stop trying, it is to try something different...

Replying to

and

I think most of their engineers have already come to that conclusion a long time ago, but they need to make the case that C++ is a dead end and then to specifically adopt Rust as the solution. They're not going to invest millions of dollars into it without lots of research.

Replying to

Android integrated Rust as one of the first-class languages (Kotlin, Java, C++, Rust) and will be moving to using it for most new low-level components. Android 12 has a Rust-based Bluetooth stack. As long as that goes well, you can expect a whole lot more Rust in Android 13+.

8:34 AM · Sep 22, 2021Twitter Web App

Replying to

ChromeOS and Fuchsia have been using Rust in certain areas already. Chrome hasn't started using it outside of ChromeOS though. Each of these is essentially a separate sub-organization within Google and makes their own decisions about languages. Each has pretty much rejected Go.

Replying to

As far as I know, Google isn't using much Rust outside these 3 sub-organizations. I expect they're replacing a lot of their C++ and Java elsewhere with Go, although they're still likely to start using both Rust and Kotlin as replacements for those. It's a huge decision to make.

Show replies