Hacker News Reader

Comment by SneakerXZ | Hacker News Reader

You need to write your bridging yourself and it might not always be possible because you need to bridge Rust <-> Objective-C.

Swift with Objective-C is bridged automatically.

View on HN

I use rust with ios, and my bridging header just includes a single C header file. I don't see how it's any more complicated than using a C library.

Yeah, it bridges to C so you need to build another bridge to have nice Objective-C API. Not mentioning, you will have hard times calling Objective-C API from Rust.

You don't have this problem with Swift.

You don't need to involve Objective-C to use a C API in Swift. You can call C functions directly in Swift and wrap them in a nice Swift API.

I know that but if I decide to use Rust instead of Swift, why would I be wrapping Rust in Swift through C? And still it doesn't solve a problem how Rust can call anything from Cocoa or my existing code.

Rust can call anything that exposes a C-compatible ABI, and Rust code can expose a C-compatible ABI so any language that can call into C (i.e. all languages) can call into Rust.

> if I decide to use Rust instead of Swift, why would I be wrapping Rust in Swift through C?

To avoid the unnecessary overhead of dynamically dispatched Objective-C method calls.

To me, it seems more sensible to go

  Rust -> C -> Swift

  Rust -> C -> Objective-C -> Swift

There exist Rust crates that make it easy to call Objective-C APIs. See https://github.com/SSheldon/rust-objc/ .

Thanks :)

Reply on news.ycombinator.com