Stream: compiler development

Topic: rust crABI

Brendan Hansknecht (Sep 17 2023 at 15:06):

Not sure how this isn't bigger news and I missed it, but rust is making their own abi (just in the experiment phase, but an official rfc experiment).

The abi would enable the common cases around ownership and borrowing to be preserved when doing ffi. Also, it would allow more complex rust types to be passed. No more being limited to char* for strings or being unable to pass results over ffi. They even want to support some closures and trait objects with attached crABI methods that can be called from the other language.

Side note: found this on the zig subreddit with someone thinking it would be a great way to put all of your unsafe rust in zig. Instead of an unsafe block, just a crABI call to a zig function.

https://github.com/rust-lang/compiler-team/issues/631

Brendan Hansknecht (Sep 17 2023 at 15:08):

They even want to support extern "crabi" async fn

I woulder if we could eventually make a roc call support that and run directly on the rust state machine for async. Just interesting ideas.

Richard Feldman (Sep 18 2023 at 01:13):

so like --target for ABIs...I'd never really thought about building for any other than C! (Let's be honest, C ABI is a big enough project as it is...) I guess Swift also has its own ABI?

Brendan Hansknecht (Sep 18 2023 at 02:05):

I see two main potential gains:

1. Rust calling rust shared or static libraries can use way more rust types and specify borrowing semantics. This would all be in totally safe rust.
2. It enables writing safe ffi to other languages. So you could have a safe rust function that calls into zig and zig does anything unsafe.

An important part of this work is that you get more borrow checker validation when calling something over ffi. Less likely to mess something up in unsafe code wrapping a function when you instead clearly define the ownership and borrowing in the ffi definition.

Last updated: Jul 26 2025 at 12:14 UTC