如何評價 Swift 語言？

11-16

今天蘋果推出了全新的基於腳本的編程語言 Swift。Swift 有類似 Python 的易用性，又有較強的運行效率。它彌補了 Objective-C 的哪些不足？融合了哪些其他語言的優秀特性？將它和 C# 相比，各有什麼優劣？它會對未來的軟體開發產生什麼影響？作為一個程序員，此刻，一個對世界消費者和消費平台都有著廣泛影響力的公司，推出了一個全新的語言，所有人都是0基礎，你有什麼想法？

2016.07.10 更新

-------------------

現在還處於過渡時期，但趨勢很明朗了，Swift 必然會替代 Objective-C，並且比想像中來得快。現在就應該做好準備了。假如之前已經掌握了 Objective-C，切換到 Swift 也不難。Swift 中很多概念在 Objective-C 中已經存在。推薦網站 Swiftify | Objective-C to Swift Converter ，輔助將舊的 Objective-C 代碼轉成 Swift。

那是不是 Objective-C 就不需要學習呢？並非如此。Swift 還沒有很好地解決好跟 C 和 C++ 混編的問題。很多項目底層核心庫會採用 C/C++，界面和大部分邏輯採用 Swift 編寫，需要 Objective-C 作為粘合層。另外還存留很多庫是用 Objective-C 編寫的，使用這些庫需要一定 Objective-C 知識。

隨著時間推移，Swift 在整個 iOS/Mac 工程中占的代碼比例會越來越多，而 Objective-C 作為粘合層還是會存在。Objective-C 的語法很獨特，就算跟 C++ 寫在同一文件，也不會搞混，Objective-C 跟 C++ 混編是很容易的。Swift 調用 C 代碼還勉強可以（還不夠方便），但直接調用 C++ 沒有什麼可能。

或者有些人會覺得小小的一個 App，還需要跟 C/C++ 混編？你是小看了 App 了，App 會越做越複雜的。應該當成跟 PC 平台相同的地位看待，PC 平台的軟體可以達到什麼規模，App 就會達到什麼規模。在需要高性能，跨平台的場合，C/C++ 還是繞不開的。

很多人現在還沒有學習 Swift, 覺得它沒有什麼優點，只是一個語言大雜燴。只是等你真正使用 Swift 編寫一兩個項目，就回不了頭。Swift 有些簡便快速的寫法，在 Objective-C 中是沒有辦法做到的。並且 Swift 的一些語言特性避免了很多 Objective-C 的坑。使用 Swift 編寫的任何功能，使用 Objective-C 也可以做到，但是會麻煩得多。而假如太麻煩的話，明知道是好的，也不會去做。

很多事情，你還沒有見識過的時候，會覺得不需要。但等你真正接觸過了，就難以忍受再次失去了。我翻看整理 3、4 年前的項目，那時項目還沒有採用 ARC。現在看來假如沒有 ARC，代碼寫起來太麻煩了，那時還沒有更先進的寫法，根本不會有這樣的感覺。Swift 比 Objective-C 先進。

現在 Swift 還不穩定，語言、庫、相關工具將會快速變動，而這恰好說明它在發展。

很多大公司為求穩，會仍然採用 Objective-C。而個人開發者和小團隊，新項目應該直接採用 Swift 編寫，舊項目的新模塊也應該使用 Swift 編寫。這樣慢慢將整個語言重心從 Objective-C 切換到 Swift。Swift 的代碼更簡潔，開發效率更高。原有 Objective-C 項目，已經使用 Objective-C 編寫的比較穩定的庫，不需要也不建議要用 Swift 重新編寫，直接混編，讓它慢慢過渡就行了。

大公司傾向於不犯錯，求穩。個人開發者和小團隊，求穩一定不能跟大公司競爭的，更應該求好求變。

另外還是會有人說，現在很多公司的項目是規定一定需要使用 Objective-C，那怎麼辦，我不能選擇啊。假如只滿足於當前工作，那公司需要什麼就去學什麼，但從個人發展的角度來說，iOS 開發中，兩種語言都需要學習的。其實 iOS 開發中，語言的學習從來就不是難點。

2014.06.06 原回答

----------------

更詳細的評論可以再看看這篇文章。從 Objective-C 到 Swift

主要從技術的角度評價 Swift 語言。商業的角度，吸引開發者，共同維護蘋果生態圈的繁榮等之類就不說了。

Swift 這門語言還是比較有意思的，很多概念在 Objective-C 中已存在，但打扮過，比原來的模樣漂亮。個人感覺，蘋果還真的想用它取代 Objective-C 呢。

------------------

Swift 跟 Objective-C 共用同一套的運行時環境

Swift 的類型，可以橋接到 Objective-C 的類型，反之亦然。如 string 對應原來 Objective-C 的NSString, closures 對應 Objective-C 的 block，等等。 Objective-C 積累下來的大量庫，代碼不用改寫，Swift 就直接可以使用。看兩個 API 的聲明，對比一下

Objective-C

void dispatch_apply(size_t iterations, dispatch_queue_t queue, void (^block)(size_t));

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event;

Swift

func dispatch_apply(iterations: UInt, queue: dispatch_queue_t!, block: ((UInt) -&> Void)!)

func touchesBegan(touches: NSSet!, withEvent event: UIEvent!)

我懷疑，Swift 中的介面文件，是利用原來 Objective-C，C 中的介面文件自動程序生成的。

同一個工程，可以同時使用 Swift, Objective-C, C, C++ 四種編譯語言（額外嵌入的腳本語言另算）

原來的 iOS/Mac 工程，已經可以同時使用 Objective-C, c, C++三種語言。現在支持第四種。Objective-C, C, C++ 三種語言的結合很容易，Objective-C 跟 C 原本就兼容，Objective-C 跟 C++ 混編只要將文件名改成.mm。而 Swift 跟其它語言的結合，需要另外的文件進行橋接，其實也挺方便的。

這裡的橋接很容易，Apple自家的各種 C 庫移植過來了。比如Core Image/Audio，直接包含

import CoreAudio import CoreImage

就可以使用了。

現在 Swift 完全可以跟 Objective-C 並存，原來的工程不建議重寫，也不用重寫。順其自然，慢慢讓它進化就是了。

Swift 寫法看起來像腳本語言，但它是真正的編譯語言

初學者，看它使用了

let a = 4 var b = "hello"

沒有類型定義，就想當然的覺得它是腳本語言，解釋執行，這是不對的。上面兩行語句是用了類型推導，類似 C++ 裡面的 auto。Swift 跟 Objective-C 的運行時環境一樣，寫的程序跑起來不會比Objective-C 慢。Swift 區分了struct 和 class, 分別使用傳值跟傳引用。另外類中的函數可以直接調用，而不像 Objective-C 那樣需要發送消息，運行速度要比 Objective-C 快一些。

Swift 吸收了很多其它語言的語法，寫起來比 Objective-C 簡潔得多，不過它的很多概念，跟原來 Objective-C 差不多

編程語言的語法重要，但是語法背後的概念更重要。比如面向對象，常用概念無非是，繼承，多態，封裝，信息隱藏等。繼承又可能分成多重繼承，介面繼承，實現繼承。或者還會有些嵌套類，嵌套函數等等。

當明白語法背後的概念，知道為什麼需要有這些東西。之後從一門語言切換到另一門有著相同概念的語言，其實很容易。

而語法會影響表達，理論上每門語言都可以表達任何概念。不過當某種概念在某門語言中，很難表達出來，就會傾向於不這樣使用它，這種概念在那門語言的社區就難以被人熟知。

感覺上，Swift 有著 Objective-C, C++, Ruby 的影子。

暫時，我自己最喜歡的3個特性有

tuple，終於可以返回多個數值了。一行交換兩個值。C++ 裡面的 tie+tuple 也可以實現類似功能，不過使用庫，顯得噪音太多。
closure，喜歡它的簡寫，還有在函數最後一參數，可以寫在()外面。這些特性，用來寫函數式風格的程序，會很好看。而原來 Objective-C 的block, 還有 C++ 的function, 就太啰嗦了。
switch，case 裡面的條件匹配。

這些語法，編譯最後還是會映射成原來 Objective-C 的運行模型。原來 Objective-C 的概念，引用記數，ARC, 屬性，協議，介面，初始化，擴展類，匿名函數等等，繼續有效。

有個大塊頭的東西，是原來 Objective-C 沒有的，就是泛型。Swift中將那種操作寫一次，就可以作用多個類型的語法叫做generics（泛型）。

總的說來，Swift 涵蓋了現在流行的編程方式，結構化，面向對象，泛型，函數式。

Swift 的新語法，可以很好地支持內部 DSL

有一種編程風格，不太好歸類。就是將程序拆分成，描述+解釋。解釋部分寫一次，其它地方使用描述式的語句，而不是命令式的語句。

內部DSL，通常利用主語言的語法特性，創出一套寫法，來寫一些描述性的語句。這些語句組合起來，就像一門新語言似得。這個比較難理解。舉個例子（從ruby那裡借過來的），假如計算，幾小時之後的秒數。C 語言中，大概會寫成

getHourSeconds(3)

而現在 Swift中，只要定義了擴展

extension Int { var hours:Int { return self * 3600 }

var ago:Int { return -self } }

就可以寫成

3.hours 3.hours.ago

分別是 3 小時後的秒數，3 小時前的秒數。

同理，也可以寫成

10.days 10.days.ago

這種寫法，看起來跟原來的命令式寫法完全不同。這些程序是描述性的。原來的 Objective-C, 從語法上做不到這樣自然。我估計 Swift 以後會冒出大量這樣風格的庫。

這種風格，到底好不好，要看情況。比較方便定義內部 DSL 的語言, 我自己知道的有 C++, Ruby, Lisp。現在多了 Swift。

認為所有人都是0基礎的，是錯誤的

有些人學得特別快，因為之前的基礎好。語言的語法只是表面，表面的東西總是變動得比較快的。底下的東西重要得多，而看不見。水面一塊冰，有些人是冰山露出一角，有些人是無根的浮冰。看起來差不多，其實差別十分之大。

我相信有些人，在兩個小時之內就可以使用這門新語言。之前已經掌握 Objective-C 了，切換到 Swift 中其實也容易。

提提那個Playground

蘋果前員工 Bret Victor 有個視頻 Bret Victor - Inventing on Principle，提到這種可視化編程。當我們每一步操作，都得到實時地反饋，我們的做法會有很多不同，做出的東西也會不同。這個Playground 用來學習Swift 的特性很好用，但還不能跟實際工程結合起來使用。

先說結論（針對Swift 2.2）：Swift把幾種主流語言的優勢糅合得非常好，是我見過的最漂亮最現代化的語言。

「幾種語言的優勢」指的是：

Objective C的運行時動態支持，和基於編譯期引用計數的內存管理模型，
Ruby靈活優雅的語法，
C++的嚴格編譯期檢查，C++11編譯期類型推導，模版（之所以說模版template，而不是范型generic，是因為Swift的范型實現依靠編譯器更多些，而不像Java/C#依賴於運行時支持），
Javascript和Ruby的closure。

糅合的結果就是，寫Swift帶給你的極致體驗是無與倫比的。

你可以輕鬆地像Javascript一樣用closure寫函數式編程，實現callback, aync, 以及類似Promise的代碼風格；而同時，你又無需忍受Javascript那樣稀爛的類型系統（JS連函數參數的個數都不檢查）。語法上，Swift closure幾乎和Ruby一樣漂亮；Javascript寫closure很啰嗦，Objective C寫block更難看（那個C函數指針風格的block聲明我就沒搞清楚過，有碼農為此專門寫了個blog: Fucking Blocks Syntax），C++寫closure？... 眼花。

更舒服的是，Swift通過引入nullable的概念，支持在編譯期對nil值進行檢查。這一舉解決了Objective C因為對nil值過於靈活和寬容導致的問題。而通過optional chaining, 原來的靈活性依然保留。

除此之外，Swift還支持與Objective C混編，完美支持iOS/Mac的SDK。所以在老項目中，過渡到Swift的成本是比較低的。個人推薦老項目轉向Swift可以從testcase開始寫。

題主說Swift是「基於腳本的編程語言」，這個說法不太妥當。Swift是一門非常嚴格的編譯語言，它的編譯期類型檢查要比Objective C和Java都要嚴格，更別提那些真正的腳本語言了。當然，Swift可以在Xcode Playground里即時編輯即時顯示結果——那是蘋果的黑科技，並不意味著Swift是腳本語言。性能上，Swift不輸Objective C。

初學者關心好不好學這個問題。在此也給出明確答案：不好學。Swift不是一門初學者入門語言。不要抱著寫Swift可以快速上手的浮躁心態入門iOS開發。

註：本答案寫於 2014-06-03，評價的是 Swift 很早期的版本，現已不完全適用。

本想看完文檔再寫的，不過看到排名靠前的答案有些偏激（你們不就是想找個理由不學嘛），還是先寫些看法吧。

首先，它不是一門玩具語言。
去看看它的文檔就明白了，feature 非常豐富（我敢保證你們在半天內是看不完的）。
再看它的庫，Apple 把 Cocoa 的 API 都用 Swift 寫了個封裝，而不是完全一致的。
下面是文檔里的例子：
Objective-C：

UITableView *myTableView = [[UITableView alloc] initWithFrame:CGRectZero style:UITableViewStyleGrouped];

Swift：

let myTableView: UITableView = UITableView(frame: CGRectZero, style: .Grouped)

所有參數都重寫了有沒有？如果不是想取代 Objective-C，幹嘛還去重寫，你直接用那冗長的參數不就完了？
不過現階段底層仍然調用的是 Objective-C 的 API，而不是直接用 Swift。

其次，一些被指出的缺點其實並不存在，或者並不嚴重：

數據結構少？還有原生的 tuple 和 enumeration 沒提到，此外還能用 Objective-C 的 NSSet，至少總量上比 Objective-C 多了幾種。
沒有多線程？可以用 GCD 的 API，也被移植到 Swift 了。
沒有私有屬性？很多語言都沒有，都靠使用者自覺。
只能與 Objective-C 互動？C 也是可以的。
沒有異常處理？Objective-C 里基本也不用。

補充一個缺點：不支持複雜的宏，只支持 #define。
很顯然，這些缺點對很多開發者 / 團隊來說不算大問題。

此外，對於想轉行做 iOS 或 OS X 的開發者來說，Swift 是個很好的 Objective-C 替代者。
這裡沒空一一列舉 Swift 的優點了，文檔里可以找出很多。簡單來說，Objective-C 只會更坑。
蘋果也說 Swift 是「A complete replacement for both the C and Objective-C languages.」
甚至你用 XCode 6 新建一個項目，在選擇語言時，Swift 也排在 Objective-C 上面。

最後，如果不是做 iOS 或 OS X 開發，Swift 算不上一門很好的語言。

簡單的評論一下 @星晚的答案。

var array1 = Array&()
var array2 : Array& = Array&()
var array3 : Array& = Array()
var array4 : Array = Array&()
var array5 : Array = [Int]()
var array6 : [Int] = Array()
var array7 : [Int] = [Int]()
var array8 = [1, 2, 3, 4]

這其中有哪一種是可讀性差，或者不好維護的嗎？ = =
寫法多，但是強類型，有什麼缺點？

而且這種多，也只是語法糖的效果，和C++那種寫法多有天壤之別。stl一種寫法，boost一種寫法，C-style一種，這樣才會導致因為團隊成員的水平問題而出現的工程的維護性問題。

另外閉包簡直不能再清晰，只要你明白一句話，看見{} 就是閉包。閉包只有一種寫法，就是{}.

不管參數省略與否，同樣也是強類型，也就是說只有編譯器能infer出參數的類型的情況下，才能寫$0, 也就是說，一般只有特別簡短的閉包才會出現這種寫法。根本就不會帶來什麼可讀性問題。

至於paopaoSort(data, function: &> ) ？

&>是operator， operator就是function，排序一般都需要傳入一個比較元素的function。這很難理解？我相信任何一個完整的學習了Swift的人，對於上述代碼的閱讀都不會有任何問題，不管隔多少年來看。甚至沒學過Swift，只是知道自定義運算符的意思的編程初學者，也不會有問題。

雖然展現你陰暗的一面挺酷酷的感覺，但感覺沒暗到點子上？

為了消滅邀請，評價一下，其實我覺得，關於它，該說的大家都已經說了。看別的答案就行。

唯一剩下可以說的，就是這個名字。這個名字是一款車大家都知道，也許很多人不知道它是一個已經存在的語言：

http://swift-lang.org/

這個語言跟蘋果的 swift 完全不是一回事。蘋果沒把這個域名搶下來（至少我發布這篇回答的時候，現在是沒有搶下來），不知道之後會發生什麼樣的結局。

最近幾天，應該已經有了無數人訪問這個網站，然後應該已經有無數人把這個語言誤解為蘋果剛剛發布的語言了。

如果 swift 真的如大家所說的那樣流傳開來，那麼這個網站的這個 swift 語言又何去何從？

Swift比OC看起來和用起來都清爽多了，OC被吐槽的兩個地方都完美解決了：一個是訪問一個對象上的東西，竟然用三種不同的符號來表示：「.」、「-&>」、「[obj mathod]」；另一個是內存管理，什麼assign, strong, retain, copy, atomic, nonatomic媽蛋，Chris Lattner用他發明的Swift好好修理了一下蘋果，這回老實多了！

現代語言的幾個特徵，閉包（Closure），運算符重載，自動內存管理這回Swift解決的比Java還完美，閉包自動捕獲（Capture）上下文變數，是可以修改變數值的哦（Java印象中是只讀捕獲）！

閉包對非同步編程模型是非常重要的，簡單說就是「回調」，你說C的函數指針也是回調的方式，沒錯，但是參數傳遞會要了你的命！閉包能夠自動「捕獲」上下文變數是非常方便的。

運算符重載本來是C++的一大牛逼之處，現在Swift也有了，這個有什麼用，解析JSON的時候重載個「[]」之後就完全就跟人類可讀的方式一模一樣了：json["data"]["tiem"]["title"].stringValue就拿到值了，以前OC用SBJson庫（別笑，還真TM叫這個名字）怎麼寫？得寫出10行代碼。運算符重載這一點，目前主流的就C++和Swift支持了吧。咦？Java在那裡跪了多久了？C#則在旁邊哭暈了，難道我不算主流嗎？！

Swift的幾個最最常用的內置數據結構：String, Array和Dictionary比OC的方便，不用再寫神馬Mutable了。而初始化的風格，怎麼看都像JS，比OC友好多了。

析構函數也是C++一個有用的功能，Swift支持，Java怎麼還在那裡跪著……

extension則是個從OC沿襲下來的好東西，莫名你就能給一個沒有源碼的class加一方法，多牛，何以見得呢，比如在需要把字元串顏色值轉成UIColor的時候，就能這麼寫了："#ff1234".hexColor

optional則是個OC沒有的好東西，任何類型都能夠用非特數值表示「空」了，對一個Int來說，0和nil是兩個不一樣的概念。

還有多值返回，return (1, "OK")這樣子，不用定義一堆的struct了！

然後，社區支持的情況，叫做「盛況空前」，寫一個App需要的各種基本庫，Github上都有了非常成熟的Swift專門版，剛剛解析JSON的那個叫做「SwiftyJSON」，還有HTTP庫「Alamofire/Alamofire · GitHub」，非同步"Promise"庫「mxcl/PromiseKit · GitHub」

==2017/9/1補充==

不足之處：

1、Swift還不支持非同步函數async/await（用來解決非同步回調金字塔），目前還只能通過Promise來解決，但是Promise的缺點是用起來很複雜，目前只見到C#和ES7的async/await機制把這個問題透徹的解決了。

p.s. 有async/await支持的非同步模式可以極大的簡化IO（包括網路）相關功能的開發複雜度，不再需要放到工作線程來防止UI被阻塞，和線程相關的消息隊列、鎖、臨界區也就不用處理了。當然，計算密集型應用導致的阻塞還是得靠工作線程的。

p.p.s. 雖然C#支持async/await，但是相當一部分開發者都沒有真正理解這兩個關鍵字的意義，只說一句實話：這兩個關鍵字和線程沒有任何關係，表示異議就意味著確實沒理解:)

swift 是多範式編程語言。可結構化編程struct enum，可面向對象class，可面向協議protocol，可函數式 high-order，pure function。

集合了所有當前語言的精華，涉及到底層的優化（多用struct），抽象的架構思維（protocol-oriented，比java的介面強大很多），更健壯的代碼（functional programming），程序員友好（代碼簡潔，var let 省句尾分號...），另外，甚至DSL，元編程。

每個方向都帶你通往另一個大門。性能優化方向，架構師方向，函數式方向，函數-範疇方向，純函數-分散式方向（開源支持Linux），伺服器端方向（不止web server）。。最重要的是，swift看上去很簡單，寫起來很輕鬆，但能寫出多優美的代碼得看個人水平了。

蘋果的東西出來總是爭議很大，不過我會跟隨的。從quora上轉個國外某人@futurepaul寫的代碼。

一想到未來會有一系列書叫做深入淺出swift總覺得怪怪的。。。

現階段問題還很多啊

1、bug好多，cocoa庫的頭文件都有些有問題
例如：ios - parser.parse() in Swift leads to EXC_BAD_ACCESS
就是NSXMLParserDelegate的頭文件有問題，莫名其妙的bug
另外，xcode編輯器的bug就不說了，頻繁出現SourceKitService崩潰，整個代碼著色都沒有了

2、文檔很糟糕，一個是寫的不太全啊，很多該有的內容還沒有寫；一個是寫了一些超前的東西，把還沒實現的語法特性寫進去了，比如class var，類的靜態成員變數
optional枚舉類型講的也不是很明白，讓人不得不做很多實驗去理解到底是怎麼回事。比如，要將AnyObject?類型downcast到某個具體的比如String?，一開始我就猶豫，其實optional&和optional&應該不是在一個繼承鏈上的（按照C#的Nullable來理解的話），但實際上，是可以直接downcast的，下面都是OK的

let s1 : AnyObject? = "hello" let s2 : AnyObject? = nil s1 as String //"hello" s1 as? String //optional("hello") s2 as? String //nil s1 is String // true s1 is String? // false這就有點奇怪

3、基礎的庫還比較缺乏，太依賴現有的Cocoa，但是Cocoa有幾乎完全為了objective-c寫的
一些基本的容器沒有，比如NSSet；一些基本的數據類型的操作比較缺乏，比如Character類型，從頭文件看是個枚舉，但是看了半天都沒有弄明白怎樣把它轉化為unichar。也沒有找到可以用來操作Character類型的數據的方法，類本身提供的方法很簡單很有限。

4、把已有的objective-c寫的程序用swift重寫是個很痛苦的過程
想寫的非常swift幾乎不可能，很多地方只能用objective-c的東西
而且頻繁出現各種莫名其妙的問題，幸虧有stackoverflow

Objective-c 就是IOS的編程語言宗教。所有的東西都要用它開發——教主這樣說。現在教主已去，而IOS的APP也達到了空前的繁榮，是時候換一種積極的支撐方式了，能夠讓民間的開發者可以快速介入，即便是今天不出swift，明天也會有其他語言來替代Objective-c,觀察系統語言的發展,細心的你會發現，這是一種趨勢，類似的情況在其他系統上也發生過，而Objective-c將會退居幕後，做底層和中間件的開發。造成這種現象的原因也很容易理解，就是當一個領域空前繁榮之後，細分化，模塊化，流水線化，是必然的趨勢，拿APP來說應用層開發的高效性便捷性，將成為最基本的要求，而底層開發則要求穩定性和易用性。總的來說 Swift的出現是一種成熟的表現，目的就是適應這一領域高速的發展。如果你但從狹隘的語言層面來看這個問題，去寫你的Objective-c代碼吧，孩子。

好吧，好處大神們都說得到位了，是時候展現我陰暗的一面了。

當然，

以下都是個人觀點，僅供參考：

前面傳出google公司有意向使用swift作為Android的編程語言，額，不到真的有官方聲明，誰也不敢拍板吧。

然後回到正題，我真心覺得swift有時挺噁心的，理由只是因為Chris Lattner這貨讓我感覺真的有時是完完全全處於腦洞大開的狀態，如果是想要學習swift的，學習成本那真的是，唉~~~：

就拿數組Array和閉包Closure這兩貨舉個例（不建議各位以數字進行命名，下面只是圖方便）:

// 定義數組的幾種形式

var array1 = Array&()

var array2 : Array& = Array&()

var array3 : Array& = Array()

var array4 : Array = Array&()

var array5 : Array = [Int]()

var array6 : [Int] = Array()

var array7 : [Int] = [Int]()

var array8 = [1, 2, 3, 4]

寫完我就呵呵了。。。因為swift這種靈活性簡直令人髮指，很多其他語言都會盡量去固定語法格式，這種能寫出這麼多形式的，也許也挺好的不是，但學習成本嗖嗖的，你永遠不知道別人會寫出什麼形式的代碼出來啊摔！！！

後來我遇到了閉包這貨，唉，以下全稱一個閉包的減肥之路：

//一個簡單的函數

func greatorFun2(x : Int,y : Int) -&> Bool {

return x &> y

}

paopaoSort(data,function : greatorFun2)

//調用寫成閉包

paopaoSort(data) { (x : Int, y : Int) -&> Bool in

return x &> y

}

//首先可以省略參數的類型

paopaoSort(data) { (x , y ) -&> Bool in

return x &> y

}

// 然後返回值類型可以省略

paopaoSort(data) { (x , y ) in

return x &> y

}

// 再則，當只有一行閉包代碼 return 都可以省略掉

paopaoSort(data) { (x , y ) in

x &> y

}

你以為到這就結束了么，呵呵，還是太年輕了~你發現參數名也可以省略！！然後用「美金」來買通編譯器讓你通過，（ $0 代表第一個參數，$1第二個參數）

paopaoSort(data) {

$0 &> $1

}

所以結束了，呵呵~~~

此處可以省略只有邏輯（只有一個符號）了，加上拖尾閉包的概念就成一個{&>}這種東西了，我簡直凌亂了好么。

//paopaoSort(data) { &> }

paopaoSort(data, function: &> )

過掉一天，你回來看代碼一看我去這東西是啥？可讀性不是一般的差，你可以保證自己不寫這種簡式的代碼，但能保證別人不寫？

真的swift太靈活了，這樣真的很不好，之後希望蘋果能做出改變，畢竟入了ios這坑，為了錢，我還是要學下去的，即時學習成本真的好高。

目測蘋果這次會成功吸引一大批因為嫌 Obj-C 煩所以不碰 iOS 的動態語言開發者試水 iOS 開發，尤其是 web 開發者這一塊。平台之間的競爭，得開發者得天下。在爭奪開發者的戰場上，無論是 Native vs. Web 還是 iOS vs. Android，這都是蘋果的一著好棋。

我自己來回答下吧。這就好像iPad 1 剛出來，大家都覺得這貨是閹割了（無前攝像頭），而且毫無新意（大版iPhone) 然後過了3年呢，大家都感慨自己有眼無珠，缺乏遠見了。

Swift 的推出於此相比有過之而無不及。樓上各計算機大牛從語法，語義，機制，結構等方面剖析得很徹底，認定swift 並不是一門很高級的先進的語言。他們完全走錯了方向。其實這門語言的價值根本不是高級不高級，而是用的人多不多，代碼寫得快不快，寫出來的程序好不好。一旦開發者（特別是企業用戶，商務用戶，遊戲）從開發效率來說鐵下心支持ios , windows phone 就喝西北風去吧。。想像一下，obj c 這麼難用，都蠱惑了900萬開發者，語言榜第三。一個更加現代化又完全兼容obj c 的swift , 會有多大的影響力？
不需要多大想像力我們就能知道答案。即便c#再牛逼，又有幾個人用呢？排名第五罷了。
推出一個現代、安全並且特別面向移動端的編程語言，這是一個非常具有遠見的決策。native app 是未來，網頁沒有前途，Java 是渣。

90%的五百強企業都在使用ios , 一個簡單的編程語言就是在開開創新世界。Xcode 還不要錢。想一想。

Swift 奠定了蘋果未來5年在和google , 微軟大戰時的領導地位

作於語言來說Swift其實沒啥好說的，no silver bullet對於新語言永遠適用。

Playground在實際開發中我覺得沒有預期的那麼大，因為多數應用邏輯複雜且上下文相關性很強。

但是對於原型開發會非常有幫助。

其實狠簡單，swift就是apple自家的語言，當然跟xcode等ide合作良好，同時對於ios這種平台上開發來說，肯定是第一選擇，從語法角度上看，其實不重要，重要的是平台，只要ios還那麼牛逼，還能霸佔著80%的利潤，那麼swift就一定會有光明的前途，就像jvm遍地開花的時候，java再爛也不會爛到哪裡去一樣，決定一個語言的是生態，是平台，至於語法，再噁心你都得老實學，因為你沒有選擇，難道不是？
從語法上看，swift還不是狠穩定，swift3去掉了++，去掉了var參數，感覺還不穩定，前幾個版本語法改變比較大，breaking changes比較多，但是也可以感覺出來，改變越來越少，逐步趨於穩定，醬紫

翻譯一篇Rust開發者Graydon Hoare關於Swift的評論好了。翻譯的不好，大家見諒。

graydon2 | Swift

今天Apple介紹了Swift和一個相當火辣的livecoding環境。雖然playground很漂亮，但我在這方面並非專家，所以不做評論。我肯定有其他的livecoding nerds會在別的地方討論它的。

我剛剛閱讀完Swift語言的手冊，所以建議你們對我的評論別太較真。但是我可以指出一些著急的讀者可能很感興趣的部分。因為近期沒接觸過這個領域的人未必能像內行人一樣一語中的。一些其他的Rust nerds(Swift: a new programming language by Apple designed for safety : rust) 也在積極測試和評論。

邏輯

像許多最近的語言一樣，Swift基於LLVM，編譯到原生代碼。它很可能相當快，並且可以產生許多不同目標平台的原生代碼。這也包括內存使用和延遲仍然重要的客戶端代碼。
在設計Swift時，『與Objective-C對象模型互操作的能力』似乎被作為一條硬約束。這可能會限制一些Swift所能安全完成的工作。
看上去是專有的語言。我真希望不是。
似乎相當廣泛的借鑒了C#和...(我不知道怎麼謙虛和禮貌的表達) ... Rust。如果是真的我感到受寵若驚。當然，我是有偏見的。我這裡不是要聲明我是原創者，因為我自己也是一個語言多元論者，Rust本身也拼湊了很多其他語言當中我們喜歡的特性(ML, C++, C#, Lisp, Ruby等等)。見到我們所喜愛和推廣的概念在其他的地方流行是好事。希望開發團隊能夠寫些關於他們開發過程的文章，評論其他語言中他們所喜歡和討厭的部分, 以及他們所借鑒，改進或是自己重新發明的部分。趨同進化在很多語言中發生（經常發生有趣的效果）。

特性

沒有顯式指針(但是參看下文inout的部分），它依賴C#式的值/引用二分類型。這是在重獲因為Java式全Heap式系統而損失的性能同時不引入學習和設計負擔路上的半步。(備註：Java現在也在實驗值類型)。看上去是Swift和Rust最大的區別。這也意味著你不能輕易的取另一個結構體或數組內部的地址。這很令人遺憾，但是是合理的妥協。
既然沒有指針，自然沒有真正的機制來推斷所有權。當你使用引用類型的時候，它不過是一個指向共享堆的ARC指針或弱指針。Region，Unique性(Uniqueness)以及所有相關的性能增強與認知負擔都不存在。
單繼承，顯式覆蓋(override)和屬性(properties)，以及多介面("protocol")繼承。這是今天的標準，非常C#式的設計，看上去protocol不可以擁有默認方法。class是引用類型，structs是值類型。
通過extensions提供對類型的事後擴展能力。我不確定對它有沒有一致性的限制，我找不到。
lambda表達式似乎使用了非常Ruby式的塊結構(甚至包括後置參數的樣子!)。Rust一兩年前使用它，現在不用了(我有點喜歡它）。也有一個方便的使用編號參數的方式，像closure的#() reader macro.
很棒的帶有tuple和sum type的函數語言式代數類型系統，後者使用和Rust一樣的enum引入。你所期待的模式匹配和解構綁定(destructuring binding)。幾乎和Rust一樣，不過沒有用來綁定顯式指針的皺紋(wrinkle). 他們也避免了Rust的模式匹配當中所有的語法歧義，讓我很沮喪(他們在名字解析之後消除歧義）。
結合數字類型，更好的字面量(literals)，沒有隱式強制轉換的本地類型推斷。Yay！
腳本語言式（以及Go語言式）的詞典(dictionary)字面量。小事，但是會很受歡迎。
一個基本的模塊系統，沒有通配符，成組import或重命名。沒有可見性控制。但是通過attributes支持了重新導出。
沒有macro系統
沒有滿地的null，謝天謝地。相反，引入了C#和Facebook最近的Hack語言中的option類型和nullable語法糖，包括相當多的可選鏈式調用，強制和綁定，這很棒。
let和var關鍵字，用以區分可變(mutable)和不可變(immutable)對象。

奇怪的(Peculiarites)

數組有奇怪的copy-on-extension語義，但是我覺得它們可能總在堆上？字元串看上去也是基於堆和Copy-on-Write的。不太清楚。
不清楚你自己是否或如何能實現iterator protocol.
參數可以是inout的，這樣的參數看上去不可避免的要求一元運算符。有意思的是，像Objective-C一樣，inout關鍵字拒絕死去。在Rust當中，在我們發展出first class region pointer("lifetime")系統之前，我們也幹了類似的事（"parameter modes")。參數傳遞模式和真正指針之間的不對稱最終讓我們無法忍受，不過我猜Swift不覺得這是啥大問題。
看上去不是一個表達式語言，我猜『沒有macro系統』，所以...
除了代數類型沒有討論錯誤處理，option類型和奇怪的對"runtime error"的偶然引用。不確定Swift使用什麼孤立/回復系統，或者系統是否存在。關鍵字"unwind"在手冊當中沒有出現。
命名參數看上去可疑地像OCaml的"OLabl"變種。我不確定這有多大的用。
帶有檢查的算術，以及16進位浮點字面量，Yay!

總體來說我基本同意Bryan O"Sullivan的推特：

今年的學術界函數語言會議將會感覺像是一系列的勝利慶祝。夥計們，好時候啊！
——Bryan O"Sullivan(@ bos31337), 2014年6月2日https://twitter.com/bos31337/statuses/473569531366211584

當我開始開發Rust的時候，很大的動力來自於在使用C++『為工資』工作的時候，會喪失我在業餘hacking中非常喜歡的ML主義特性。我們試圖將很多這樣的元素（代數類型，模式匹配，Option，annotation-light類型）引入失敗的ES4項目，但是它不勝負荷而崩塌了。

對我來說意義非凡的是，在這些年中，我們見證了被認為是『正常』新語言特性的變化。F#在多個平台上發布(不知道M#會不會仍然這樣）；Scala被認為是一個求職的有用的技能；如果說C++11沒有類型匹配和代數類型的話，它也擁有Lambda表達式和本地類型推斷。Rust現在存在了；現在我們可以看到Apple生態系統帶來了類似的慰藉。多開心啊。

幾天的體驗是無法了解一門經過四年開發出來的語言的，所以，我相信真的懂代碼的人是不會對這門語言做出判斷的，對於一門語言來說，時間是檢驗真理的唯一標準。提再多的專業名詞對於回答提問者的問題是沒有太大幫助，所以我只從一些淺顯的角度去做一些分析，僅僅是分析而已。而且我極力推薦提問者閱讀松本行弘先生所著的《代碼的未來》，這比你在知乎尋求答案要好的多。堆砌再多的專業名詞也無法說明你有多麼牛逼，還是乖乖去寫代碼吧。
我只是一個大學生，我對編程語言的理解很淺，當然不能跟大神去比，看了知乎上的答案後我覺得沒有找到特別滿意的答案，所以我就去stackoverflow上看一下國外的程序員的看法，令我很意外的是他們的答案都很統一，「put on hold」，我覺得這三個詞才是這個問題的真正答案。那麼接下來我就來說說我的看法好了：

1、首先說說吐槽的人吧，很多一夜之間讀完the Swift Programming Language的人只是熟悉了他的語法，我相信很多有過其他語言如Ruby，Python，Haskell等開發經驗的一些人，對於Swift很容易上手。Swift相對於Objective—C入門門檻下降了許多。But，你真的懂這個語言的精髓嗎，Swift只是LLVM的一環，你單純評價它的語法會不會太片面了呢。
2、Swift才剛剛誕生，蘋果的庫還是Objective C寫的，但是蘋果已經為Swift寫了介面，全面改寫庫只是遲早的事情。而且因為蘋果的保密文化，Chris Lattner在開發這門語言的時候可以說是單槍匹馬，有缺陷是肯定的，但是蘋果一定是會完善的，這點毋庸置疑。所以誇上天的話也沒必要，年輕的語言註定是要接受時間的考驗的，隨著開發者們對庫的完善，Swift肯定是會越來越好。所以沒必要拿來跟別的語言比。
3、Put On Hold，時間會證明一切，現在下結論實在太早。如果你問這個問題只是想知道這門語言的好壞決定要不要學的話，我只能說，too young too simple，學習語言不是買東西。
Finally，不要再說你多快看完了一本書，我想問你對他的底層了解多少呢，真的了解LLVM的又有多少呢，腳踏實地才是正道，讓時間去檢驗吧，我等渣渣在旁邊看看就好了，多學一門語言也不會掉一塊肉是不是？

講了那麼多好像沒有評價這門語言哦，那我隨便說兩句好了，我就從我這個新手的角度來看看好了先來說一下這門語言的特色好了。我推薦大家去看一本書，是Ruby的發明者松本行弘先生寫的《代碼的未來》，當我看完發布會後，我的第一感覺就是Swift不就是松本行弘先生所說的代碼的未來嗎？：

1、寫起來像腳本語言的編譯型語言，它有腳本語言寫起來的舒暢感，跑起來又有編譯語言的速度感，這都多虧了LLVM啊。
2、松本先生說過，隨著多核CPU和多核GPU的出現，語言多多線程的支持顯得尤為重要，Swift支持的很好，而且對蘋果的A7有過優化。我沒有看完guide tour，所以我不知道有沒有非同步支持，所以不發表看法。
3、語法特性我就不分析了，我也不會，OC的語法都能接受，Swift的語法豈不是更好接受。

就說這麼多，不足之處請見諒，錯誤請在評論里指出，我會做出修改。

PS：從這個問題上就可以看出為什麼在計算機領域國外要比國內強很多了，我覺得每個人都應該思索一下。語言組織不好，請見諒，我語文是體育老師教的。

最近剛體驗了一下，打算接下來的項目裡面用上去。我們不做工業級的項目，不寫工業級的代碼，我們就是成千上萬的小應用開發商。粗看有各種函數式語言的成分，很多地方跟ruby很像，但是竟然還有erlang、prolog那種turple和匹配，看起來是個函數式語言的大雜燴，擁有各種先進特性。
那麼，做小項目進度會快很多！工作中我試驗過，即使不熟悉函數式編程的純粹objective c程序員，教他們一些map、select之類的簡單函數式編程的也是很簡單的事情，可以大幅度提高工作效率，這一點很現實。
至於沒有異常、沒有gc，對於我們做小項目來說不是大問題。以我們的項目規模，出了各種不穩定的crash根本沒資格抱怨這種東西。而且，也許不久以後就會有呢。

@yue wang 的答案寫的很好，應該看一看。

我只想說，swift做出的很多決定竟然跟我www.gaclib.net 那個隨手發明來寫進xml的腳本一樣，譬如說$x用來代表lambda表達式啦，類型寫在名字後面啦，只有let和lambda才能做類型推導啦，用一個不完整的GC語言寫出來的library直接map成腳本的object model啦（基本上腳本長得那麼彆扭都是因為這個，我那個也一樣）……

apple藥丸

不過反正swift做的這麼丑果粉們都不會有意見的，因為至少比更丑的oc好看（逃