4 ms·
If you're writing an embeddable database, exposing it as a C library maximizes the potential user base. Since most languages have some way to do ffi with C, mo
by tyingq 4y ago
If you're writing an embeddable database, exposing it as a C library maximizes the potential user base. Since most languages have some way to do ffi with C, most platforms have C compilers, etc.
- josephg 4y agoC FFI goes both ways. It’s also pretty easy to compile rust or zig code into a static or dynamic C library. And then that library can be used directly from C or from anything that has a C FFI (Python, Ruby, javascript, Java, etc etc). I’ve been working on an iOS app lately with some of the core code in rust (shared with other platforms) and the UI in native swift. Changing the API at the boundary is a bit annoying, but the resulting app works great.
- plagiarist 4y agoWhat are the ergonomics of compiling that binary library? I think this sounds really neat, if you have a build system that produces something like an .xcframework and corresponding package file it wouldn't even be a pain point.
- josephg 4y agoYeah; thats exactly what I have. I have a script which compiles the rust code for all the combinations of hardware (arm & x86_64 on ios & macos) and produces an .xcframework. Then I just recompile my xcode project. Its a bit hacky, but it works fine. I'm using the swift_bridge crate to generate a lot of the bindings and generate the .xcframework. https://github.com/josephg/replica/blob/master/build_swift.sh https://github.com/josephg/replica/blob/master/build_swift.s...