问题描述
未来注定是多核的世界，问题在于如何去解决多核的危机。Scala和Erlang是两门渴望成为其解决方案的语言，但它们也有些许的不同。那么它们所采取的方式各有什么利弊呢？引入问题摩尔定律已经改变了。我们不再获得和以前一样的时钟频率增长，取而代之，我们得到了更多的（CPU）核心。今天，也许你的笔记本都已经是双核的了。为了利用多核的特性，应用程序需要支持并发。如果你的客户买了一台八核的机器，要向他们解释清楚正常情况下应用程序只会用到12%的CPU能力将是一件费时费力的事，即便该机器是为该应用量身定制的。在未来，情况可能变得更糟。你的顺序执行代码不仅不会跑得更快，甚至有可能实际上跑得更慢。其原因在于，你获得越多的核心，由于功耗和散热的影响，每个核心就会更慢。几年之后，英特尔就会给我们带来32核的CPU，按这种趋势，在我们不知不觉之中数千核的CPU就会出现。但每个核心都会比现在的核心慢很多。并发代码一个显见的解决途径就是编写（或重写）软件以支持并发。最常见的方式莫过于使用线程，但大多数开发者都认为基于线程的应用编写起来特别的困难。死锁，饿死以及竞争条件对大多数并发开发者来说都是太熟悉的概念了。Erlang和Scala都大大减轻了这种痛苦。语言概览Scala常被看作是下一个主要的JVM语言。它结合了面向对象编程的范式和函数式编程的范式，与Java相比有着更简洁的语法，它是静态类型的，有着跟Java一样或者有时候更快的运行速度。有太多的理由值得去认真探索一下Scala。Erlang是一门为健壮性而生的语言，由于它的设计，它自然又是一门有着极好伸缩性的语言。它比Java历史更早，但却常被看作引领未来并发的语言。它是一门动态类型的函数式语言，有着一些非凡的系统正常运行时间的成功例子。争论核心那么Scala与Erlang争论的到底是什么呢？说到底，就是性能表现与伸缩能力，但这争论也包括了其它像风格，语言特性以及库支持等等。这场争论开始于Ted Neward有一次无心的给出了他对几种语言的看法，并称“在其自己解释器上运行事实上很差的”。Steve Vinoski与Ted于是展开了几轮争论，但这一讨论很快转移到了更多的博客上，争论的焦点也转变成了Scala与Erlang之间那些有趣的差异和共同点。我们将总结每个有意思的论点并给出每种语言的利弊，并表达对一些问题的各种不同看法。可**性Steve Vinoski就Ted所发表的帖子进行了回应，给出了他对于“Erlang在其自己解释器上运行”的感受：事实上，Erlang在其自己解释器上运行得，很好很强大；如若不然，不可能有如此好的可**性，它将只是又一个面向并发的有趣但却无用的语言实验而已。Steve谈到这个问题，就算一个语言本身可**，它所依赖的基础也必须可**才行。因为Erlang从骨子里就是为可**性而设计的，从而支持并发，所以它不会受到一些并发性常见问题的影响，这主要是底层库包在并发环境下运行很好。另一方面，Scala是站在JVM之上的，所以一个重要卖点在于可潜在地使用所有现成的Java代码。然而，大部分的Java代码并非专为并发而设计的，使用Scala代码时要将此考虑进去。轻量级进程要运行大规模并发应用，你需要大量的并行执行。这可以通过几种方式达到。使用线程是一种常见的方式，使用进程又是另一种。其区别之处在于，线程与其它线程之间共享内存，而进程是相互**的。这意味着线程需要像互斥信号这样的锁机制，防止两个线程在同一时间对同一内存进行**作，但进程不会受此问题影响，相反是使用一些消息传递机制来跟其它的进程间通信。但进程在性能和内存方面的代价是昂贵的，这正是人们就算知道基于线程的并发是一种极复杂的编程模型也宁愿选择它的原因。Steve Vinoski这样写到：提供互不共享的轻量级进程架构将使得大规模并发能力变得十分容易，但这并不意味着一旦你设计好了，剩下的就只是编程的工作那么简单。Erlang采取了这样的并发方式。一个Erlang进程是非常轻量化的，Erlang应用常常拥有成千上万的线程甚至更多。Scala通过基于事件的Actor从另一方面达到了同样的效果。Yariv Sadan解释说：Scala有两种类型的Actor：基于线程或是基于事件。基于线程的Actor在重量级的OS线程内部执行。它们从不相互阻塞，但每个VM上可伸缩的Actor不会多于几千个。基于事件的Actor是简单的对象。它们是十分轻量化的，并且，像Erlang进程一样，因此它们可以在一台现代的机器上数以百万计的产生。Yariv解释到，尽管如此，这里面也还是有一些区别的：与Erlang进程的区别之处在于，每个OS线程内部，基于事件的Actor是顺序执行的并且使用没有强占式调度算法。这使得一个基于事件的Actor可能在很长一段时间内阻塞其OS线程（甚至是无限的）。不可**Erlang是一门函数式语言。这意味着其数据是不可变的，像Java的String一样，并且没有副作用带来的风险。对数据的任意**作会产生一个该数据新的修改后的版本，但原数据仍然不变。在谈到健壮性的时候，不可**是其需要高度注意的一个因素，因为没有代码可以无意间修改其它代码依赖的数据，但从并发的观点来看，不可**也是一个十分重要的特性。如果数据不可变，其被两个并行执行路径更改的风险就不存在，因为没有办法改变它且不需要保持同步，所以数据可以被拷贝到其它机器上。因为Scala构建在JVM之上，结合了面向对象和函数式方法的特点，它不具备像纯函数式语言的不可**的保证。然而，在Yariv日志的评论部分，Yariv和David Pollack就这两门语言之间的差别展开了一场有趣的讨论。David，Scala Web框架Lift的作者，给出了他对于不可**的看法：不可** —— Erlang强制了这一点，而且你几乎无法绕过它。但是，与强制一个单一类型相比，你可以用Scala神奇强大的类型系统的剩余部分去交换。我在进行Scala Actor编码时使用不可变数据，而让Scala的类型系统负责其它类型。 Yariv问到：只发送不可变类型难道不是一个重大限制吗？这意味着，例如，你不能从Hibernate装载一个简单的bean并将它发送给其它Actor。 David回答到：我曾基于Scala的Actor构建个多个生产系统。实际上对于不可**问题并没有多少工作需要处理。你只需要将你的相关类（消息）定义为不可变的，其它的就不用管了。类型系统Erlang是动态类型的，而Scala是静态类型的并且相比Java有着更强的类型系统。然而，与Java相比最大的一个区别是Scala可以类型推断。这意味着你可以省掉大部分的类型注解，使得代码更加**净而编译器照样会做所有的检查。关于动态与静态系统之间孰是孰非的争论看来永远也不会停止，但Erlang和Scala之间却有着显而易见的区别。尾递归或是循环Yariv又提到：函数式编程与递归从来都是形影不离的。实际上离开了尾递归你很难写出有用的Erlang程序，那是因为Erlang没有循环——它对一切都使用递归（这在我看来是一件好事 :））。 这显然使得Erlang与Scala产生了很大差别。Scala提供了很多更传统的迭代，但David Pollack并没看出在这种环境下尾递归有什么优势：尾递归——对基于事件的Actor来说根本不是什么问题。 如此说来，这仅仅有关你的偏爱和风格罢了。热交换代码由于Erlang是为可**性而生的，热交换代码（运行时替换代码）是其内建的天性。JVM对热交换代码有所支持。类可以被改变，但由于其静态的类型系统，其方法签名是不可改变的——只有其内容可以改变。虽然有第三方工具致力于此，也有框架（提倡以一种使运行时更方便交换类的编程风格书写代码），但就算运行在JVM上，如何进行交换仍是取决于你的Scala Actor是如何构建的。Jonas Bonér就此给出了一个详尽的例子。总结Scala和Erlang都是致力于解决多核危机的语言。它们来自不同的背景和年代，因此对待某些问题的方式也不尽相同，然而在许多方面它们的共识大于分歧，至少在并发性上如此。Erlang已经有着数十年的历史，并且已经在许多关键的真实系统中证明了自己。其不足之处在于它有一点像一个孤岛，最近的多语言编程的趋势似乎对Erlang社区影响不大。另一方面，Scala是同一类型应用的新生儿。一些真实应用即将诞生，并且一些公司将未来押在了上面。Scala相对Erlang的最大优势在于，它运行在JVM之上并且可以利用所有现成Java代码、框架和许多工具。话虽如此，这种强大的能力也要求了更大的责任，因为大部分Java代码不可能自动适应Scala的Actor模型。对于主流语言无法帮开发者解决的压力越来越大的问题，两种语言都对提供了相似的解决途径。希望你在读完这篇争论总结之后，能更清楚哪种语言更适合你的特殊要求，并对其深入了解。未来是多核的。Scala和Erlang将会越来越流行。