5 ms·

Swift is a really cool language. Quite similar to Rust, but easier to use. ( GC, no borrow checker, no multi-threading safeguards, ...) I just wish cross platf

Swift is a really cool language. Quite similar to Rust, but easier to use. ( GC, no borrow checker, no multi-threading safeguards, ...) I just wish cross platform support was a real priority. The Ubuntu packages are all there is, and much of the ecosystem is centered around (Mac/i)OS.

pjmlp 8y ago
Kotlin/Native might turn out to be that, but it depends pretty much where JetBrains is willing to take it. In any case, as rule of thumb, systems languages that come with an OS/platform usually win in the long run.
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.
mnem 8y ago
If GC means garbage collection here, Swift definitely doesn't have that.
- pjmlp 8y ago
  Sure it does, reference counting is a GC implementation algorithm from CS point of view. The Garbage Collection Handbook, chapter 5. http://gchandbook.org/ http://gchandbook.org/ Just one key CS reference for compiler writers among a few others.
  - seanmcdirmid 8y ago
    When people say GC in computer science, they don’t typically mean reference counting. Reference counting is an automatic memory management scheme along side GC, not inside it. One way to think of it is that if it lacks a separate GC phase and can’t deal with cycles, it isn’t GC.
    - pjmlp 8y ago
      Nah, that is mixing GC with tracing GC, because it is too much to type/say an additional word. Lay people also use wrong terms when talking about other scientific fields, that doesn't make them right by quantity of use.
      - seanmcdirmid 8y ago
        I don’t think McCarthy had reference counting in mind when he coined the word garbage collection. I think it’s more likely that people say garbage collection when they actually mean the more general term of automatic memory management. No one would ever mistake arena based memory management as a form of garbage collection, for example, even though it is obviously a form of automatic memory management.
  - chobytes 8y ago
    By that measure C++ and Rust are a GCd languages because they have smart pointers.
_frog 8y ago
Swift doesn't actually use garbage collection, it uses a variant of Objective-C's Automatic Reference Counting (ARC) which was introduced a few years prior to Swift.
- saagarjha 8y ago
  If we’re being pedantic, Automatic Reference Counting is a form of garbage collection.

pjmlp 8y ago

Kotlin/Native might turn out to be that, but it depends pretty much where JetBrains is willing to take it. In any case, as rule of thumb, systems languages that come with an OS/platform usually win in the long run.

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.

mnem 8y ago

If GC means garbage collection here, Swift definitely doesn't have that.

pjmlp 8y ago
Sure it does, reference counting is a GC implementation algorithm from CS point of view. The Garbage Collection Handbook, chapter 5. http://gchandbook.org/ http://gchandbook.org/ Just one key CS reference for compiler writers among a few others.
- seanmcdirmid 8y ago
  When people say GC in computer science, they don’t typically mean reference counting. Reference counting is an automatic memory management scheme along side GC, not inside it. One way to think of it is that if it lacks a separate GC phase and can’t deal with cycles, it isn’t GC.
  - pjmlp 8y ago
    Nah, that is mixing GC with tracing GC, because it is too much to type/say an additional word. Lay people also use wrong terms when talking about other scientific fields, that doesn't make them right by quantity of use.
    - seanmcdirmid 8y ago
      I don’t think McCarthy had reference counting in mind when he coined the word garbage collection. I think it’s more likely that people say garbage collection when they actually mean the more general term of automatic memory management. No one would ever mistake arena based memory management as a form of garbage collection, for example, even though it is obviously a form of automatic memory management.
- chobytes 8y ago
  By that measure C++ and Rust are a GCd languages because they have smart pointers.

_frog 8y ago

Swift doesn't actually use garbage collection, it uses a variant of Objective-C's Automatic Reference Counting (ARC) which was introduced a few years prior to Swift.

saagarjha 8y ago
If we’re being pedantic, Automatic Reference Counting is a form of garbage collection.