Swift and Objective-C share a memory model, though, which Rust does not. I suspect that any Rust code that interoperates with Objective-C will never be "cleaner" than the corresponding Swift code.

I mean, it depends on the Swift code you write - basic example which could be done fairly closely: https://github.com/ryanmcgrath/cacao/blob/trunk/examples/aut...

Having written my fair share of both languages, I don't think they're as far apart as people think... yet, anyway.

I doubt my response will age well.

I’ve had some pretty good luck integrating Common Lisp and the Objective-C runtime: the difference of memory models isn’t a huge problem, as long as there’s a nice way to map between them.

Swift selectively shares the objc memory model.

Apps don't need to be in Rust. And maybe they even shouldn't be programmed in Rust.

If your application or backend or whatever can tolerate GC, I would strongly recommend that you use it. While Rust has made manual memory management easier than either C++ or C, it still requires more work than a GC'd language.

Rust has a lot of things going for it, but this obsession with writing everything in Rust that has taken HN by storm is a little confusing.

Swift is unequivocally a higher-level language than Rust and definitely should be used for iOS development unless you have a very good reason to use Rust.

Swift does not do cycle-collecting GC, either. Not really any "higher-level" than Rust, when you look at a comprehensive view of the problem space. And obligate ARC ala Swift has all kinds of performance pitfalls, to the point where it can be even worse than obligate tracing GC.

Yes. It might help to can think of it this way:

Rust, with the borrow-checker, strong-arms the developer into using memory patterns that the compiler manage handle without the overhead of reference counting or other runtime mechanism.

Those same memory patterns are available in Swift as well, which the compiler can then optimize as well (in theory -- as far as I'm aware there are various unimplemented optimization opportunities in Swift).

So in a sense, in Swift you can opt-in or out of rust-level memory management.

Of course, a big difference is that Rust tells you up-front when you've got it right, but in Swift it's not at all clear. You need to profile. Swift does have a clear delineation between reference types (which use ARC) and values types, so you can get on the right path by choosing value types. Value types in Swift are very rich and powerful so it's not a hard path to follow.

ARC is GC, and anyone who says otherwise is crazy.

Usually on Apple’s platforms ARC and GC are treated separately because Objective-C has shipped with a conventional garbage collector as well as reference counting and it’s difficult to tell them apart otherwise.

Swift language by definition is at the same level as Rust. "Higher Level" means that developer is order of magnitude more productive in language X than in language Y. This is not a case for Swift vs Rust.

Swift does implicit allocations, doesn't have explicit monomorphisation, requires a non-trivial runtime. Language functionality like ARC and ivars compiles to a lot of "magic" (compared to Rust's focus on zero-cost abstractions). Swift's standard library is full of dynamic dispatch (e.g. Swift strings are a collection of classes with abstracted-away and variable in-memory representation. Rust's strings are dumb pointer+length).

Swift is much higher-level than Rust. It's at best at Go's level. You'd expect Swift's performance to be good, but in low-level tasks Swift is actually closer to JS/TypeScript than anything else: https://github.com/ixy-languages/ixy-languages

I'd be careful about drawing general conclusions from https://github.com/ixy-languages/ixy-languages

It's using some non-optimal patterns that you would not normally use in Swift for code if you wanted it to perform well. (There's a nice performance analysis if you click in, showing that it's using ARC in an inner loop, which is taking 3/4th of the time. That's not something you need to do.)