Migrating SlateDB Bindings To UniFFI
After landing SlateDB bindings, several people asked about my experience with UniFFI. It's young and uneven, but still the right bet. Particularly so if you need async across runtimes.
Several people have asked about my experience with UniFFI after landing SlateDB binding work in PR #1462. I had a discussion in Discord, which I’m documenting here:
- If you care about multiple languages, UniFFI is the right thing to be on.
- It is still early. A lot of the bindings are young or infrequently maintained.
- The UniFFI maintainers have said they do not want to bless many first-class bindings, so the ecosystem feels a bit wild west right now.
- I still expect that to improve. The foundation is solid.
- Go is the easiest target. You can keep the API synchronous and avoid most of the hard runtime work.
- If I only cared about Go (or sync APIs), I would probably use
cbindgenand a simpler C FFI layer. - If you want your bindings to work with each language’s async ecosystem, UniFFI is great.
- I started down the path of
cbindgenfor async APIs, closer to what FoundationDB does across language bindings. It’s a heavy lift and LLMs did not work well with it. UniFFI let me avoid most of that.
UniFFI is young, uneven, but still the right bet. If I only needed Go, I would probably use cbindgen; if I needed one API across several languages, I would use UniFFI again.