如何评价 Swift 语言？修改
今天苹果推出了全新的基于脚本的编程语言 Swift。Swift 有类似 Python 的易用性，又有较强的运行效率。它弥补了 Objective-C 的哪些不足？融合了哪些其他语言的优秀特性？将它和 C# 相比，各有什么优劣？它会对未来的软件开发产生什么影响？作为一个程序员，此刻，一个对世界消费者和消费平台都有着广泛影响力的公司，推出了一个全新的语言，所有人都是0基础，你有什么想法？
孙竟，专控萝莉 20 年
MaxPassion、Mister.Z、刘博 等人赞同
本想看完文档再写的，不过看到排名靠前的答案有些偏激（你们不就是想找个理由不学嘛），还是先写些看法吧。
首先，它不是一门玩具语言。
去看看它的文档就明白了，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 算不上一门很好的语言。 2014-06-05 59 条评论
yue wang，要永遠跟智商高比自己的人來討論問題
durti ma、邱超凡、胡时伟 等人赞同
我刪了原先有爭議的答案，重寫一下，之前列的每一點都在，只是論據上做了很多更新。不過 基本觀點和原判斷一致－－這就是個玩具語言，降低 Apple 平台開發門檻用的（否則要 Playground 幹嘛？），以至於 Apple 自己都不用。寫幾百幾千行的程序可以，數萬數十萬的項目就心有餘力不足了。 等 Apple 自己項目採用了，我再有可能改掉這判斷
其實這語言還有很多不足，但限於篇幅我還是列原帖中就提到的幾點
－ swift 和 c/c++ 對接很麻煩，得通過 objc （尤其是 C++ ）這極大限制了它的使用。 很多公司的代碼， C++比重很大，因為要跨平台或是有各種公司內部底層項目的依賴。swift 在這點上相當糟糕。ObjC 精明很多。
－ 所有變量都 public ， 沒有隠藏機制，不適合大型項目開發（很多人說無所謂，可以通過規範約束，這分明是沒多少大項目經驗的人說出來的話－－我想問靠自覺好還是讓編譯器和 IDE 不讓你胡來好？很多時候，IDE 中沒辦法補全代碼時，你才會想起“哦，原來它是私有的”。事實上，如果沒有語言層面的支持，這種問題即使像 Google FB 這種高手如雲的公司，同行 peer review 代碼也不一定能發現，因為這種問題本身就不好查，你發一個 code review 幾千行調用，別人一個個給你查去？這些公司就是用如 Python/PHP 這樣的語言的，也有 static analyzer 來糾正程序員的很多問題）
－ 基礎庫很爛，基本依賴 objc 的庫。是的，你原生有數組有哈希表，但除了這兩個，基本就沒啥了，連Set 都沒有。所以到頭來還是得使用 objc 原有的 api。這就産生兩個問題，一， objc 不是 type safe 的， 比如沒有 generic 機制。二，效率比 native 的低，因為 objc 的 method call 不如 function/method call 高效。同理， Apple 不可能改變 ObjC 的地位，因為它是 swift 的 基石。整個 Cocoa/Cocoa Touch 的 API 都是 ObjC 風格的（比如沒有 generic），所以不可能指望 swift 替代 ObjC
－ 沒異常機制。有人說這不重要，Apple 的庫自已也不用異常。那其實是你沒接觸過一些重要的 design pattern。其實，很多公司用很多語言會禁用 exception，比如 Google C++/ObjC Style Guide 中，都不允許用 Exception。但開發一些重要的底層模塊需要這個機制。否則怎麼造輪子？
－ 原答案中說 Grand Central Dispatch 等 C 庫沒法使用， 是我疏忽，因為 Apple 給出的文檔更新日期標得不對，我以為其沒有更新，在此致歉。另外 Swift 文當真心爛，不但費解，我現在粗看已經看到很多錯誤（打錯字的，或者明明是重要接口但沒出現在標準庫文檔裡的比如
hashable），不過一個新出的語言總有這種問題，現在還 preview，不能太過責備。
下面那些高票回答，基本也就是本著看看語言教程做的結論。說 swift 語言有多先進的，基本少見多怪，設計得花哨好看的語言多的是，swift 絶對不能算。判斷語言好用不好用，還是得自己看看項目中怎麼用。我差不多十年前看了 Haskell 的教程，覺得這玩藝太 TMD 牛逼了， 等實際用它寫項目了，就覺得這種怪胎語言設計者是腦殘嗎？所以看教程就做評論的結果我一般是不信的。
（底下一嚷嚷函數式語言有多好，叫囂 haskell 能多廣泛地寫實際項目的人，你知道你多無知嗎？你哪怕寫個稍微麻煩點的項目，就知道除非你通讀ghc編譯器源代碼，否則怎麼踩雷的都不知道。要用它寫出不漏內存效率不明顯降低的代碼，寫出來就跟c差不多難看了，而難度比c大多了。哪個語言還要求你寫程序得通讀編譯器源代碼？在公共場合秀智商下限有意思嗎？哪怕像Twitter 或LinkedIn 用scala也是用對象抽象而不是用函數抽象的。你噴我只能證明你沒經驗，懶得理你呦） －－
噴子們愛噴就熱情地噴吧，我把評論打開了，方便你們噴，你們噴我都懶得理你們。 說我是外行的，我已經把我的行業改成了建築業。真的，我是學建築的，不騙你們：） 2014-06-07 268 条评论
黄兢成，iOS开发人员，喜欢睡觉，看书，编程
弈然心动、子成、Sin Cheung 等人赞同
翻完iBooks书店上的The Swift Programming Language, 也下载了Xcode 6的beta版本来试验了一下。现在可以评价一下。如发现不对的地方，请在评论中指出，我斟酌后进行修正。 主要从技术的角度。而商业的角度，吸引开发者，共同维护苹果生态圈的繁荣等之类就不说了。 我不敢说swift学了有没有用，可不可以挣更多钱，但这门语言还是比较有意思的。swift骨子里面还是objc，但打扮过，比原来的模样漂亮。个人感觉，苹果还真的想用它取代objc呢。 ------------------
swift 跟 objc 共用同一套的运行时环境
swift 的类型，可以桥接到 objc 的类型，反之亦然。如 string 对应原来objc的NSString, closures对应objc的block，等等。objc 积累下来的大量库，实现不用改写，swift 就直接可以使用。（最多加个声明文件）。看两个API的声明，对比一下 objc
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中的接口文件，是利用原来objc，c中的接口文件自动程序生成的。
同一个工程，可以同时使用swift, objc, c, c++ 四种编译语言（额外嵌入的脚本语言另算） 原来的 iOS/Mac 工程，已经可以同时使用objc, c, C++三种语言。现在支持第四种。objc, c, c++三种语言的结合很容易， objc跟c本身就兼容，objc跟c++结合只要将文件名改成.mm。而swift跟其它语言的结合，需要另外的文件进行桥接，其实也挺方便的。
这里的桥接很容易，Apple自家的各种 C 库移植过来了。比如Core Image/Audio，直接包含
import CoreAudio import CoreImage
就可以使用了。
现在swift完全可以跟objc并存，原来的工程不建议重写，也不用重写。顺其自然，慢慢让它进化就是了。
swift 写法看起来像脚本语言，但它是真正的编译语言 初学者，看它使用了
let a = 4
var b = \
没有类型定义，就想当然的觉得它是脚本语言，解释执行，这是错误的。上面两行语句是用了类型推导，类似 C++ 里面的auto。swift跟objc的运行时环境一样，写的程序跑起来不会比objc慢。swift区分了struct和class, 分别使用传值跟传引用。适当地使用struct，应该会比objc要快一点。
swift 吸收了很多其它语言的语法，写起来比objc简洁得多，不过它骨子里面的概念，跟原来objc差不多
编程语言的语法重要，但是语法背后的概念更重要。比如面向对象，常用概念无非是，继承，多态，封装，信息隐藏等。继承又可能分成多重继承，接口继承，实现继承。或者还会有些嵌套类，嵌套函数等等。
当明白语法背后的概念，知道为什么需要有这些东西。之后从一门语言切换到另一门有着相同概念的语言，其实很容易。
而语法会影响表达，理论上每门语言都可以表达任何概念。不过当某种概念在某门语言中，很难表达出来，就会倾向于不这样使用它，这种概念在那门语言的社区就难以被人熟知。 感觉上，swift有着 obj-c, C++, Ruby的影子。 暂时，我自己最喜欢的3个特性有 ? ? ?
tuple，终于可以返回多个数值了。一行交换两个值。C++里面的tie+tuple也可以实现类似功能，不过使用库，显得噪音太多。
closure，喜欢它的简写，还有在函数最后一参数，可以写在()外面。这些特性，用来写函数式风格的程序，会很好看。而原来objc的block, 还有c++的function, 就太啰嗦了。 switch，case里面的条件匹配。
这些语法，编译最后还是会映射成原来objc的运行模型。原来objc的概念，引用记数，ARC, 属性，协议，接口，初始化，扩展类，匿名函数等等，继续有效。 我将swift看成是objc的一块大大的语法糖。
有个大块头的东西，是原来objc没有的，就是泛型。swift中 将那种操作写一次，就可以作用多个类型的语法叫做generics（泛型），而C++中称为template（模板），叫法不同，本质是同样的东西。
总的说来，swfit 涵盖了现在流行的编程方式，结构化，面向对象，泛型，函数式。
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
这种写法，看起来跟原来的命令式写法完全不同。这些程序是描述性的。原来的objc, 做不到这点。 我估计swift以后会冒出大量这样风格的库。
这种风格，到底好不好，要看情况。比较方便定义内部DSL的语言, 我自己知道的有C++, Ruby, Lisp。现在多了Swift。
认为所有人都是0基础的，是错误的