Migrating SlateDB Bindings To UniFFI

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 cbindgen and 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 cbindgen for 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.