The State of Swift & Rust interoperability?

[AliMark71 (Ali AlSalman)]

I want to ask about the current state of Swift and Rust interoperability, how hard is it currently to mix the two languages, and if it isn't great for now, is there any plans to make it better?

I think that rust is proven to be a great language, I also like swift, and swift is also better while developing for Apple platforms, I think it could be very great to get the benefits of both languages, like for example using rust to accelerate some performance critical aspects of some swift project.

[Nobody1707]

While there was an, apparently abandoned, attempt by the Rust team to add the Swift ABI as an option for #[repr({language}], currently the only way to interoperate is through a C ABI shim layer.

However, both languages have very good C interoperability, so it isn't that bad. And Swift has experimental C++ interop support, whereas Rust has the CXX crate, so theoretically you could use C++ as the glue language.^[1]

---

1. I can't recommend that yet though, Swift's C++ interop still has a lot of rough edges ↩︎

[Sajjon (Alex Cyon 🇸🇪 ❤️ 🇺🇦)]

Do you know of UniFFI?

We at Radix are using it in Sargon - a Rust library for sharing code between our iOS and Android apps.

UniFFI is a great tool for using a Rust core with mobile apps - since it generates Swift code and Kotlin code ready to be used in each native code base.

[vns]

@sipefree

It seems to me that Rust and Swift are naturally fit for tight interoperability, as many of the underlying concepts surrounding memory safety have 1-1 correlations, as do many higher level concepts like protocols and traits.

Not quite, at idea level these languages have quite opposite view on memory management particularly. When Rust has by default borrow checker, and opt-in reference counting (in two versions - Rc and Arc, where A is for atomic, not automatic), Swift goes opposite way with automatic reference counting, that has hidden underneath solution to use atomics or not, and recently has added move-only types and borrowing concepts, that are opt-in. IMO that is a substantial difference between two languages making it harder to enable tighter interop based on that.

What might be more interesting in that case is their LLVM basis, that can act as common ground, but that’s just a theory. Obviously, it’s easier right now to just use C (nice article on that topic — C Isn't A Programming Language Anymore - Faultlore)

[Joseph_Heck]

I'll double up on recommending consideration for Mozilla's UniFFI. It adds quite a lot of fidelity over straight hand-created FFI interfaces, and we've been using it as well for exposing the core Automerge library to use in Automerge-swift. There are constraints - but we've been very happy with it.

The downside of wrapping it into general Swift code as a library (for us) are mostly around some lingering quirks with binary artifacts (XCFrameworks) - assembling them, and getting symbols from them in order to provide standard Swift documentation. We've worked around all these limitations, but it's not really a "just click it and it works" kind of setup.

[vns]

I agree that Swift and Rust has a lot in common, just concepts that were made as key in each one are different. Which means that a lot of Swift code in Rust will appear as Arc<>, for example, since developers tend to use classes more then structs, just because it’s simpler (kinda similar to what I see with many Rust newcomers to just use Box when you are done "fighting" borrow checker, but again - totally different context I would say).

@sipefree

Going back to the initial point though, Swift’s use of ARC and CoW types make it very expressive when writing application level code, which tends to demand some level of flexibility and dynamism, but where the occasional copy of a list or data structure is not a comparatively large cost, and where it occasionally makes sense to use a class or protocol existential with dynamic dispatch.

Rust is not so expressive in that arena — it’s much more cumbersome to be flexible and dynamic like that. But it is far more expressive than Swift when doing low level, high performance, CPU-bound work, where the cost of using atomic locks around Arc<> types or the cost of cloning a list unnecessarily are actually significant detriments.

Yes, and that’s a part of my point of Swift and Rust being different from the conceptual perspective. While a lot of language capabilities are similar, main focus for each is different. As you stated, in Rust there are more low-level friendly paths available by default, when in Swift you have to reach for them with extra effort (you can find many of Swift developers not even acknowledged of memory management details or latest additions of borrowing, but it is a nonsense for Rust to not know about borrow checker), and vice versa. Which, I think, makes it harder to befriend this languages compared to what it might seem at first place. After all, it is much easier to just write working code in Swift, from my experience, compared to the amount of work and cognitive load required to get around Rust ways.

I would be happy to have some day such interop, don’t get me wrong (even though I would prefer to Swift to take over ). Just despite their similarities I find this languages conceptually different in a somewhat fundamental topics, so even though it is possible to express most of Rust in Swift and most of Swift in Rust, I expect it to be not much easier than expressing C++ in Swift. And given that both languages are LLVM based, interop (I suppose extremely roughly) similar to what JVM have for, say, Kotlin/Java can be more productive(?) ground.