#bindings #python-bindings #codegen #ffi-bindings

interoptopus

The polyglot bindings generator for your library (C#, C, Python, ...). 🐙

76 releases

Uses new Rust 2024

new 0.15.0-alpha.2 Mar 28, 2025
0.14.27 Sep 13, 2024
0.14.26 Jun 29, 2024
0.14.23 Feb 14, 2024
0.5.2 Jul 30, 2021

#32 in FFI

Download history 1232/week @ 2024-12-06 1114/week @ 2024-12-13 851/week @ 2024-12-20 886/week @ 2024-12-27 1184/week @ 2025-01-03 1584/week @ 2025-01-10 924/week @ 2025-01-17 610/week @ 2025-01-24 1365/week @ 2025-01-31 898/week @ 2025-02-07 841/week @ 2025-02-14 481/week @ 2025-02-21 619/week @ 2025-02-28 1033/week @ 2025-03-07 724/week @ 2025-03-14 854/week @ 2025-03-21

3,314 downloads per month
Used in 6 crates

MIT license

175KB
3.5K SLoC

crates.io-badge docs.rs-badge license-badge rust-version-badge rust-build-badge

Interoptopus 🐙

The polyglot bindings generator for your library.

Write a robust library in Rust, easily access it from your second-favorite language:

  • Design a single .dll / .so in Rust, consume it from anywhere.
  • Get QoL features (e.g., classes, strings) in languages that have them.
  • Painless workflow, no external tooling required.
  • Easy to support more languages, backends fully decoupled from main project.

We strive to make our generated bindings zero cost. They should be as idiomatic as you could have reasonably written them yourself, but never magic or hiding the interface you actually wanted to expose.

Code you write ...

#[ffi_type]
pub struct Vec2 {
    pub x: f32,
    pub y: f32,
}

#[ffi_function]
pub fn my_function(input: Vec2) {
    println!("{}", input.x);
}

// List functions you want to export, types are inferred.
pub fn ffi_inventory() -> Inventory {
    InventoryBuilder::new()
        .register(function!(my_function))
        .validate()
        .build()
}

... Interoptopus generates

Language Crate Sample Output1 Status
C# interoptopus_backend_csharp Interop.cs
C interoptopus_backend_c my_header.h ⏯️
Python interoptopus_backend_cpython reference.py ⏯️
Other Write your own backend2 -

Tier 1 target. Active maintenance and production use. Full support of all features.
⏯️ Tier 2 target. Might be missing features or UX, contributors wanted!
1 For the reference project.
2 Add basic support for a new language in just a few hours. No pull request needed.

Getting Started 🍼

If you want to ...

Supported Rust Constructs

See the reference project for an overview:

  • functions (freestanding functions and delegates)
  • types (composites, enums, opaques, references, ...)
  • constants (primitive constants; results of const evaluation)
  • patterns (ASCII pointers, options, slices, ...)
  • services (turn to classes in C# and Python, and async methods)

Performance 🏁

Generated low-level bindings are zero cost w.r.t. hand-crafted bindings for that language.

That said, even hand-crafted bindings encounter some target-specific overhead at the FFI boundary (e.g., marshalling, pinning, and safety checks). For C# that cost is often nanoseconds, for Python it can be microseconds.

Detailed call cost tables can be found here: 🔥

For a quick overview, this table lists some common round trip times in ns / call:

Construct C# Python
primitive_void() 3 (TODO)
primitive_u64(0) 4
pattern_option(Option.None) 14
pattern_delegate_adhoc(x => x[0]) 477 1
pattern_delegate_retained(delegate) 21
pattern_ascii_pointer("hello world") 20
pattern_utf8_string("hello world") 52
await serviceAsync.Success() 361 2

1 First time delegate creation and pinning is expensive in C# (100's of ns). We recommend you retain the delegate instead for >20x faster calls, see for example here.
2 Preliminary numbers for full round trip to tokio and back. Although async calls have some intrinsic overhead (e.g., spawning a new TaskCompletionSource is ~100ns), some of that overhead appears to be a benchmarking effect when spin-waiting for a newly spawned task. In essence, if your application benefits from async this overhead is negligible, but simple getters or setters shouldn't needlessly be made async.


Feature Flags

Gated behind feature flags, these enable:

  • derive - Proc macros such as ffi_type, ...
  • serde - Serde attributes on internal types.
  • log - Invoke log on FFI errors.

Changelog

  • v0.15 - Massive cleanup, bugfix, UX overhaul (+syn2).
  • v0.14 - Better inventory UX.
  • v0.13 - Python backend uses ctypes now.

Also see our upgrade instructions.

FAQ

Contributing

PRs are very welcome!

  • Submit small bug fixes directly. Major changes should be issues first.
  • New features or patterns must be materialized in the reference project and accompanied by at least an C# interop test.

Dependencies

~0–275KB