this post was submitted on 09 Mar 2024
48 points (100.0% liked)

Rust

5960 readers
2 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 10 points 8 months ago* (last edited 8 months ago) (1 children)
[–] [email protected] 5 points 8 months ago* (last edited 8 months ago) (2 children)

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?

[–] [email protected] 2 points 8 months ago

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.

[–] [email protected] 2 points 8 months ago* (last edited 8 months ago) (1 children)

@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 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 https://doc.rust-lang.org/nomicon/ffi.html for how this is done manually.

[–] [email protected] 1 points 8 months ago

@varsock If you plan to refactor the architecture to convert things into microservices, grpc is also a solid way to go.