The Swift platform and what it will offer developers is one of the most important announcements last week at the Apple Worldwide Developers Conference (WWDC). Many programmers found the syntax of Objective-C hard to get used to, so Swift may provide a productivity boost to some.
While most developers will look to future projects for implementing Swift (meaning at least a year off), some said they are moving ahead more quickly. For example, developer and writer Marco Arment said in a blog post that he would take a while to grok the new behaviors as well as its standards and expectations.
In an interesting and uncharacteristic move, Apple is opening all its WWDC 2014 video presentations to the public; last year only registered developers had access to them. Check out the Introduction to Swift by developer publications engineers Tim Isted and Dave Addey.
On his blog, Michel Fortin talked about Swift's safety features.
Apple says it’s designed for safety. It’s important to note that the design of Swift doesn’t prevent memory corruption that could happen due to multithreaded code at all, however. I find it striking that there’s no mention of threads or concurrency at all in the language documentation. Maybe they’ll just outlaw threads, but that’d be surprising.
Besides this multithreaded hole, the rest of the language seems to be safe from memory corruption bugs. There’s no way to temporarily escape the safeties (like Rust’s unsafe block), so any unsafe thing you may want to do will have to be in C or Objective-C.
There were some posts with interesting discussion about Swift and scripting. Clark Goble at Clark's Tech Blog had several long posts about the introduction of Swift and a first look at its performance. He suggested heading over to GitHub and checking out the surprisingly large amount of Swift code there.
To my eyes, it is much easier to read. I know some ObjC diehards are saying the lack of verbosity makes it harder to read. I don’t see that. In fact, one criticism I have is that so much still uses Cocoa naming conventions that too much remains verbose. I think the rule that the most used methods/classes should be terse has not been a rule Cocoa has followed well. (Especially in terms of string handling)