5 ms·

Swift will never win against Rust for a much simpler reason: performance. Invariably, rust is chosen where performance is critical, and Swift’s reference count

Swift will never win against Rust for a much simpler reason: performance. Invariably, rust is chosen where performance is critical, and Swift’s reference counting GC ensures it will never compete with Rust in those scenarios.

jurip 4y ago
Rust is pretty often chosen also in places where performance is not that critical. It has a good ecosystem, a good type system, native builds and great performace. Those factors make it a good choice in places where you'd be just fine even if it was slightly slower. If Swift loses by a small margin — and Swift is a high performance language too — it could very well edge out Rust with ergonomics.
- Zababa 4y ago
  Also great build tool and IDE support. Cargo and rust-analyzer by themselves make me not miss a GC that much.
jupp0r 4y ago
You don't need ultra performant memory management for most of your code. Swift compiles to machine code and ARC is fine for most use cases and you can use unsafe raw pointers etc for your occasional hot code path where you want to optimize memory management.
- cellularmitosis 4y ago
  I would love to see what this looks like in practice if you can point me to a link. (I’m now curious if the unowned keyword would have similar performance characteristics)
  - jupp0r 4y ago
    https://github.com/apple/swift-evolution/blob/main/proposals/0107-unsaferawpointer.md https://github.com/apple/swift-evolution/blob/main/proposals...
cellularmitosis 4y ago
Replying to both comments at once: I understood “win” to mean “be a viable replacement for C / C++”. A viable replacement has to meet _everyone’s_ needs, not just the needs of those for whom performance isn’t critical. And to be more specific about the performance, it isn’t by a small margin (unfortunately I no longer have the links handy, but the general trend was that Rust, C and C++ were in the same performance group, then Java, then Go, then Swift, then JavaScript. It was something like 3 to 5x slower). I should also perhaps mention that Swift is my favorite language to develop in. I’m not trying to be antagonistic, just realistic about its prospects against Rust.
manmal 4y ago
Slight correction: Swift‘s ARC is not a GC (the compiler just inserts retain/release calls where it’s necessary), and one can write very performant code by steering clear of reference counted types, and Objective-C types (dynamic dispatch is really slow). Value types with copy-on-write shouldn’t impose much overhead. Automatic inlining is progressing nicely AFAIK, and recently introduced concurrency can collapse callstack frames (not sure Rust does that).
- pjmlp 4y ago
  It is definitely one per CS definition of automatic memory mangement algorithms. Compiler optimizations are exactly that, optimizations that any automatic memory mangement implementation usually takes advantage of.
  - manmal 4y ago
    I stand corrected, thanks!
- lapcat 4y ago
  > dynamic dispatch is really slow This is false. People believe it on faith without measuring: https://mikeash.com/pyblog/friday-qa-2016-04-15-performance-comparisons-of-common-operations-2016-edition.html https://mikeash.com/pyblog/friday-qa-2016-04-15-performance-...
  - manmal 4y ago
    I have never used IMP caching, and don't think the average developer uses this (aside from indirect use of Apple's frameworks). Otherwise: > A normal Objective-C message send is a bit slower, as we'd expect. Still, the speed of objc_msgSend continues to astound me. Considering that it performs a full hash table lookup followed by an indirect jump to the result, the fact that it runs in 2.6 nanoseconds is amazing. That's about 9 CPU cycles. In the 10.5 days it was a dozen or more, so we've seen a nice improvement. To turn this number upside down, if you did nothing but Objective-C message sends, you could do about 400 million of them per second on this computer. So it's 9 cycles vs what, one?

jurip 4y ago

Rust is pretty often chosen also in places where performance is not that critical. It has a good ecosystem, a good type system, native builds and great performace. Those factors make it a good choice in places where you'd be just fine even if it was slightly slower. If Swift loses by a small margin — and Swift is a high performance language too — it could very well edge out Rust with ergonomics.

Zababa 4y ago
Also great build tool and IDE support. Cargo and rust-analyzer by themselves make me not miss a GC that much.

jupp0r 4y ago

You don't need ultra performant memory management for most of your code. Swift compiles to machine code and ARC is fine for most use cases and you can use unsafe raw pointers etc for your occasional hot code path where you want to optimize memory management.

cellularmitosis 4y ago
I would love to see what this looks like in practice if you can point me to a link. (I’m now curious if the unowned keyword would have similar performance characteristics)
- jupp0r 4y ago
  https://github.com/apple/swift-evolution/blob/main/proposals/0107-unsaferawpointer.md https://github.com/apple/swift-evolution/blob/main/proposals...

cellularmitosis 4y ago

Replying to both comments at once: I understood “win” to mean “be a viable replacement for C / C++”. A viable replacement has to meet _everyone’s_ needs, not just the needs of those for whom performance isn’t critical. And to be more specific about the performance, it isn’t by a small margin (unfortunately I no longer have the links handy, but the general trend was that Rust, C and C++ were in the same performance group, then Java, then Go, then Swift, then JavaScript. It was something like 3 to 5x slower). I should also perhaps mention that Swift is my favorite language to develop in. I’m not trying to be antagonistic, just realistic about its prospects against Rust.

manmal 4y ago

Slight correction: Swift‘s ARC is not a GC (the compiler just inserts retain/release calls where it’s necessary), and one can write very performant code by steering clear of reference counted types, and Objective-C types (dynamic dispatch is really slow). Value types with copy-on-write shouldn’t impose much overhead. Automatic inlining is progressing nicely AFAIK, and recently introduced concurrency can collapse callstack frames (not sure Rust does that).

pjmlp 4y ago
It is definitely one per CS definition of automatic memory mangement algorithms. Compiler optimizations are exactly that, optimizations that any automatic memory mangement implementation usually takes advantage of.
- manmal 4y ago
  I stand corrected, thanks!
lapcat 4y ago
> dynamic dispatch is really slow This is false. People believe it on faith without measuring: https://mikeash.com/pyblog/friday-qa-2016-04-15-performance-comparisons-of-common-operations-2016-edition.html https://mikeash.com/pyblog/friday-qa-2016-04-15-performance-...
- manmal 4y ago
  I have never used IMP caching, and don't think the average developer uses this (aside from indirect use of Apple's frameworks). Otherwise: > A normal Objective-C message send is a bit slower, as we'd expect. Still, the speed of objc_msgSend continues to astound me. Considering that it performs a full hash table lookup followed by an indirect jump to the result, the fact that it runs in 2.6 nanoseconds is amazing. That's about 9 CPU cycles. In the 10.5 days it was a dozen or more, so we've seen a nice improvement. To turn this number upside down, if you did nothing but Objective-C message sends, you could do about 400 million of them per second on this computer. So it's 9 cycles vs what, one?