逻辑

像许多最近的语言一样，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!

逻辑

像许多最近的语言一样，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!