3 ms·

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 strongl

by 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.
- pornel 6y ago
  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 https://github.com/ixy-languages/ixy-languages
  - jmull 6y ago
    I'd be careful about drawing general conclusions from https://github.com/ixy-languages/ixy-languages 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.)

by smabie 6y ago

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.

pornel 6y ago
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 https://github.com/ixy-languages/ixy-languages
- jmull 6y ago
  I'd be careful about drawing general conclusions from https://github.com/ixy-languages/ixy-languages 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.)