The center of my article is that, with Apple's current data, the language will not replace OBJC, which is not the OBJC of the next generation. It has many drawbacks that make it not enough to do large projects. These drawbacks make Apple itself not using it as a Mac/ios app. I don't rule out a lot of improvement next year, but at least it's not there yet.
So if you're going to OBJC, you don't have to look at it.
But if you ask me how important this language is to the average developer, I say it's important to tell you that-it's the blockbuster Apple's WWDC to the world. How can I say it's not important? It lowers the threshold for getting started. So that a lot of JS, Python, Ruby users will use Apple's technology for its development program. Its role, like Core Data, Interface Builder, allows you to quickly write a program that can be used. But if you want to do something serious, you're not in the right mind. So and Apple's own Mail is not going to use Core Data, their own iPhoto not to use Uicollectionview, a little bit of the App will not use Interface Builder, Apple itself will not use Swift. It just gives a small team of 35 of people the ability to quickly make available programs that allow large companies to quickly make Prototype.
====
Some say it's equivalent to C #, or the equivalent of Scala's improvements to Java, and I can tell you that Swift is not the language. It's more like a toy language that lets people make prototypes quickly.
The call for Apple to send out the next-generation Objective-c language is long overdue, and Ars Technica, which writes tens of thousands of words of OS X reviews, wrote two years ago that Apple should do a language, objective-c without C and use more modern features and more Short API and support for automatic type inference, the article sees OS X 10.8 Mountain lion:the Ars Technica review.
But Apple apparently did not take the language seriously. It is obvious that they do not want to replace the OBJC. And in Apple's style, if they treat Swift as OBJC's future, there will surely be one or two Ios/mac apps using Swift to rewrite. (for example, when Apple cut Carbon, the first thing to do was rewrite the Finder).
From a linguistic standpoint, Swift has too many drawbacks:
Its standard library is too bad, only dictionary, Array and string and several of these data structures, not even a Set. Want to use something else? You still have to use the OBJC. Yes, when you use the native data structure, the speed is faster than OBJC. But that's only a few. It does not have any support for asynchronous/synchronous programming. It cannot bind to the use of the grand-Dispatch, so any serious Web application cannot be written at all.
It does not have any protection mechanisms (private, protected), all method and variable are globally visible, which obviously does not meet the needs of serious projects.
can only interact with OBJC. If you want to use C or C + + seriously, you have to write OBJC wrapper. This basically limits your use of a large number of C + + library functions.
There is no way to catch Objective-c's exception, if once out of exception, your App immediately collapses. This also basically limits your use of many OBJC old code libraries.
When Chris was designing the language, he could clearly see his myopia. This is also normal, he is a compiler, not doing language research. So the language that claims to support functional programming does not have the universal function of most functional languages:
The only support is in lazy, closures, and simple function language functions (such as map, filter). It can be done in OBJC.
No pattern matching.
Type deduction is almost the same as c++11, not using Hindley Milner
From these features, Apple's positioning is simply to reduce the toy language that the learning curve offers to developers of OBJC headaches. Each of the previous five articles is basically fatal, so Apple's own projects are not used. It is possible to make an early proof of the prototype of concept.
I can imagine that it's easy to achieve Swift (LLVM is very mature, and it's getting easier to write a new language, such as a small language in just a few steps: 1.) Kaleidoscope:tutorial Introduction and the Lexer), of course, it is possible that Apple will solve these problems in the future to make them truly practical. But for now, Apple doesn't want Swift to replace objective C.