clojure与java,关于性能和Java互操作性：Clojure与Scala

我已经阅读过Clojure与Scala的各种报道，而我发现两者都有自己的位置。有一些考虑因素我没有得到关于何时比较Clojure和Scala的完整解释：

1.)这两种语言中的哪一种通常更快？我意识到这会因语言功能而异，但对性能的一般评估会有所帮助。例如：我知道Python字典非常快。但总的来说，它是一种比Java慢得多的语言。我不想和Clojure一起走在路上遇到这个问题。

2.)与Java的互操作性如何？到目前为止我所读到的只是Scala具有本机集合类型，这使得与大型Java代码库集成有点笨拙，而Clojure遵循一种简单的以Iterable / Iterator为中心的方式来与Java类进行交互。还有更多想法/细节吗？

最终，如果它在clojure和scala之间足够接近，我可能会尝试它们。关于Clojure的一件事是语言看起来很简单。但话说回来，Scala有一个非常灵活的类型系统。但是，我知道Scala很快(基于多个个人帐户)。所以，如果Clojure明显变慢了：我想早点知道，而不是迟早。

使用Clojure 1.2 Clojure可以无需开销就可以调用java。 请看assembla.com/wiki/show/clojure/Datatypes和assembla.com/wiki/show/clojure/New_new。 这样做是因为Clojure希望接近Java但在Clojure中实现。

我认为任何一种语言对你来说都足够快。在比较Python和Java时，将语言归咎于速度差异似乎有点不合理。 Java是编译JIT(移动设备除外)，而Python则被解释。仅仅因为两者都使用字节码并不意味着实现甚至可以具有远程可比性能。但是Scala和Clojure都是JVM语言，因此它们应该具有相似的性能。

与Clojure相比，Scala具有一些实现优势，我期望性能更高一些。虽然Scala的静态类型通常会转化为速度优于Clojure的鸭子类型，但Clojure确实支持类型提示，这可以大大加快代码速度。可能普通的Scala比普通的Clojure更快，但你只需要优化瓶颈。大多数程序的运行时间是由少量的实际代码生成的。

关于使用Java的互操作，Scala更接近Java，但我确信两种语言的互操作性都很好。在编程Clojure中，Stuart Halloway写道："[你可以访问]从Java代码中可以获得的任何东西。"

由于Scala的作者Martin Odersky编写了Sun的Java编译器，我认为Scala方面也没有丢弃任何球。 :-)

你会很难选择两种更好的语言，尽管我也喜欢Ruby。你为什么担心要尝试哪一个？为什么不尝试两者？ Scala更有可能成为"下一个Java"，而很难想象Lisp将在50多年没有这样做之后终于起飞。但很明显Lisp处于自己独特的抽象层次，而Clojure相当简单，因此Scala + Clojure不会比(相当复杂的)Scala那么难，我相信你会很高兴你做到了它。

就此而言，他们可以互操作......

* dalvik(android的JVM)在2010年获得了2.2版本的JIT编译器

呵呵。好的，感谢所有的见解。起初，我处于这样的模式，我只想选择一个并运行它。但出于某种原因，我并没有想到我可以只使用它们并让它们相互操作。所以，也许我会选择两者并与他们一起快走:-)

而且我想补充一点，我确实对LISP有一点"情有独钟"，所以Clojure患有牙龈炎这一事实并不足以吓跑我。

在JVM中编写的语言将以最快的速度执行并不总是正确的。最初的JRuby具有糟糕的性能，因为它是一个编译为JVM的解释器，而不是源代码。这种语言也可能是罪魁祸首。静态类型语言通常比动态语言等更容易优化。

-1"Scala和Clojure都是JVM语言，因此它们应具有相似的性能"这绝对没有意义。需要与Java等静态语言保持互操作的动态语言总是要慢得多(重载成本很高，类型提示并不能解决所有问题等)

@julkiewicz - 动态语言总是慢得多，这根本不是真的。这取决于您的编译器是否可以在优化相关代码方面做得不错。例如，在Clojure中，您可以使用与Java性能完全匹配的Java原语进行算术运算。同样，在类型提示的Java对象上调用方法与Java对象方法调用一样快。 Clojure编译器基本上生成与javac相同的字节码，用于等效的Java代码。

-1"Scala和Clojure都是JVM语言，因此它们应具有相似的性能"这绝对没有意义。

@julkiewicz JIT已根据仅在运行时知道的信息进行优化，并在其假设发生变化时插入警卫。原则上没有理由说Python不能做同样的事情。动态语言需要更多分析，但一旦优化，它应该同样快。

使用现有的JVM Scala在静态类型的帐户上具有优势，因为JVM支持动态类型 - 反射 - 很慢。实际上，由于这个原因，必须通过相同的技术，结构类型实现一个Scala特性。

此外，Scala接受可变对象就好了，而且一些算法只需更快地实现可变性。

由于Scala和Java本质上都是基于类的语言，因此它们更容易互操作。或者，也许更无缝。 Java类是Scala的类，Scala类是Java的类。当谈到Scala的单身人士或Java的静态成员时，可能会出现问题，特别是当有一个框架涉及期望事物以某种方式工作时。

所以我会在这两个帐户上使用Scala。从很多方面来说，Clojure是一种更好的语言，它当然具有Scala上没有的(目前为止)非常有趣的功能，但是你可以通过完全功能获得这些好处。如果你打算这样做，那么Clojure很可能会更好。如果你不这样做，那么你应该继续使用Scala。

clojure的函数式编程功能是我考虑这种语言的最有说服力的原因。我正在达到这样的程度：如果我没有以功能方式编写代码 - 为什么我还要使用嵌入Java的脚本语言呢？我已经在我身边使用Python来完成快速而肮脏的任务。

然后去Clojure。

"Java中嵌入的脚本语言"。请说明理由。

@ Jus12证明什么？

@Daniel：很抱歉混淆。我的意思是对Ryan Delucchi的评论。他说Scala是一种"嵌入Java的脚本语言"，我不买。 (除非他的意思是Clojure，我不知道)。

@ Jus12我认为他将这些语言用作JVM脚本语言，并且考虑到这一点，除非他能够正常运行，否则他认为它们在Python上没有任何优势。然后，我不是他，所以我只能猜测。

请注意，Clojure和Scala是两种完全不同类型的编程语言 - Clojure是一种类似于Lisp的函数语言，它不是面向对象的。 Scala是一种面向对象的语言，具有函数式编程功能。

在我看来，语言的功能和概念(功能，OO，......)是选择语言的重要标准，而不是表现(该语言的特定实现)的表现 - 尽管我知道你没有希望陷入一种没有良好实施可用性的语言。

我会选择Scala，因为它是面向对象的，但也允许你学习函数式编程(如果你对此感兴趣)。另一方面，如果您不关心OO并且想要学习"纯粹的"函数式编程，请尝试使用Clojure。

显然你还没有使用过Clojure。 Clojure就像Scala是Functional一样面向对象。您可以实现接口，扩展类，声明私有和静态函数等(clojure.org/java_interop)。

Clojure中存在与Java的互操作性，但类和对象显然不是Clojure的主要特性。如果要在Clojure中编程，则不要以OO方式创建类和设计项目。

>>"比表演"。问题是：当项目深入时你会发现你的表现很差 - 而不仅仅是因为它只有一小部分(你已经计划将其转换为java用于那个非常重要的事情)。虽然我不打算在这里说"不要使用clojure - 期间......"但应该很清楚，在性能领域，clojure是一个更大的风险。应用程序级代码有很多机会无关紧要：但也有大量的框架/多线程/处理密集型代码库，这将是一种负担。

@javadba clojure对于低级多线程代码不好的想法似乎很随意。 Clojure的设计使得多线程编程错误很难实现。作为clojure语言核心的不可变数据和STM功能是核心Scala中不可用的，并且它们使得程序员不小心在其代码中意外地插入竞争条件或死锁的可能性更小。当然，这比您可能从Scala或Java等静态类型语言获得的运行时间更有价值。

"当然这比运行时间的几毫秒更有价值"......这取决于数据的规模。一些记录好几毫秒。乘以数亿......

惯用的Scala比惯用的Clojure更快，并且仍然如此。

Scala和Clojure都可以轻松地放在Java之上。两者都不好坐在它下面。

如果您的代码在时间要求严格或对空间至关重要，请坚持使用Java。但即便如此，它也不是。

计算机语言基准游戏对Clojure的真正资源成本几乎没有任何启示。没有采用Clojure数据结构。功能和序列抽象不会出现。

Clojure似乎很简单。它不是，但它富有表现力。它的运行速度可能比Java快五倍，但源的数量要小五倍(YMMV)。对于大多数应用程序来说，这是一个巨大的胜利。但是对于一些人而言，对于其他许多人来说，这是一种毁灭性的损失。

凭借Clojure语言的经验，我相信有可能事先告诉你的问题是否会完全切割成一个可以简洁而充分地(在性能方面)用Clojure表达的部分和需要用Java完成的部分。

你可以去Scala lite：在Scala中编写Java习语。你会获益的

一些简洁，一种在眼睛上更容易的语法，以及连贯的语法

虽然复杂的类型系统。

没有Clojure lite这样的东西：编写Java习语

Clojure完全没有意义。你得到的只是缓慢的Java，这很难

理解，因为它跨越了习惯用语

表达出来。

据说Scala是正确的Java。 Clojure与Java完全不同。你可能会说它是正确的Lisp - 一个大胆的，有些人会说荒谬，声称 - 这可能证明是真的。

这个答案很好地阐明了两者的真正差异和优势/劣势。它不是用scala-或clojure-apologist方式写的，而是用真实的方式写的。

"计算机语言基准游戏"产生的统计数据是您可能会找到的最佳数据。

它们很深入，您可以比较多种语言。问题是他们没有涵盖Clojure :(

也就是说，提交任何东西都很容易 - 它都是开源的。

统计数据确实说Scala非常快。

fyi shootout.alioth.debian.org/u32q/compare.php?lang=clojure

你去吧比Java慢2-25倍，内存和代码大小增加2-30倍通常比Java大。看起来它与Python相当，而Scala与Java非常接近。我说Scala是一个相当明显的赢家，Clojure明显更慢 - 除非Clojure测试写得不好。

似乎基准确实涵盖了Clojure(OP的评论是一年之久)。结果并不令人鼓舞。 Scala是要走的路。

上面的评论有点过时 - 截至2012年中期，Clojure已经大幅缩小了差距，现在平均只有约2倍的Java。

关于互操作性，我不能代表Clojure，但我希望它与Scala类似。

从Scala调用Java非常容易。

只要您将外部API与Scala和Java之间的公共点相符合，就可以轻松地从Java调用Scala。例如，Scala对象在某些方面用于Java中的静态方法，但它不是一回事。 Scala类可以编译为许多类，其名称在Java中看起来很有趣。

你不会想要混合搭配。在Scala或Clojure中构建使用大量Java库的组件是非常可行的。您当然可以从Java调用此组件，但您不想要做的是尝试使用Scala API以供Java中的Scala程序使用。

SVN声称"CVS做对了"。在我看来，Scala是Java完成的。

所以clojure是git？

@Ron哈哈，我的想法完全一样。

实际上Clojure的集合是git-ish

2010年11月的PragPub讨论了Clojure-Java互操作性。调用Java方法很简单，但扩展Java类/接口是完全不同的。

另一方面，Scala更接近Java。 Scala-Java互操作性在http://www.codecommit.com/blog/java/interop-between-java-and-scala中详细阐述

调用Java代码和扩展Java类/接口的方式与调用Scala代码的方式相同。一些痛点可能是处理Java泛型的一些边缘情况，因为Scala的类型系统比Java强得多。按照Java Bean约定创建getter和setter需要注释。

从Java调用Scala大部分时间都很简单，但是例如Scala的伴随对象需要知道如何将它们编译为字节码。使用来自Java的非抽象方法的特征也应该很复杂，并且调用具有特殊字符的方法将需要知道它们在字节码中的编码方式。

它现在(截至2010年5月)值得在Clojure的最新1.2分支中使用 - 这包括对原始类型和静态类型(通过各种类型提示和协议)的大量额外支持。

我的理解是，您可以在需要时使用这些功能，以获得与在纯Java中编写完全相同的代码相当的速度。

与此同时，即将推出的Scala 2.8中的@specialized技术正在为Scala库带来类似的改进。作为一种语言工具，它可用于所有代码，而不仅仅是标准库。