3 ms·
> I would not recommend FFI + ctypes. Well it depends. C is the lingua franca of Computer Science. These days I write a lot of code that needs to be accessible
by forrestthewoods 3y ago
> I would not recommend FFI + ctypes.
Well it depends. C is the lingua franca of Computer Science. These days I write a lot of code that needs to be accessible to a variety of languages and environments. Python, C#, C++, Matlab, Unity, Unreal, etc.
Write a C API and your code can be used anywhere. Now if you know you only ever need to support Python then sure look into PyO3. But if you have mixed use you can’t be the flexibility of a C API.
- guitarbill 3y agoHonestly though, I would likely still choose to implement the logic in Rust as a crate/library in a workspace, the (C)Python extensions as a PyO3 dylib/separate crate, and a C FFI dylib as yet another crate. The benefit is that you only need to ship the CPython extension, you can build it with cargo, and everything's in one place. I've maintained bindings for Python and C# to native libraries, and it's usually a pain for various reasons. The C API might be able to be used anywhere, but that doesn't mean it's ergonomic, easy to use, or safe.
- forrestthewoods 3y ago> The C API might be able to be used anywhere, but that doesn't mean it's ergonomic, easy to use, or safe. Definitely true. That said I think there is an under appreciated beautiy to a clean C API. It’s easy to “upgrade” a C API with per-language/environment bindings. It can be near impossible to “downgrade” a high-level API to C.
- yazaddaruvala 3y agoAnd Rust just uses the C ABI, so wouldn’t your comments include “in Rust”?