4 ms·

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 know

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.

steveklabnik 11y ago
> 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 :)
- SneakerXZ 11y ago
  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.
  - steveklabnik 11y ago
    Thanks :)
  - anonova 11y ago
    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.
    - SneakerXZ 11y ago
      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.
      - autoreleasepool 11y ago
        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.
        SneakerXZ 11y ago
        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.
        kibwen 11y ago
        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.
        autoreleasepool 11y ago
        > 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 vs Rust -> C -> Objective-C -> Swift
      - kibwen 11y ago
        There exist Rust crates that make it easy to call Objective-C APIs. See https://github.com/SSheldon/rust-objc/ https://github.com/SSheldon/rust-objc/ .
ajross 11y ago
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.

steveklabnik 11y ago

> 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 :)

SneakerXZ 11y ago
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.
- steveklabnik 11y ago
  Thanks :)
- anonova 11y ago
  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.
  - SneakerXZ 11y ago
    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.
    - autoreleasepool 11y ago
      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.
      - SneakerXZ 11y ago
        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.
        kibwen 11y ago
        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.
        autoreleasepool 11y ago
        > 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 vs Rust -> C -> Objective-C -> Swift
    - kibwen 11y ago
      There exist Rust crates that make it easy to call Objective-C APIs. See https://github.com/SSheldon/rust-objc/ https://github.com/SSheldon/rust-objc/ .

ajross 11y ago

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.