5 ms·

Spending the last month swapping between Swift and Clojure, there's still a very large safety difference between ARC & a memory-safe VM. The problem is, compil

by arohner 12y ago

Spending the last month swapping between Swift and Clojure, there's still a very large safety difference between ARC & a memory-safe VM. The problem is, compiler magic gives the illusion of safety, and then you segfault and remember that you're in a non-memory safe language. Swift is a big improvement, but it's still basically a DSL on top of objC, with all of the downsides that implies.

dilap 12y ago
Question: If you use only strong and weak ptrs (no unsafe_unretained), avoid doing pointer arith, unchecked array accesss, or blowing the stack, can you still get segfaults? No, right?
- arohner 12y ago
  If you stay in pure swift, it's much harder to segfault, but it's still possible, mainly due to the amount of objC code you interact with. Today, it's not reasonable to expect a swift programmer to be proficient without knowing objC, the way it's reasonable for a Java programmer to not know C. The segfault I hit yesterday had to do with a CoreData API that didn't retained its argument, when I assumed it did. The bug doesn't appear when compiling with -Onone, but does appear in -O. Compiler flags are another place where Swift is still very much in C-land, rather than Java/Python/Ruby land. You still need to understand the C compilation model, and e.g. getting your ARC flags wrong in a cocoapod will still cause crashes. To be clear, swift is a big improvement over objC, but you can't pretend it's a VM managed language.
  - masklinn 12y ago
    > To be clear, swift is a big improvement over objC, but you can't pretend it's a VM managed language. Memory safety does not require VM management (or so Rust is trying to prove).
    - arohner 12y ago
      >Memory safety does not require VM management (or so Rust is trying to prove). I agree, with a few qualifications. I think Haskell has already proved it's possible. I think Swift + ARC isn't a strong enough guarantee of memory safety for two reasons: 1) Swift has to interact with a huge amount of objC code, of varying degrees of quality (some Apple code, some OSS code via cocoapods). Swift itself would be much safer if all objC was rewritten in Swift. 2) ARC isn't as strong a guarantee as either GC or Rust's pointer semantics. For example, it's easy to hold weak references to something you thought was retained, and then dereference an invalid pointer. So yes, you can have a memory safe language without a VM, but I think you need GC and/or much stronger pointer semantics, ala rust.
      - steveklabnik 12y ago
        > I think Haskell has already proved it's possible. Haskell has a GC, no?
        masklinn 12y ago
        Yes. GHC bundles a fairly heavy runtime with programs, including (but not limited to, not by a long shot) a garbage collector: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts
  - deleted 12y ago
    [deleted]
- constexpr 12y ago
  Yes. According to http://clang.llvm.org/docs/AutomaticReferenceCounting.html#self http://clang.llvm.org/docs/AutomaticReferenceCounting.html#s..., ARC assumes that self is valid for the lifetime of the call. This will not be the case if the last reference to the object is changed or cleared during the call, which may result a segfault. The performance loss of retaining and releasing self across all methods was deemed too much compared with the safety gains.

by arohner 12y ago

dilap 12y ago

Question: If you use only strong and weak ptrs (no unsafe_unretained), avoid doing pointer arith, unchecked array accesss, or blowing the stack, can you still get segfaults? No, right?

arohner 12y ago
If you stay in pure swift, it's much harder to segfault, but it's still possible, mainly due to the amount of objC code you interact with. Today, it's not reasonable to expect a swift programmer to be proficient without knowing objC, the way it's reasonable for a Java programmer to not know C. The segfault I hit yesterday had to do with a CoreData API that didn't retained its argument, when I assumed it did. The bug doesn't appear when compiling with -Onone, but does appear in -O. Compiler flags are another place where Swift is still very much in C-land, rather than Java/Python/Ruby land. You still need to understand the C compilation model, and e.g. getting your ARC flags wrong in a cocoapod will still cause crashes. To be clear, swift is a big improvement over objC, but you can't pretend it's a VM managed language.
- masklinn 12y ago
  > To be clear, swift is a big improvement over objC, but you can't pretend it's a VM managed language. Memory safety does not require VM management (or so Rust is trying to prove).
  - arohner 12y ago
    >Memory safety does not require VM management (or so Rust is trying to prove). I agree, with a few qualifications. I think Haskell has already proved it's possible. I think Swift + ARC isn't a strong enough guarantee of memory safety for two reasons: 1) Swift has to interact with a huge amount of objC code, of varying degrees of quality (some Apple code, some OSS code via cocoapods). Swift itself would be much safer if all objC was rewritten in Swift. 2) ARC isn't as strong a guarantee as either GC or Rust's pointer semantics. For example, it's easy to hold weak references to something you thought was retained, and then dereference an invalid pointer. So yes, you can have a memory safe language without a VM, but I think you need GC and/or much stronger pointer semantics, ala rust.
    - steveklabnik 12y ago
      > I think Haskell has already proved it's possible. Haskell has a GC, no?
      - masklinn 12y ago
        Yes. GHC bundles a fairly heavy runtime with programs, including (but not limited to, not by a long shot) a garbage collector: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts
- deleted 12y ago
  [deleted]
constexpr 12y ago
Yes. According to http://clang.llvm.org/docs/AutomaticReferenceCounting.html#self http://clang.llvm.org/docs/AutomaticReferenceCounting.html#s..., ARC assumes that self is valid for the lifetime of the call. This will not be the case if the last reference to the object is changed or cleared during the call, which may result a segfault. The performance loss of retaining and releasing self across all methods was deemed too much compared with the safety gains.