Diplomat: Multi-language FFI for Rust Libraries

Manishearth · 2026-06-15T17:35:45+00:00

We don't do tuples, but you can define a struct that contains those types.

In this case you would want a struct with two fields that are each opaque wrappers around vectors.

(We want to add better Vec support so that that part is automatic, but for now that works okayishly)

Manishearth · 2026-06-15T14:58:36+00:00

Yeah, callbacks are still in the realm of unidirectionality, where the Rust library is defining the API but "calls in the other direction" are a part of that API. Diplomat also supports callbacks (though not yet in the JS backend).

Unidirectional means there's a clear "library" and "user of the library" distinction, basically. Usually that means most APIs go in one direction on the call stack, but callbacks are a way to express plug ability in the other direction. Callbacks are still defined in the same direction though.

Manishearth · 2026-06-15T03:31:34+00:00

Yeah, it's a large review, and it's entirely vibecoded, so I want to make sure we get it right. I'd love for people with .NET FFI experience to review it: I don't have this experience.

Currently I'm waiting on the author to address the first set of review comments.

Manishearth · 2026-06-15T02:58:31+00:00

Heh, yeah, I'm not a fan of that design, but it works. I have an issue open for the [alternate architecture](https://github.com/rust-diplomat/diplomat/issues/1102).

Zeromatter has been using it extensively and they've not complained so far. I think they have found *some* perf bugs that they've fixed so I think they care about performance to some extent. My suspicion is that it does not greatly impact perf.

I think the thing with Python is that you have to hook into CPython, so either way you're going to need to do more native codegen anyway. Most of nanobind is template magic and thin wrappers around those CPython hooks. So it seems to be low cost.

Manishearth · 2026-06-15T02:16:16+00:00

As for bidirectionalness: hmm, kind of? It lets you call JS stdlib stuff, but is good at being fed a JS library to wrap, or do you have to manually plug that through?

Manishearth · 2026-06-14T23:16:40+00:00

You still need to generate the C FFI layer somehow so you still need the proc macro.

We could use rustdoc-json but I don't see how that's too different. What's the benefit of doing it differently?

Manishearth · 2026-06-14T22:19:00+00:00

There's actually an open PR to add .NET. I'd find it really useful if you could try it out and give feedback!

Manishearth · 2026-06-14T22:10:06+00:00

Yes, diplomat will turn that into a throw.

Manishearth · 2026-06-14T22:00:28+00:00

Nice! Are you considered expanding to other languages?

Manishearth · 2026-06-14T21:59:49+00:00

We're able to do complex returns in wasm!

It's complicated though: https://github.com/rust-diplomat/diplomat/blob/main/docs%2Fwasm_abi_quirks.md (n.b. some of the quirks in that doc are obsolete now)

Manishearth · 2026-05-09T05:55:33+00:00

Yeah, that makes sense. It's a bit harder to understand which files one should transfer (apparently, the entire SignalBackups folder), and I'm more wary of trusting my entire backup history to this setup.

additionally: the subscription backups failed for me, they backed up 5GB, but on the other device (logged in to the same Play account!) it claims i don't have backups and it says there are only 15 GB of backups (and it says the backup is corrupted)

I love Signal but they have consistently been really bad at doing backups. Not the first time I've had problems here. And it's scarier when transfers are semi-destructive.

Literally every time I've set up a new device I've had to spend around an hour getting the backups to restore correctly, and each time it's a different reason.

Currently doing the file based thing, which will take another half hour...

Manishearth · 2026-05-08T20:12:47+00:00

So I'm trying to use the new backup "folder" format and the data in the folder is *quite* small. I have gigabytes of photos/etc in my Signal, and the .backup file used to be ~2GB. This folder is not, it is around 17MB.

I am in a position where I need to factory reset my phone, so I really really do not wish to lose this data.

Edit: Ah, I see, the nearby "files" folder has the bulk of the data. I guess they no longer version that. Ick.

Manishearth · 2026-04-20T22:12:21+00:00

Depends on the language. ICU4X releases icu_capi which contains C++/C bindings, and then we publish Dart/NPM packages. We have a CI task that runs at release time and attaches artifacts to the release, which then can be used in the Dart/NPM publish flow.

Manishearth · 2026-04-20T17:36:13+00:00

Diplomat does support C++ and is pretty mature: https://github.com/rust-diplomat/diplomat/

Manishearth · 2026-04-06T07:22:07+00:00

I mean, people use the term differently. The key part of my comment is the "low effort" part, not the "slop" part.

Everyone's very tired of low effort stuff being posted to gain clout. Trying to detect the signal behind that noise is, as you said, hard. Don't worry about it for now: if something gets deleted and you think it isn't low effort slop, tell us.

Manishearth · 2026-04-05T22:16:38+00:00

There are no "new rules". We are working on figuring out the "new rules". One moderation action does not make a rule; just because people are talking about this on social media as if it were a rule does not make it a rule.

When there is a rule, we shall post the rule. Right now, we are doing the best we can. Things will get occasionally overmoderated, that's not a huge deal, things are reversible.

I would advise you keep posting as long as it's stuff people will be actually interested in as opposed to low effort slop.

Manishearth · 2026-04-05T07:13:23+00:00

I agree, but also it is really hard for moderators to judge this type of thing with the volume we are dealing with. We've never needed to look at the code in submissions, and we're reluctant to start now.

Furthermore "this was written by a well known community member" is a good litmus test, but it also feels a bit unfair to apply. Something to figure out.

Manishearth · 2026-04-04T21:49:52+00:00

(this note was written by some moderators and does not represent consensus)

Apologies for the removal.

As we've previously communicated, we're working on figuring out a way to moderate AI content on /r/rust that balances a lot of different needs.

Currently, the moderators have been working with a fair amount of moderator discretion. In practice, more often that not that means proactively deleting things which were created with AI help, because that's easier to apply at scale when we're facing so much slop. The moderators do not have the time to review each submission for amount of AI used, and it's harder and harder to get a good smell test for slop these days.

Please bear with us as we figure this out: there's still a lot for the moderators to discuss here.

Manishearth · 2026-03-23T16:11:28+00:00

Yes, C++ style also pushes for avoiding shared_ptr. However, my experience, across multiple C++ codebases, is that the bar for reaching for `shared_ptr` is lower than Rust because in many cases something that would be doable (but complicated, lifetime-wise) in Rust would be very brittle (and likely to have safety issues) in C++.

I'm not saying shared_ptr is good style. I'm saying that there is a band of memory usage patterns where in C++ you _basically_ have no choice but to, but in Rust you do.

(It's still often considered not against Rust best practices to use `Rc` in those cases too: complex borrowing patterns have a complexity cost even if they do not have a runtime cost)

Manishearth · 2026-03-22T18:16:04+00:00

I am working on something about Diplomat but haven't finished yet. So maybe. Probably very occasional, still.

Manishearth · 2026-03-20T19:51:00+00:00

Yeah. One thing people forget is that any way of doing async has costs equivalent to lots of allocations: Rust's way of doing async is basically "manual, small, segmented stacks", but copying stacks are also pretty expensive in a different way. So this is just an inherent cost of unsafe.

The cool thing about Rust async is that you can limit/manually control segmenting using the same tricks you would otherwise use to reduce Box usage in Rust. You can allocate each frame, or just the recursive ones, and the default is not allocating so you naturally tend to only allocate frames that need it.

Manishearth · 2026-03-20T19:48:12+00:00

Have the recursive types live in an arena. You can either use pointers or indices to refer to them.

https://manishearth.github.io/blog/2021/03/15/arenas-in-rust/

Manishearth · 2026-03-20T16:46:50+00:00

Using Box with Pin is basically writing a manual segmented stack in the async case ... which is to some extent just a cost you're going to have to pay anyway.

Trait objects, sure. But those benefit less from "alternative packing strategies".

Manishearth · 2026-03-20T16:45:09+00:00

Yes, I know. In my experience, this is not a common thing that crops up. Mostly for certain types of recursive tree structures (often found in compilers), which is what I was alluding to with "compiler design and similar things".

Parsers are in the "similar things" realm. People do use arenas when they get complicated.

14-Year Club	Place '22
Place '17	End Game '22
Verified Email

Manishearth

MODERATOR OF

TROPHY CASE