12 ms·

My favorite thing about Swift is that is seems to get out of the way - and when it gets in the way it's usually with a nifty language feature (like the { $0 + $

• quux 10y ago
  I think they had to go with ARC due to the requirement that swift interoperates with Objective-C. If that hadn't been a constraint, yeah it would be an interesting decision.
  • deleted 10y ago
    [deleted]
  • zepto 10y ago
    No - they already had GC working with Objective-C and could have chosen it for swift if they had thought it was the best technology. Here's a quote from Chris Lattner: "GC also has several huge disadvantages that are usually glossed over: while it is true that modern GC's can provide high performance, they can only do that when they are granted much more memory than the process is actually using. Generally, unless you give the GC 3-4x more memory than is needed, you’ll get thrashing and incredibly poor performance. Additionally, since the sweep pass touches almost all RAM in the process, they tend to be very power inefficient (leading to reduced battery life). I’m personally not interested in requiring a model that requires us to throw away a ton of perfectly good RAM to get an “simpler" programming model - particularly on that adds so many tradeoffs."
    • quux 10y ago
      Yes, they had GC working with Objective-C but there were so many problems with it that they dropped the GC in favor of ARC years ago. By the time Swift came along, GC with Objective-C was no longer an option.
      • rimantas 10y ago
        And it was only an option on OS X, never on iOS.
      • zepto 10y ago
        Chris Lattner was already working on Swift when the decision to drop GC was made. Guess who made the decision? Chris Lattner. If anything, GC was dropped because of Swift, not the other way around.
• dalbin 10y ago
  There is a pretty good comment from Chris Lattner about ARC versus GC : https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
  • shiny 10y ago
    I really like the `deinit` construct that comes with ARC, which lets you know when an object is about to be deallocated. Makes it much easier to find memory leaks, imo.
    • Razengan 10y ago
      Indeed. `deinit` has saved me from things that would have caused much greater problems later on. It's probably one of the more subtle features that one would miss the most when moving to a language that doesn't have it.
  • kris-s 10y ago
    awesome!
• api 10y ago
  I'm always a bit fascinated when what everyone knows is the next thing turns out not to be. RISC is a classic example. (ARM is light CISC compared to the sort of true minimal RISC I'm talking about.) GC is borderline but it feels like it might be one of those. In retrospect one giveaway is how easy it is to avoid almost all memory problems in C++ with RAII and STL.
  • pcwalton 10y ago
    > In retrospect one giveaway is how easy it is to avoid almost all memory problems in C++ with RAII and STL. Not at all. It's easy to think you're avoiding those memory problems, but they invariably crop up again and again.
• gnufied 10y ago
  I love go but if one thing that it is not is - expressive, especially when compared to its dynamic cousins like Ruby/Python. That is a tradeoff I am willing to live with, but there is no need to get starry eyed over it.
  • adamnemecek 10y ago
    Can you give an example? I've been writing a bunch of swift recently and I actually find it somewhat more expressive than either of those.
    • findjashua 10y ago
      GP was talking about Go. Not to beat a dead horse, but not having generics results in writing similar code over and over again, eg working with collections
      • adamnemecek 10y ago
        ah, apparently i'm blind. yeah, swift generics are nice even though they can be somewhat tricky to work with.
• RotsiserMho 10y ago
  Me too. Is something similar available in Rust? I'm familiar with smart pointers in C++ but I love that Swift manages a lot of that mess for me.
  • snuxoll 10y ago
    Generally data lifetime in rust is fully deterministic and the borrow checker can statically determine when data should be deallocated. If for whatever reason you do need reference counted semantics there are options in the stdlib (alloc::rc).
    • steveklabnik 10y ago
      And to elaborate on this, there's a namespace clash: Arc in Rust is _atomic_ reference counting, and Swift is _automatic_ reference counting, which, even more confusingly, is implemented using atomic reference counting in my understanding. Automatic reference counting inserts all of the refcount bumps. In Rust, you have to write the up count yourself, but not the downcount. But, reference counting isn't used very often, at least in my experience. It's very useful when you have non-scoped threads, though.
      • Gankro 10y ago
        As far as I can tell, the impl of Arc and ARC are actually basically identical at the high level, with the only major diff being ARC only keeps 32-bit counts on 64-bit (so they only waste one pointer of space). Everything else is just where retain/release (clone/drop) calls are made. Rust is insanely good at not frobbing counts because you can safely take internal pointers and move pointers into a function without touching the counts at all. Swift has lots of interesting optimizations to avoid touching the counts, but it's hard to compete with a system that has so much great static information related to liveness of pointers and values. As a simple example, consider this code (which is conveniently valid Swift and Rust, modulo snake_vsCamel): let x = make_refcounted_thing(); foo(x); This code in isolation will always not frob counts for Rust. This code may not frob counts in Swift, depending on what follows `foo`. In particular if foo is in tail position (or at least tail-position-for-the-life-of-x), then we can avoid frobbing, because we know foo's final operations will be to release its function args. foo may in turn punt releasing its function args to anyone it passes them to as a tail call. Note that Swift and Rust both have the usual caveats that "less is a tail call than you think" thanks to side-effecting destructors. The takeaway is that Rust's default semantics encourage releasing your memory earlier, which in turn means less traffic on the reference counts. Particularly interesting is that in Rust, you can run a function arg's destructor earlier than the end of the function by moving it in to a local variable. In Swift, I do not think this is possible (but I wouldn't be too surprised to be wrong -- Swift has tons of special attributes for these little things).
• jsingleton 10y ago
  For anyone curious as to what ARC is in this context (not the dialect of Lisp HN is written in): https://en.wikipedia.org/wiki/Automatic_Reference_Counting https://en.wikipedia.org/wiki/Automatic_Reference_Counting Last time I did any Objective-C you had to retain/release yourself so the auto stuff is interesting. As far as I can tell the benefit over Garbage Collection is that GC only works well when you have lots of excess spare memory, which is constrained on mobile devices.
  • pcwalton 10y ago
    There are hybrid systems that combine the prompt deallocation of pure reference counting with the superior throughput of tracing garbage collection. Part of the reason I really dislike the "reference counting vs. garbage collection" debate, and keep emphasizing that reference counting is garbage collection, is that it sets up this false dichotomy. In reality, there are all sorts of automatic memory management schemes that combine aspects of reference counting with tracing in different ways, most of which were created in the 80s and 90s. Sadly, almost nobody in industry is aware of this enormous body of work, and the simplistic "RC vs. GC" model has stuck in everyone's heads. :(
  • mpweiher 10y ago
    Not just is reference counting a form of garbage collection (as pcwalton pointed out), it is also not the case that you had to retain/release stuff yourself, certainly not since Objective-C 2.0's properties. Here is the code to define and use a property pre ARC with properties: @property NSString *name; ... object.name = @"Marcel"; And here is the same code with ARC: @property NSString *name; ... object.name = @"Marcel"; Spot the difference? Now it turns out that there are some differences, such as automatic generation of -dealloc methods and weak references and some cosmetic stuff. But overall, it's at best a subtle difference and for most code you won't be able to tell the difference. Pre Objective-C 2.0, there were solutions such as AccessorMacros[1], which handled the same use-cases except without the dot syntax (which is somewhat questionable) and have the advantage of being user-defined and user-extensible, so for example if you want a lazy accessor, you don't have to wait for your liege lord, er language supplier to add them, or create a whole new language to do the trick. Instead, you just write 4-5 lines of code and: done! [1] https://github.com/mpw/MPWFoundation/blob/master/Classes/AccessorMacros.h https://github.com/mpw/MPWFoundation/blob/master/Classes/Acc...
• mpweiher 10y ago
  >I wish I could have been a fly on the wall when they were discussing ARC versus GC. Apple shipped a tracing GC (RC is a form of GC) for a while, but couldn't get it to work reliably or with adequate performance. ARC was a bit of a "Hail Mary" and is problematic in its own right, but certainly better than the GC it replaced. Marcel
  • thevibesman 10y ago
    > ARC was a bit of a "Hail Mary" and is problematic in its own right I'm just curious with your experience what you are pointing to as problematic. Other than potential extra release calls in tight loops, the main downside I saw was it made the use of C structs way less appealing---at the same time, I wouldn't want to with manually memory managed C structs in GCD blocks.
    • mpweiher 10y ago
      Problems: - Lots of extra retains/releases can cause significant and unpredictable performance degradation, and even crashes: http://blog.metaobject.com/2014/06/compiler-writers-gone-wild-arc-madness.html http://blog.metaobject.com/2014/06/compiler-writers-gone-wil... - The language went from fun dynamic, optionally statically typed to strict static typing that restricts exploratory programming: http://blog.metaobject.com/2014/03/cargo-cult-typing-or-objective-c.html http://blog.metaobject.com/2014/03/cargo-cult-typing-or-obje... http://blog.metaobject.com/2014/05/the-spidy-subset-or-avoiding-copeland.html http://blog.metaobject.com/2014/05/the-spidy-subset-or-avoid... - People no longer write class-side convenience initialisers :-(( - The benefits are mostly marginal, and the non-marginal benefits are needlessly bundled with ARC - The C interaction model of the Objective-C hybrid language was made much more complex, somewhat defeating the purpose of a hybrid language That's off the top of my head.
• mahyarm 10y ago
  Go is about as fast as java is with a lower memory requirement although.