5 ms·

I don't really see how "quite similar to Rust" and "GC, no borrow checker, no multi-threading safeguards" can both be true at the same time.

by jfk13 8y ago

omeid2 8y ago
They're both highly influenced by ML family of languages.
skohan 8y ago
They both have similar goals as far as mitigating certain classes of runtime errors through static checks. Both have nice type systems, and features like explicit mutability and nullability. Like you say the approach is pretty different: when it comes to the tradeoff between safety/performance and developer ergonomics Rust leans toward the former where Swift leans toward the latter.
0815test 8y ago
It's quite similar to Rust... if Rust literally used Arc<Mutex<T>> everywhere. And Arc<Mutex<T>> everywhere might actually have lower throughput than tracing GC! (Though it's arguably preferable for low-latency code, so it might make some sense for the typical use cases of ObjC and Swift.)
- terhechte 8y ago
  That's not entirely true, it would be similar to `Arc<T>` everywhere, because the Swift compiler and the language are by default not concurrency safe (there're runtime features to detect issues here, similar to RefCell though). This means that Rust has to use `Arc<Mutex<T>>` in order to satisfy the compiler, Swift gets away with `Arc<T>` (and I'm currently not sure, but it might even be only `Rc<T>`) because the compiler doesn't prevent it.
- dep_b 8y ago
  The advantage of ARC is that the cost of deallocating is very constant and always happens at the same moment. This helps enormously when you are doing performance sensitive stuff like scrolling over a list of complex cells. With the Java style of GC the minimum and maximum cost and timing of GC are just not so predictable so in real-world scenarios ARC based apps feel more fluent. It's like playing games. You'll notice the 10FPS dips more than the difference between 50FPS or 60FPS on average.
  - pjmlp 8y ago
    Not really. Cascading deletes of highly nested data structures are similar to pause the world in tracing GCs. If the way destruction is triggered does not take this into account, stack overflows are bound to happen. Finally it introduces slowdowns in shared data structures used across threads. Herb Sutter has a very good CppCon talk about these issues. EDIT: Forgot to mention that Swift was the loosing language at CCC talk about implementing device drivers in memory safe languages. All the ones with tracing GC had a better outcome.
    - dep_b 8y ago
      I think nothing of what you just wrote undermines what I just said. > Cascading deletes of highly nested data structures are similar to pause the world in tracing GCs. Which is simply difficult for every language. But even then still more predictable than Java "we'll do it when we feel ready for it" approach.
      - pjmlp 8y ago
        Yet all the languages with a tracing GC wipe the floor of Swift's reference counting implementation. "35C3 - Safe and Secure Drivers in High-Level Languages" https://www.youtube.com/watch?v=aSuRyLBrXgI https://www.youtube.com/watch?v=aSuRyLBrXgI https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages The subject of Herb's talk was actually going through all the reference counting problems to introduce in the end a lightweight implementation of deferred pointers, which isn't nothing more than basic tracing GC. https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE
        dep_b 8y ago
        Well if you think a driver is somewhat similar to a front-end implementation to begin with then it's OK. If "wiping the floor" means what I see on a day by day basis comparing JVM based UI's versus the same thing built in Swift you're probably talking about something different to begin with. I'm talking about predictable performance and guaranteed minimum performance. I don't think you're speaking about the same thing. The video seems to be interesting anyway, so thanks for that.

I don't really see how "quite similar to Rust" and "GC, no borrow checker, no multi-threading safeguards" can both be true at the same time.

by jfk13 8y ago

I don't really see how "quite similar to Rust" and "GC, no borrow checker, no multi-threading safeguards" can both be true at the same time.

omeid2 8y ago

They're both highly influenced by ML family of languages.

skohan 8y ago

They both have similar goals as far as mitigating certain classes of runtime errors through static checks. Both have nice type systems, and features like explicit mutability and nullability. Like you say the approach is pretty different: when it comes to the tradeoff between safety/performance and developer ergonomics Rust leans toward the former where Swift leans toward the latter.

0815test 8y ago

It's quite similar to Rust... if Rust literally used Arc<Mutex<T>> everywhere. And Arc<Mutex<T>> everywhere might actually have lower throughput than tracing GC! (Though it's arguably preferable for low-latency code, so it might make some sense for the typical use cases of ObjC and Swift.)

terhechte 8y ago
That's not entirely true, it would be similar to `Arc<T>` everywhere, because the Swift compiler and the language are by default not concurrency safe (there're runtime features to detect issues here, similar to RefCell though). This means that Rust has to use `Arc<Mutex<T>>` in order to satisfy the compiler, Swift gets away with `Arc<T>` (and I'm currently not sure, but it might even be only `Rc<T>`) because the compiler doesn't prevent it.
dep_b 8y ago
The advantage of ARC is that the cost of deallocating is very constant and always happens at the same moment. This helps enormously when you are doing performance sensitive stuff like scrolling over a list of complex cells. With the Java style of GC the minimum and maximum cost and timing of GC are just not so predictable so in real-world scenarios ARC based apps feel more fluent. It's like playing games. You'll notice the 10FPS dips more than the difference between 50FPS or 60FPS on average.
- pjmlp 8y ago
  Not really. Cascading deletes of highly nested data structures are similar to pause the world in tracing GCs. If the way destruction is triggered does not take this into account, stack overflows are bound to happen. Finally it introduces slowdowns in shared data structures used across threads. Herb Sutter has a very good CppCon talk about these issues. EDIT: Forgot to mention that Swift was the loosing language at CCC talk about implementing device drivers in memory safe languages. All the ones with tracing GC had a better outcome.
  - dep_b 8y ago
    I think nothing of what you just wrote undermines what I just said. > Cascading deletes of highly nested data structures are similar to pause the world in tracing GCs. Which is simply difficult for every language. But even then still more predictable than Java "we'll do it when we feel ready for it" approach.
    - pjmlp 8y ago
      Yet all the languages with a tracing GC wipe the floor of Swift's reference counting implementation. "35C3 - Safe and Secure Drivers in High-Level Languages" https://www.youtube.com/watch?v=aSuRyLBrXgI https://www.youtube.com/watch?v=aSuRyLBrXgI https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages The subject of Herb's talk was actually going through all the reference counting problems to introduce in the end a lightweight implementation of deferred pointers, which isn't nothing more than basic tracing GC. https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE
      - dep_b 8y ago
        Well if you think a driver is somewhat similar to a front-end implementation to begin with then it's OK. If "wiping the floor" means what I see on a day by day basis comparing JVM based UI's versus the same thing built in Swift you're probably talking about something different to begin with. I'm talking about predictable performance and guaranteed minimum performance. I don't think you're speaking about the same thing. The video seems to be interesting anyway, so thanks for that.