Hacker News Reader

Comment by SneakerXZ | Hacker News Reader

It is the other way around. Using Rust on iOS is pain. Using Swift is not pain because it is supported by Apple. So it is easier to bring my Swift code and knowledge that I use on iOS to other platforms because other platforms (Linux) don't require sophisticated tooling and support. So I can create apps in Swift for iOS but also backend in Swift for Linux and it is the major benefit.

View on HN

So... what you say is practical, but it creeps me out. This is the same logic behind "just code for windows because that's what everyone runs and treat everything else as a port". We suffered through that for a decade already, let's not repeat the mistake.

Don't tie your ecosystem to a proprietary (yes, Swift is still a 100% proprietary environment!) toolchain. We've done that several times already in this industry and the results have never been good.

  > Using Rust on iOS is pain.

Is there something more specific than the general fact that cross-compilation is a bit involved at the moment? Just curious :)

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.

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.

> 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

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.

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