4 ms·

I would like to see a comparison of how this compares to Rust. In terms of interoperability it has Cxx (https://cxx.rs https://cxx.rs) to offer safe bindings to

I would like to see a comparison of how this compares to Rust. In terms of interoperability it has Cxx (https://cxx.rs https://cxx.rs) to offer safe bindings to C++ but also has great support for Android, Linux and many other systems. You don't even need to hack together Windows bindings (as explained in the blog post) because Microsoft offers official bindings (https://crates.io/crates/windows https://crates.io/crates/windows). I'm not sure if I'd call it a superpower if any potential interoperability has to be written to be used (compared to it already being available). Or rather, in comparison to what is interoperability a Swift superpower? Certainly not C++ or C which can be used in a far wider set of targets.

zozbot234 3y ago
Swift simply has good interop with shared objects written in Swift. You're not forced to go through a raw C ABI for everything, whereas you have to do that in Rust (unless your shared objects are part of the same build). There are crates to make interop a bit easier, but they're not standard in any real sense. The flip side though is that once you have to build a raw C API/ABI for your shared object written in Rust, it becomes usable with any other language that has good FFI with C, which is most of them.
zer0zzz 3y ago
I've worked both with the Swift C++-Interop project and I've also spoken to the author of cxx.rs a little bit. The two approach the problem differently. Swift's approach is that you only need to provide a header (which you likely already have), and the compiler does all the rest to handle the bridging for you. cxx.rs' approach is that you use this crate to write a bridging file and so long as you follow the type set that cxx.rs understands you have a bridge (int, char, std::string, std::unique_ptr etc). They're both good approaches but the Swift approach is definitely much more ambitious and more user-friendly to the programmer.

zozbot234 3y ago

Swift simply has good interop with shared objects written in Swift. You're not forced to go through a raw C ABI for everything, whereas you have to do that in Rust (unless your shared objects are part of the same build). There are crates to make interop a bit easier, but they're not standard in any real sense. The flip side though is that once you have to build a raw C API/ABI for your shared object written in Rust, it becomes usable with any other language that has good FFI with C, which is most of them.

zer0zzz 3y ago

I've worked both with the Swift C++-Interop project and I've also spoken to the author of cxx.rs a little bit. The two approach the problem differently. Swift's approach is that you only need to provide a header (which you likely already have), and the compiler does all the rest to handle the bridging for you. cxx.rs' approach is that you use this crate to write a bridging file and so long as you follow the type set that cxx.rs understands you have a bridge (int, char, std::string, std::unique_ptr etc). They're both good approaches but the Swift approach is definitely much more ambitious and more user-friendly to the programmer.