Secure by Design: Google’s Perspective on Memory Safety (
from to on 09 Mar 2024 10:19


threaded - newest on 09 Mar 2024 11:51 next collapse
  • We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety.
  • A large-scale rewrite of all existing C++ code into a different, memory-safe language appears very difficult and will likely remain impractical.

Tough spot to be in, but I’m glad there are more and more people calling out for a transition away from C/C++. One can only hope that Rust doesn’t become the new C++ aka the garbage dump of programming languages. Every large player wanted to write C++ in their own way, so they added it to the language and now we have this… thing.

CC BY-NC-SA 4.0 on 09 Mar 2024 13:38 next collapse

In the long run, I wonder if rust will spawn a family of new memory-safe languages. on 09 Mar 2024 13:40 next collapse

Statically typed, compiled, memory safe languages? I can live with that 👌

CC BY-NC-SA 4.0 on 09 Mar 2024 18:16 collapse

I am also very interested in seeing what the next generation of Rust-inspired languages will look like, and not because I am dissatisfied with Rust today. Rust has significantly raised the bar of how a good programming needs to work and any new language in the systems programming area (and beyond) will inevitably be compared to it. on 10 Mar 2024 10:45 collapse

Finally, the victory of the ML family is at hand! Just like RISC over CISC. It just took a long time. on 09 Mar 2024 14:48 collapse

Unfortuately c++ interoperability is hard. I wouldn't write c++ without vector and other containers (templates). Or classes complete with inheiritance (rarely multiple) and thus name mangeling. I now have millions of lines of that stuff and it is hard to write anything else because it has to mix. on 09 Mar 2024 14:52 next collapse

At work, we started the c++ migration to rust doing the following:

  1. Identify “subsystems” in the c++ code base
  2. Identify the ingress/egress data flows into this subsystem
  3. Replace those ingress/engress interfaces with grpc for data/event sharing (we have yet to profile the performance impact of passing an object over grpc, do work on it, then pass it back)
  4. Start a rewrite of the subsystem. from c++ to rust
  5. Swap out the two subsystems and reattach at the grpc interfaces
  6. Profit in that now our code is memory safe AND decoupled

The challenge here is identifying the subsystems. If the codebase didn’t have distinct boundaries for subsystems, rewrite becomes much more difficult on 09 Mar 2024 15:29 next collapse

@varsock @Timely_Jellyfish_2077 out of curiosity, why use grpc in lieu of ffi? on 09 Mar 2024 22:38 collapse

I don’t think I am well positioned to answer that question given my experience. Ill give it my best.

I believe the advantage of more abstraction of gRPC was desireable because we can point it at a socket (Unix domain or internet sockets) and communicate across different domains. I think we are shooting for a “microserves” architecture but running it on one machine. FFI (IIRC) is more low level and more about language interoperability. gRPC would allow us to prototype stuff faster in other languages (like Python or go) and optimize to rust if it became a bottleneck.

Short answer is, we are able to deliver more value, quicker, to customers (I guess). But I don’t know much about FFI. Perhaps you can offer some reasons and use cases for it? on 10 Mar 2024 00:04 next collapse

FFI is just calling Rust directly from something else (or vice versa), and has pretty much no performance compromises. The main downside is potential safety implications at the FFI boundary (i.e. need to guarantee Rust doesn’t release C++ memory or vice versa), but if you’re already fine with gRPC performance penalties, you can just copy everything at the boundary and not worry about it.

It’s basically the way Python native modules work, and can be used between any C-compatible languages. on 10 Mar 2024 02:49 collapse

@varsock rust has very good code generation for C (and sometimes C++ as well) headers via `bindgen` ( This allows you to potentially make minimal changes to the code without having to refactor to use a new protocol on the legacy side, and has faster performance (benchmark to confirm), since there’s no serialization/deserialization step. See for how this is done manually. on 10 Mar 2024 02:50 collapse

@varsock If you plan to refactor the architecture to convert things into microservices, grpc is also a solid way to go. on 09 Mar 2024 15:44 collapse

Sounds like you’re well on your way with a good process. The book Software Architecture: The Hard Parts is a pretty decent guide to breaking apart a monolith. It’s not a 100% follow it to the letter guide IMO, but I think the overall approach makes sense. At each step you have to consider trade-offs instead of following any kind of dogma. on 09 Mar 2024 15:19 collapse

Dang. It seems like there is a lot of momentum around transitioning away from C/C++.

Is C++ going to be the new FORTRAN/COBOL/PERL in 30 years? on 09 Mar 2024 16:10 next collapse

Sign me the fuck up, I want to get paid absurd amounts of money to do basic stuff in a language I am already proficient in on 10 Mar 2024 10:43 collapse

It seems like there is a lot of momentum around transitioning away from C/C++.

There is. But it won’t be fast, because of the humongous amount of existing C and C++ code. They won’t disappear for a long time, it will just get less and less over time.