At work, we started the c++ migration to rust doing the following:
Identify “subsystems” in the c++ code base
Identify the ingress/egress data flows into this subsystem
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)
Start a rewrite of the subsystem. from c++ to rust
Swap out the two subsystems and reattach at the grpc interfaces
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
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.
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?
@varsock rust has very good code generation for C (and sometimes C++ as well) headers via bindgen (https://github.com/rust-lang/rust-bindgen). This allows you to potentially make minimal changes to the code without have 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.
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.
At work, we started the c++ migration to rust doing the following:
The challenge here is identifying the subsystems. If the codebase didn’t have distinct boundaries for subsystems, rewrite becomes much more difficult
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.
@varsock @Timely_Jellyfish_2077 out of curiosity, why use grpc in lieu of ffi?
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?
@varsock rust has very good code generation for C (and sometimes C++ as well) headers via
bindgen(https://github.com/rust-lang/rust-bindgen). This allows you to potentially make minimal changes to the code without have 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.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.