5 ms·

I actually think this could be developed into something very useful. Rust is a lot cleaner than Swift, and proper Objective-C interop could make it a viable alt

I actually think this could be developed into something very useful. Rust is a lot cleaner than Swift, and proper Objective-C interop could make it a viable alternative for app development. (I'd avoid trying to replicate ObjC's syntax, though, since it's the worst part of that language.)

saagarjha 6y ago
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.
- adamnemecek 6y ago
  Swift selectively shares the objc memory model.
- Klonoar 6y ago
  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/autolayout.rs 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.
- fiddlerwoaroof 6y ago
  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.
smabie 6y ago
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.
- zozbot234 6y ago
  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.
  - smabie 6y ago
    ARC is GC, and anyone who says otherwise is crazy.
    - saagarjha 6y ago
      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.
  - jmull 6y ago
    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.
- drran 6y ago
  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.

saagarjha 6y ago

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.

adamnemecek 6y ago
Swift selectively shares the objc memory model.
Klonoar 6y ago
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/autolayout.rs 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.
fiddlerwoaroof 6y ago
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.

smabie 6y ago

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.

zozbot234 6y ago
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.
- smabie 6y ago
  ARC is GC, and anyone who says otherwise is crazy.
  - saagarjha 6y ago
    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.
- jmull 6y ago
  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.
drran 6y ago
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.