速度嘛，的确比C/C++慢，没办法，人家C/C++是直接编译成机器码，而咱是编译成class文件，需要java虚拟机解释执行。
要说速度慢到哪里去也不至于。图像处理很费时吧，最近使用相同的算法处理相同的图像，C/C++所花的时间是java的一半而已。
优点：
1.自动回收内存
在C/C++中你敢这样写吗：
int
w
=
getWidth()
byte[]
data
=
new
byte[w]
2.
eclipse代码补全功能
需要什么打一下点，就什么可用的东西都列出来了，只要不是语法错误，没有引入需要的包，点一下红叉叉，自动导入。C/C++还要去查MSDN之类的东西，找头文件。
3.代码组织
类名、方法名、变量名一目了然，看一眼就大概明白是干什么的。C/C++中那些全大写，下划线等等乱七八糟的东西，看到就头晕。
5.指针，java中没有指针，避免了很多麻烦。
此处省略几万字……
缺点：
1.运行效率，这个咋没办法根C/C++比；
2.结构。我们有时候需要一个结构，但java中只有类。而且，比如要读取bmp文件，C/C++直接申明一个结构，然后直接把数据读到这个结构中，一行代码搞定。而java要读取文件中一个整数，不得不读4个字节，自己来拼成整数，虽然RandomAccessFile提供了readInt之类的方法，但是都是按BIG_ENDIAN读取的，没办法读取LITTLE_ENDIAN。
3.指针，虽然这是java的一个优点，但有时候也是它的缺点。某些时候我们真需要指针。而且还需要用负数做为索引访问一个指针的内容，而java中是不允许负数做为数组索引的
鲍勃·布雷迪。bibianeruby的真名为鲍勃·布雷迪，是宾夕法尼亚州的民主党众议员，2015年9月24日，罗马教皇方济各发表讲话，在演说期间，布雷迪注意到方济各曾喝水最少，布雷迪就起了要把这杯子和圣水拿到的念头，得到水的布雷迪把水与妻子和同事分享，布雷迪表示，他非常尊敬教皇，他计划把剩下的水用杯子装起，当作“圣水”，洒向孙儿及曾孙作祝福。杯子也会被鉴定和珍藏起来。以前在这个版块也答过关于Scala的问题，但那更多的是知识普及，而没有谈Scala是什么，做什么，以及有怎样的特点。
Scala可怕的地方在于人人都能对它说上一二，但是不一定每个人都能明白。查看这个版块的帖子，有人把它当做Java的延伸版（一个UPenn宾大的学生Justin Kim ——此人目前在沃顿混得风生水起，当着我的面说Scala是在JVM上的脚本语言），有人把它当做JVM上的C++，有人觉得这是面对对象语言和函数语言的简单混合，有人觉得这就是Haskell，而且也还不如Haskell强。对Scala的偏见（或者是错误的见地）达到了很高的地步，Martin Odersky马丁·奥德斯基（Scala的发明者，EPFL教授）在今年夏天的Scala Day旧金山大会上发出了这张著名的玩笑照片：
gt
这个图片上的翻译是：“Scala唯一的作用是将人引向Haskell”（原谅我没法完全直译）。马丁·奥德斯基以此作为一个笑话，说他该把Scala改一下名字，叫做Hascalator，还请人设计了一个Logo。
不同的语言有不同的特点，同时也带来不同的优势。如果不能理解Scala的特点，就不可能知道如何运用Scala，以及发挥其最大的优势。一些语言有很显而易见的优势，也很容易理解，比如Python，Python的哲学（Zen of Python PEP 20 -- The Zen of Python），我很早的时候曾经觉得有道理，尤其是One way to do it（一种方法做一件事情），理由是对任何任务，虽然可以采用很多方法，但总有最好的一种方法，通过在语言或者哲学层面这样定义后，能简化程序员的任务，从而达到提高效率的方法。但经过一段时间的思考后，我突然发现Python其实并不是“一种方法做一件事”的哲学，而是“一种方法做一百万件事情”的哲学：极其有限的数据结构（只有四个: List, Tuple, Dictionary, Sets），以及不能查看时间复杂度的访问方法，比如鼓励人们使用for x in list。
这种处理方式能达到Python最初的打算：发明一种每个人都能使用的简易语言，但是对于追求速度和效率的程序员而言，这几乎是略带噩梦性质的。当然，这不是说Python很慢，通过各种优化（比如NumPy/SciPy中的），以及Cython这样的将Python直接翻译为C/C++语言又重新通过C_Module方式读回Python环境的编译器，性能可以得到不少提升，但是仍旧，Python并不追求快。
再举一个语言的例子：Java。Java的特性或者优势何在？Java的第一个优势在于它是第一个系统提供模块化（module）设计的语言（在此之前有Smalltalk存在，该货是OOP的鼻祖）。在Java之前，炒程序员鱿鱼是很困难的事情，那些C/C++程序员，以及而且尤其是那些Lisp程序员，一旦炒掉他们，新来的人没有十天半个月，甚至半年，是不可能搞懂前任人士的代码的。每个人的代码有自己的逻辑，自己的思路，写上个数万行任谁来看都头疼。这也是为什么Paul Graham保罗·格雷厄姆（写了《黑客与画家》）讲他给雅虎做了一个用Lisp写成的在线商店的案例，在他离开后，雅虎根本没法维护他写的代码，因为数万行Lisp没人能弄得很清楚。
Java的模块化，给企业、大公司带来了第一道曙光，模块化之后，这些公司不再给程序员一整个任务，而是一大块任务的一小块。接口一定义，虚拟类一定义，换谁上都可以，管你是保罗·格雷厄姆这样的明星程序员，还是一个新来的大学生，程序员不听话就直接开除，反正模块化之后，开除程序员的成本大大降低，这也是为什么谷歌、甲骨文（这货最后收购了Java）一类的公司大规模的推崇Java，还一度提出了模块化人事管理的理念（把人当模块化的积木一样随时移进移出）。
过度企业化后，这延展出了Java的第二个特性，束缚手脚。保罗·格雷厄姆在《黑客与画家》中写道，Java属于B&D（捆绑与束缚）类型的语言。为何束缚手脚？因为要让新手和明星程序员写出类似质量的代码，尽可能的抹消人的才华对程序的影响。不同于C/C++，老手和新手写出的Java代码不会有上百倍的耗时差距。但同样也导致了Java的一个弱点——不容易优化。很多优化Java代码的程序员必须要对JVM（虚拟机）进行优化，实际上增大了很多任务难度。
通过Python和Java这两个语言的优缺点，返回来看Scala，就能瞬间明白Scala的定位了。
首先，Scala不把程序员当傻子。当马丁·奥德斯基宣布Scala 2.12将要简化语法，推出Scala "Don Giovanni"项目的时候，在视频中说的很清楚：“Scala现在是为聪明人创造的，以后也是为聪明人服务的。”所以不同于Python让程序员用一种方法做所有事情，Scala提供一整套工具，让程序员自由选择，无论是mutable数据结构，immutable数据结构，并行（parallel）数据结构。然后在这些选择中，Scala再针对他们进行算法层面的特殊优化。Scala相信程序员的聪明才智，让程序员自行选择合适的结构，以针对变化万千的任务需求，这点是Scala做得极好的地方。
再者，有人会说immutable数据结构占用内存，或者速度很慢。这是真的，但这不是Scala的错，而是这些结构就是这样定义的。这里讲的是Scala集合的运行速度，是一个来自Goldman Sachs的程序员讲他们为Java写的集合库（GSCollection）速度和内存消耗，但同时比较了gs-collection（goldmansachs/gs-collections · GitHub），Java，和Scala库的速度。最后Scala的可变集合mutable原生库完爆Java，和gs-collection基本持平。
Scala的第二个优势，相较于Java而言，则是相信程序员的优化能力。在Scala with Style讲话中（），马丁·奥德斯基说：“很多程序员会告诉我，他们一般会重构他们的Scala代码两三次，甚至三四次。”这听起来似乎非常的没有效率，但Scala就是这样的语言，每一次重构，代码的性能或者是可读性都会有极高的提升。
之前就有人提到过，Scala新手和老手写出来的代码完全会呈现两种不同的风格，甚至新人根本不能读懂有经验的Scala程序员所写的代码，有人于是戏称：“太好了，这样的话我们部门的实习生就不能乱碰我写的代码啦！”但其实不仅风格不同，执行效率差距也一定是巨大的。Scala提供一整套工具，但是要明白什么时候用拿一种工具，哪些算法能够随意调用，哪些算法不能，这一定要依靠经验、研究和学习以及对源代码的理解才能得知。最简单的例子，Scala的foreach()方法是高度优化过了的（尤其针对Range结构和Vector结构），但是fold()就不一定了。或者当受到诱惑想用zipWithIndex()的时候，一定要明白这是两次循环，最好改用Vector(...).indices.foreach()的方法，或者用.view来推迟执行。
像这样的地方还有很多。所以在这个层面上来讲，简直和C++非常的相似。从另外一个层面来讲，不仅仅是要理解语言层面的优化，Scala作为一个社区而言，是非常追求运行速度的。Ruby社区就完全不同了，Ruby曾经是推特的主要语言。推特的团队找到了Ruby团队，说，你们能不能让Ruby运行的快一点，我们有这个这个和这个建议。Ruby直接把这些建议拒绝了，因为它们会增加语言复杂度，让Ruby不能继续做一个“fun”（好玩）的语言。而Python直接就立志做一个“Simple”（简单）的语言了。于是推特只好将后台换做Scala和Java的结合。有一位在推特工作的知乎友人在我的一个回答下留言说推特换用Scala后，TypeSafe（Scala的母公司）还送去了一个蛋糕。
为了追求速度，Scala社区是绝对不会管所谓的“简单”或者是“好玩”，怎样有效率就怎样弄。与其专注于JVM的改进，Scala社区大部分在编译器上下功夫，比如很著名的Miniboxing（Miniboxing），这是一个编译器增进器。Miniboxing做的是什么呢？只做一件事：防止auto-boxing和auto-unboxing。所有的泛型，尤其是原生类泛型（Primitive Types），诸如Int、Double等等，在进行各种操作的时候会自动取出和装回它们所属的类中去——这个我解释的不太好，但是可以看这里（Java 自动装箱与拆箱(Autoboxing and unboxing)）。
Miniboxing这样的插件可以让所有的原生类泛型再也不用自动装拆箱，从而将Scala的运行速度提升1.5倍到22倍（）。当然这样的东西可不是白来的，这是马丁·奥德斯基的PhD博士学生做的一个研究项目，然后为OOPSLA写了一篇论文（），所以怪不得这玩意Scala可以有，但其他语言想要有都没有。
另一个Scala的很大优势就是所谓的Macro——宏。宏本身作为元编程而言，其实和运行速度是没有什么太大关系的，反而，因为对反射（Reflect）的利用，可能会影响到速度。但Scala社区对宏的理解显然和最初的设计理念有偏差。因为Scala本身是没有传统意义的循环的（for-loop），所以很多时候循环必须利用while或者foreach。但是部分追求效率的Scala程序员们利用宏为Scala写了一个传统循环，叫做cfor，被收录在Spire（non/spire · GitHub）数学计算库中。cfor的写法如下：
import spire.syntax.cfor._// print numbers 1 through 10cfor(0)(_ <10, _ + 1) { i =>
println(i)}
而这玩意运行效率如何呢？文章中做了一次测评，将cfor和zip写的一个算法作比较——在公布结果之前，我想说的是，zip并不是一个高度优化的方法，所以本身就慢很多，cfor用了26.1毫秒运行，zip方法用了7.4 秒运行，这几乎是284倍的速度差距。
通过这两点，Scala的一个优势就很明显了——多样化。当需要写简单的代码，像Python一样当脚本语言使用时，Scala提供大量的原生方法和数据结构，可以很轻松的写出比较复杂的操作。但当需要速度的时候，又可以通过重构来获取数十倍或者上百倍的速度提升。通过Miniboxing一类的编译器增强器，Scala在某些操作的速度是必定超过Java的。
Scala的第二个优势就是——一帮勤劳勇敢的PhD博士生。二十一世纪的程序语言和二十世纪的程序语言已经不能比拟了。那个年代的普通人（甚至是学生）还能任意发明一下语言，稍微把编译器优化几次就能上得了厅堂（比如那一大堆Lisp方言），到了这个年代，编译技术已经达到了很复杂的程度（虚拟机技术也是如此），优化和语义理解，程序语言的定义与延展，再也不是随便任何人都能搞定的工作了。作为编程语言方面的教授，马丁·奥德斯基不断的将最前沿的学术界成果转移到Scala这个语言中，还让他的博士学生发展出新的，让语言运行得更快的方法，这些都是其他语言，尤其是Python、Ruby、甚至是Go都没有的优势。
当然，说了这么多，总会有人说了，Scala如果像C++一样难，又追求速度的话，为什么不直接去学C++，原因很简单——现在有很多在JVM上面写成的软件啊！大家又不是Haskell程序员，压根不打算一切自己写呐。
