我已经读过Clojure vs. Scala的各种论述，而我意识到两者都有自己的位置。关于将Clojure与Scala进行比较时，有一些注意事项尚未得到完整的解释：
1.）两种语言中哪一种通常更快？我意识到这从一种语言功能到另一种语言功能都会有所不同，但是对性能进行总体评估会有所帮助。例如：我知道Python字典的速度非常快。但作为一个整体，它是一个多比Java慢语。我不想和Clojure一起去解决这个问题。
2.）与Java的互操作性如何？到目前为止，我所读到的只是Scala具有本机集合类型，使其与大型Java代码库集成有点笨拙，而Clojure遵循一种简单的以Iterable / Iterator为中心的方式与Java类进行互操作。还有其他想法/细节吗？
最终，如果Clojure和Scala之间的距离足够近，我可能会同时尝试它们。关于Clojure的一件事是该语言看起来非常简单。但是话又说回来，Scala具有非常灵活的类型系统。但是，我知道Scala速度很快（基于多个个人帐户）。因此，如果Clojure的速度明显慢一些：我想早点知道。
Answers:
我认为这两种语言对您来说都足够快。在比较Python和Java时，将速度差异归咎于该语言似乎有点不合理。Java是经过编译的JIT（移动设备上除外），而Python是经过解释的。仅仅因为两者都使用字节码并不意味着实现将具有与远程相当的性能。但是Scala和Clojure都是JVM语言，因此它们应该具有相似的性能。
与Clojure相比，Scala具有一些实现上的优势，我希望它具有更高的性能。尽管Scala的静态类型通常会比Clojure的鸭子类型具有更快的速度，但是Clojure确实支持类型提示，这可以显着加快代码的速度。可能，普通的Scala比普通的Clojure快，但是您只需要优化瓶颈即可。程序的大部分运行时间是由少量实际代码生成的。
关于带有Java的互操作，Scala更接近Java，但是我确信两种语言都可以很好地互操作。在编程Clojure的斯图尔特哈洛韦写道：“[您可以访问]任何你能够从Java代码实现。 ”。
自从Scala的作者Martin Odersky编写了Sun的Java编译器以来，我还认为Scala方面也没有任何问题。:-)
您将很难选择两种更好的语言，尽管我也喜欢Ruby。您为什么担心尝试哪个？为什么不同时尝试它们呢？Scala更有可能成为“下一个Java”，尽管很难想象Lisp会在50多年后终于起飞。但是很明显，Lisp处于其自己独特的抽象水平，并且Clojure非常简单，因此Scala + Clojure不会比仅仅是（相当复杂的）Scala难得多，而且我敢肯定，您会感到高兴它。
为此，他们可以互操作...
* dalvik（Android的JVM）在2010年获得了2.2版的JIT编译器
在目前的JVM中，Scala在静态类型方面具有优势，因为JVM对动态类型（反射）的支持很慢。实际上，出于这个原因，经常警告人们必须通过相同的技术，结构类型来实现一个Scala功能。
而且，Scala可以很好地接受可变对象，并且某些算法通过可变性可以更快地实现。
由于Scala和Java本质上都是基于类的语言，因此它们更易于互操作。或者，也许更无缝地。Java类是Scala的类，而Scala类是Java的类。当涉及到Scala的单例或Java的静态成员时，可能会出现问题，尤其是当涉及到一个框架，期望事情以某种方式工作时，尤其如此。
所以我会在这两个帐户上都使用Scala 。Clojure在许多方面是一种更好的语言，它当然具有Scala到目前为止尚不存在的非常有趣的功能，但是您可以通过充分发挥功能来获得这些好处。如果您打算这样做，那么Clojure可能会更好。如果您不这样做，那么您可能应该留在Scala。
请注意，Clojure和Scala是两种完全不同的编程语言类型-Clojure是一种功能类似于Lisp的语言，它不是面向对象的。Scala是一种具有功能编程功能的面向对象语言。
我认为，语言的功能和概念（功能，面向对象...）是选择语言的重要标准，而不是性能（该语言的特定实现）的重要标准-尽管我知道您不会希望陷入一种没有良好执行的语言的困境。
我会选择Scala，因为它是面向对象的，但也允许您学习函数式编程（如果您对此感兴趣）。另一方面，如果您不关心OO，并且想学习“纯”函数式编程，请尝试使用Clojure。
如果您的代码始终是时间紧迫的或空间紧迫的，请坚持使用Java。但这不是，即使您认为是。
“计算机语言基准测试”对Clojure的真实资源成本影响不大。没有使用Clojure数据结构。功能和序列抽象不会出现。
Clojure看起来很简单。不是，但是富有表现力。它的运行速度可能比Java慢五倍，但源代码（YMMV）却小五倍。对于大多数应用程序而言，这是一个巨大的胜利。但是对于某些人以及许多其他人来说，这是毁灭性的损失。
凭借Clojure语言的经验，我相信可以提前告诉您问题是否会清楚地分解为可以用Clojure简洁而充分地（以性能术语表示）的部分，以及需要用Java完成的部分。
据说Scala做Java是对的。Clojure与Java完全不同。您可能会说Lisp做对了-一个大胆的说法，有些人会说荒谬的说法-事实可能如此。
“计算机语言基准游戏”产生的统计数据可能是您可能会发现的最佳数据。
它们是深入的，您可以比较多种语言。问题是他们没有涵盖Clojure :(
就是说，提交任何东西都很容易-全部都是开源的。
统计数据确实表明，Scala非常快。
关于互操作性，我不能代表Clojure，但我希望它与Scala处于类似情况。
从Scala调用Java非常容易。
只要使外部API符合Scala和Java之间的共同点，就可以轻松地从Java调用Scala。例如，Scala对象以某种方式使用，例如Java中的静态方法，但这不是一回事。Scala类可以编译为许多类，这些类的名称在Java中看起来很有趣。
您将不会想混搭太多。在Scala或Clojure中使用大量Java库构建组件非常可行。您当然可以从Java调用此组件，但您不想做的是尝试使用打算由Java的Scala程序使用的Scala API。
SVN声称“ CVS做对了”。在我看来，Scala是Java完成的。
该PragPub的2010年11月问题讨论的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的非抽象方法一起使用应该很复杂，并且调用带有特殊字符的方法将需要知道字节码中的编码方式。