Swift Programming Language Evolution

Post by chillacy » Tue, May 10, 2016, 12:27 AM UTC

stevetrewick wrote: post #83

ryandev wrote: post #27

I've never understood the fascination with Swift. What's wrong with Objective C?

[nil someMessage] Though some consider this a feature, YMMV.

Post by thevibesman » Tue, May 10, 2016, 1:19 AM UTC

mpweiher wrote: post #113

kris-s wrote: post #8

Earlier quoted context omitted.

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 + $1 } closure syntax). I'm very excited for the future - between Go and Swift we now have two compiled fast languages that are almost as expressive as their slower dynamic/interpreted cousins. As an aside, I like that Apple is betting the farm on ARC. I wish I c…

>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

Post by Razengan » Tue, May 10, 2016, 2:45 AM UTC

lobster_johnson wrote: post #147

twoodfin wrote: post #79

To me, the most interesting empirical result of the Swift language evolution so far is the lack of urgency on language-level concurrency. If they think they can be competitive for years (at the very least vs. Objective-C) with only platform-level concurrency support, it makes me wonder whether concurrency is generally better provided by the platform instead of the language for most needs. Conventional wisdom would ha…

Go (which I think you're alluding to) has language-level concurrency because its syntax is extremely rigid. Swift's syntax is flexible enough that this isn't needed. Specifically: * Support for annotations; the compiler/runtime can be informed about safety and marshaling concerns. * Anonymous function bodies. You can implement Go's "go func() { ... }()" pattern yourself, and a concurrency runtime can implement it. Ru…

  Queue.UserInitiated.execute {
    let url = NSURL(string: "http://image.jpg")!
    let data = NSData(contentsOfURL: url)!
    let image = UIImage(data: data)

    Queue.Main.execute {
      imageView.image = image
    }
  }

Post by proyb2 » Tue, May 10, 2016, 3:21 AM UTC

danappelxx wrote: post #99

twoodfin wrote: post #79

To me, the most interesting empirical result of the Swift language evolution so far is the lack of urgency on language-level concurrency. If they think they can be competitive for years (at the very least vs. Objective-C) with only platform-level concurrency support, it makes me wonder whether concurrency is generally better provided by the platform instead of the language for most needs. Conventional wisdom would ha…

I'm not sure if Swift really needs language-level concurrency support. As it stands, you can wrap any C library which provides some sort of concurrency and make it feel like native functionality because of Swift's syntactic sugar such as trailing closures. For example, I'm a huge fan of the library Venice[0] which provides CSP by wrapping libmill (single-threaded like libuv, uses setjmp/longjmp instead of callbacks u…

Post by johnlinvc » Tue, May 10, 2016, 5:21 AM UTC

mikeash wrote: post #51

ryandev wrote: post #27

I've never understood the fascination with Swift. What's wrong with Objective C?

Objective-C has no safe collections for non-object values. If you want an array of ints, for example, you either get to use a C array with lots of manual management and potential for error, or you use an NSArray of NSNumbers and pay for a bunch of overhead. It has very poor support for custom value types. Objective-C structs basically can't contain object pointers, so they're limited to simple things like CGRect. The…

    let x = "\(number)"