山西营销型网站建设,中冠工程管理咨询有限公司,现在网站开发语言有,什么网站权威评价搜索引擎优劣近日#xff0c;由Yammer雇员Coda Hale发给Typesafe的Scala商业管理层的邮件通过YCombinator被泄漏出来并在GitHub上刊出。该邮件确认Yammer正在将其基础设施栈从Scala迁回至Java#xff0c;原因在于Scala的复杂性与性能问题。\u0026#xD;\nYammer的公关Shelley Risk向InfoQ证…近日由Yammer雇员Coda Hale发给Typesafe的Scala商业管理层的邮件通过YCombinator被泄漏出来并在GitHub上刊出。该邮件确认Yammer正在将其基础设施栈从Scala迁回至Java原因在于Scala的复杂性与性能问题。\u0026#xD;\nYammer的公关Shelley Risk向InfoQ证实该邮件只代表Coda Hale的个人意见而非Yammer的官方声明随后Coda Hale又在http://codahale.com/the-rest-of-the-story/上发表了一篇文章。在该文章中Coda澄清说这个消息是来自于Donald FischerTypesafe的CEO对早前一个tweet的回复。\u0026#xD;\n更新近日Yammer已经发布了声明宣布对该问题的立场声明证实了上述猜测。声明还指出任何语言都会有瑕疵不仅仅是Scala该邮件只不过是尝试提出一些建议以改进Scala的性能与其他问题。最后声明说到在构建任何高性能项目时Scala是其产品环境都有一些问题需要解决该邮件旨在帮助Scala不断改进。\u0026#xD;\n虽然Coda并未打算公开该邮件但他通过Gist后来被删除了将其放到了GitHub上以获得其他朋友的反馈然而邮件内容后来被共享出来并得到了大范围传播。\u0026#xD;\n回到2010年8月Coda在Yammer Engineering博客上说他们将要转向Scala。其目标是继续运行在JVM出于性能原因上这个转变的结果就是减少了约50%的代码\u0026#xD;\nArtie最初的原型采用Java编写但在一个周末的试验中我尝试使用Scala 2.8重新实现一次。一天后代码行数减少了约一半并添加了几个特性。我震惊了Java开发者很容易找但Scala团队却能完成更多工作\u0026#xD;\n一年过后这个决定发生了变化\u0026#xD;\n目前在Yammer我们正在将基础设施迁回至Java同时以遗留库的形式继续对Scala提供支持。这个过程并不是那么急我们刚刚开始但需要很长时间。本质在于使用Scala而非Java作为我们的默认语言所产生的摩擦和复杂性并未被足够的生产力提升或是维护工作的减少而抵消。我们或许还会在产品中使用Scala但主要的开发将会使用Java。\u0026#xD;\nStephen Colebourne近日发表了文章Is Scala the new EJB2对这封邮件做了点评其要点总结如下\u0026#xD;\n作为一门语言Scala中有很多颇具见地的想法。但它是门非常复杂的语言。\u0026#xD;\n 除了Scala所引入的概念与具体实现外要想编写地道的Scala还有一个文化的问题有时突然就蹦出来一个最佳实践完全不管不顾社区。\u0026#xD;\n 我当然知道学习以及教授Scala的困难程度与重要性。因为我们不可能在没人学习Scala的情况下找到人这个事实非常重要。\u0026#xD;\n 构建工具链导致开发很不舒服。这主要是因为SBT导致了Maven与Ant的边缘化——而他们是Java生态圈中的两个主要的构建工具。\u0026#xD;\n 每个主要的Scala发布都不兼容于之前的版本这导致Scala开发者总是在开发新的库并重新发明轮子。\u0026#xD;\n 借助于分析与检查字节码我们可以通过采用一些简单的规则实现100倍的改进\u0026#xD;\n 不要使用for循环\u0026#xD;\n 不要使用scala.collection.mutable\u0026#xD;\n 不要使用scala.collection.immutable\u0026#xD;\n 总是使用private[this]\u0026#xD;\n 不要使用闭包\u0026#xD;\n \u0026#xD;\n 我和开发团队讨论了这个问题迁回至Java并且演示了两个代码基结果是大家普遍同意进行切换。毫无疑问我们肯定对Scala的某些方面还不太熟悉但这不足以让我们还固守在Scala上。\u0026#xD;\n其中一些问题可能不太重要比如说一门语言越流行那么雇佣的开发者的经验就会越多其中一些是根据经验来测试的。比如说其中一条建议就是不要使用for循环。这可以通过如下代码进行测试\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nscala\u0026gt;\u0026#xD;\n var start System.currentTimeMillis();\u0026#xD;\n var total 0;for(i \u0026lt;- 0 until 100000) { total i };\u0026#xD;\n var end System.currentTimeMillis();\u0026#xD;\n println(end-start);\u0026#xD;\n println(total);\u0026#xD;\n114\u0026#xD;\nscala\u0026gt;\u0026#xD;\nscala\u0026lt; \u0026#xD;\n var start System.currentTimeMillis();\u0026#xD;\n var total 0;var i0;while(i \u0026lt; 100000) { ii1;total i };\u0026#xD;\n var end System.currentTimeMillis();\u0026#xD;\n println(end-start);\u0026#xD;\n println(total);\u0026#xD;\n8\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n这里使用for循环与\until\模式很多Scala程序员都习惯这么用要比对应的while循环慢很多虽然使用while循环的可读性差一些。同样循环的Java实现对于for和while来说都是2ms。\u0026#xD;\n我们做的另一个测试是通过从一个包含Integer对象的数据集合中加载来看看可变map的性能这可以在Java与Scala中进行对比装箱的损耗应该差不多。\u0026#xD;\n\u0026#xD;\n\u0026#xD;\nscala\u0026gt;\u0026#xD;\n val m new scala.collection.mutable.HashMap[Int,Int]; \u0026#xD;\n var i 0;\u0026#xD;\n var start System.currentTimeMillis();\u0026#xD;\n while(i\u0026lt;100000) { ii1;m.put(i,i);};\u0026#xD;\n var end System.currentTimeMillis();\u0026#xD;\n println(end-start);\u0026#xD;\n println(m.size)\u0026#xD;\n101\u0026#xD;\nscala\u0026gt;\u0026#xD;\n val m new java.util.HashMap[Int,Int]; \u0026#xD;\n var i 0;\u0026#xD;\n var start System.currentTimeMillis();\u0026#xD;\n while(i\u0026lt;100000) { ii1;m.put(i,i);};\u0026#xD;\n var end System.currentTimeMillis();\u0026#xD;\n println(end-start);\u0026#xD;\n println(m.size)\u0026#xD;\n28\u0026#xD;\nscala\u0026gt;\u0026#xD;\n val m new java.util.concurrent.ConcurrentHashMap[Int,Int]; \u0026#xD;\n var i 0;\u0026#xD;\n var start System.currentTimeMillis();\u0026#xD;\n while(i\u0026lt;100000) { ii1;m.put(i,i);};\u0026#xD;\n var end System.currentTimeMillis();\u0026#xD;\n println(end-start);\u0026#xD;\n println(m.size)\u0026#xD;\n55\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n与java.util.HashMap相比性能是相同的与java.util.concurrent.ConcurrentHashMap相比Java的速度要比Scala快一倍。Java集合类超越了Scala以上测试基于OSX JVM 1.6.0_29与Scala 2.9.1在文本撰写之际的最新版本。\u0026#xD;\n但遗憾的是在Scala库API中有很多Scala集合他们需要通过代码中的隐式转换从Java对象类型转换为Scala对象类型。出于性能原因这需要大量的重写。\u0026#xD;\n如果Scala编译器通过invokedynamic生成代码那么闭包lambdas的性能还会得到改进这是后续版本的Scala将会做的事情。此外在JDK 8中将会给Java带来native lambdas与method handles将会有很多的性能改进这些改进都可以为Scala所用。\u0026#xD;\n最后Scala在解决版本之间的不兼容问题上面临着越来越多的压力不仅仅是2.9.2与2.9.3之间的小改进。Typesafe并未发布Scala未来路线图的官方声明也没有说明何时才会有稳定的二进制版本能够实现不同版本之间代码的兼容。如果能够实现向后兼容那么就会有更多稳定的库出现并且会形成一个社区仓库这对未来有志于使用Scala的开发者将大有裨益。\u0026#xD;\n查看英文原文Yammer Moving from Scala to Java
