例如，我遇到了害怕Rails应用程序死亡的开发人员和架构师，但他喜欢编写新的Grails应用程序的想法。
从我所看到的，使用JVM来支持Groovy，JRuby和Jython等语言而不是直接的Ruby或Python有很多资源开销。
Ruby和Python都可以在任何操作系统上进行解释，所以我没有看到任何“一次写入运行”的优势......为什么要把笨重的JVM与你一起带来？
答案 0 :(得分：29)
Java是一个更加成熟的平台，有许多现有的类库可以“放入”并使用，比如Ruby或Python（甚至是Perl）。因此，对于喜欢使用现有代码而不是自己编写所有内容的人来说，Java是一个巨大的胜利。
例如，最近我一直在寻找类似JAXB for Python或Ruby的东西。最后，我最终使用JRuby只是因为我没有找到任何成熟的，广泛使用的XML绑定库。
答案 1 :(得分：14)
为JVM编写代码（使用任何语言）的巨大优势在于，如果有必要，通常可以很容易地利用大量成熟的Java库。
我不知道你在哪里得到了一个“笨重”的JVM，其资源开销很大。 JIT倾向于生成非常快的代码，而核心JVM在今天的标准中是巨大的。它在运行时往往会占用大量内存，但这是因为现代机器具有大量RAM，并且当GC具有大量RAM时，GC效果最佳。如果需要，GC可以fine-tuned to hell and back更加保守。
正如其他人所说的那样：“Groovy的最大优点是我不会必须使用Java。关于Groovy的第二个最好的事情是我可以使用Java“。
答案 2 :(得分：9)
似乎问题中的一个假设是新项目是greenfield projects。在过去十年中，许多组织已经对Java进行了大量投资，并要求任何新项目在现有（内部）代码生态系统中工作。正如所指出的，在所有公开的Java库（无论是免费/ OSS还是商业）中都有巨大的优势，但是使用现有代码甚至作为现有系统中的组件的需求至少同样重要（如果不是更多）所以对大型组织来说。
很多也归结为平台的成熟度和功能，即JVM及其随附的所有内容（整个Java生态系统）。我脑子里有几个例子：
您可以将远程调试器插入正在运行的JVM中，并获取有关正在运行的应用程序的各种信息，这些信息对于Python，Ruby等来说根本不可能。更进一步，有JMX，编写代码的标准方法，以便可以在实时应用程序中监视甚至调整对象。看看JConsole，看看你是否只是流口水（尽管界面很丑陋）。
在这方面更进一步，有OSGi，这是编写高度模块化代码的标准，可以在实时应用程序中进行部署，启动，停止甚至升级。使用OSGi，您可以将大型应用程序分解为许多较小的“捆绑包”，然后可以单独维护（部署，启动/停止，升级）。这在大型应用程序或任何需要始终保持运行的应用程序中都是非常重要的。
该平台具有非常对异步，可靠消息传递的良好支持。你得到JMS作为基线，并且使用很少的代码来构建许多优秀且功能强大的库，用于执行复杂的事情（参见Apache Camel，ServiceMix，Mule和很多其他的）。这是另一个在大型应用程序或必须在更大代码范围内运行的应用程序中极具价值的功能。
JVM具有真实（OS级）线程，而Python等人。 非常在这方面受到限制（众所周知）。 （话虽如此，共享状态并发 - 线程化 - 是错误的方法;参见Erlang，Alice，Mozart/Oz等。
除了标准的Sun实现之外，还有许多JVM选择，例如JRockit，IBM的JVM等。这是一个包含其他语言的开发领域 - Python有Jython，Iron Python，甚至PyPy和Stackless ; Ruby有JRuby，Rubinius和others - 但是这些都与它们在各种JVM产品中找到的成熟度不相符。
所有这一切，我真的不喜欢Java 语言并尽可能地避免它。这些天，我不需要JVM的所有优秀替代语言。 Groovy对其可访问性和与平台（甚至是语言）的紧密集成进行了投票，并且因为Grails，我有时将其称为“Rails for grownups”。我更喜欢其他JVM语言，特别是Clojure和Scala，但普通程序员无法访问这些语言。 Scala最近出现了很多，特别是感谢high profile use at Twitter，所以希望有更好的语言和真正优秀的语言在更大的环境中使用。但这是另一个话题。
答案 3 :(得分：7)
为什么要把笨重的JVM和你一起带来？
JVM不会膨胀，也不会变慢。相反，它是一个精简，快速，深度优化的虚拟机。不幸的是，它针对静态OOP语言进行了优化。
但是，针对JVM的优秀编译器确实可以创建性能良好的程序。我不知道JRuby;但是Jython的目标是比普通的C Python更全面，并且它们越来越接近（在几个重要的用例中它已经更快）。
请记住，一个好的JIT（比如JVM的JIT）可以在静态C编译器上应用一些不可用的优化，从中获取更快的代码并不是一个梦想。当然，针对您的语言优化的VM应该比像JVM这样的“非真正通用”VM更快;但是存在成熟度问题：JVM在那里完成了很多的工作，而Ruby和Python的JIT并不在附近。
不幸的是，似乎没有更好的通用字节码VM。微软的CLI受到与JVM类似的限制（ironPython比JPython慢得多，重得多）。最好的候选人似乎是LLVM。有人知道为什么没有比LLVM更多的动态语言？我见过几个Scheme编译器，但似乎有几个问题。
答案 4 :(得分：4)
Groovy不是一种解释型语言，它是一种动态语言。 groovy编译器生成JVM字节码，它在JVM中运行，就像任何其他java类一样。从这个意义上说，groovy就像java一样，只是为java语言添加语法，这只对开发人员而不是JVM有意义。
开发人员的工作效率，语法的简易性和灵活性使得groovy对java生态系统具有吸引力 - 如果它们导致java字节码（参见jython），那么ruby或python会很有吸引力。
Java开发人员并不害怕ruby;事实上很多人很快就接受了ruby和python的groovy或jython。他们不关心的是留下这样一个令人惊叹的平台（java），用于性能较低，可扩展性较低甚至不太常用的语言，如ruby（尽管有其优点）。
答案 5 :(得分：3)
RoR的一大打击是它不可扩展且难以部署。通过使用Java平台，您可以利用现有的基础架构。
grails war
生成一个可轻松部署在Glassfish，Jboss等上的war文件。
答案 6 :(得分：3)
Ruby和Python都可以 解释几乎任何操作系统，所以我 没有看到任何“写一次运行 任何地方“优势......为什么要带来 笨重的JVM和你？
主要是因为您希望利用巨大的现有Java库，API和产品生态系统，这使得Ruby或Python可用的任何东西相形见绌，尤其是在企业域中。
另外，请记住，JRuby和Jython在许多基准测试中更快，而不是语言的常规（C实现），尤其是Ruby（甚至是Ruby 1.9）。
将多种语言定位到同一个虚拟机有很多好处，例如利用通用基础架构，代码重用，共享API，使用任何语言的能力在概念上最适合您，或针对特定问题域等
在.NET空间中发生同样的事情，multiple languages针对CLR。 Parrot（蒸发器）VM项目的目标也是同样的，它也是LLVM项目的既定目标。
答案 7 :(得分：2)
原因是Hotspot。
这是一次工程巡回演出。
答案 8 :(得分：1)
提及的另一个原因是与jvm相关的现有基础架构 - 如果您已经有一个运行Java的服务器，为什么不使用它而不是引入另一个平台（如rails）？
答案 9 :(得分：1)
我遇到了这个并且也被它困惑了，这是我的理论。
企业软件充满了Java程序员。像各种程序员一样，许多Java程序员确信他们的语言是最快，最灵活和最容易使用的 - 他们对其他语言并不太熟悉，但他们确信那些练习它们的人必须是野人和野蛮人，因为任何开明的人当然会使用Java。
这些人构建了庞大而复杂的Java基础架构：rube-goldberg框架机器和自动生成的代码，其中包含拜占庭式继承结构和非常大的XML文件。
所以，当有人出现并说“嘿！让我们使用C语言解释！它速度快，编写简洁，脚本和原型制作速度更快！” Java家伙首先喜欢“我必须运行一个make文件来配置它？QUEL HORREUR！”然后，必须在运行日期操作系统和日期版本的Tomcat的服务器上部署和托管这一事实，而其他任何事情都没有开始。
“嘿，我知道！这个解释语言的java版本！它可能会在高峰时段在桥上的快车道上发生故障，它有时会着火，但我可以让Tomcat运行它。我不需要学习非Java东西弄脏我的手，我可以把它塞进现有的基础设施中！赢！“
那么，这是选择脚本语言的java实现的“正确”原因吗？可能不是。取决于您对“权利”的定义。但是，我怀疑这就是他们被选中的原因比我想要相信的势利者更频繁。