根据查尔斯纳特的说法，杜比是
一种具有 Ruby 语法和 Java 类型系统的静态类型语言。Duby 支持所有 Ruby 的文字，使用本地类型推断（只有参数类型必须声明），并且运行速度与 Java 一样快（因为它产生几乎相同的字节码）。但随着 invokedynamic 的出现，杜比需要一个玩伴。
1.什么是invokedynamic，为什么Duby“需要一个玩伴”？
另一方面，Juby是
旨在基本上像 Duby，因为它使用 Java 的类型和 Ruby 的语法。但它利用了新的 invokedynamic 操作码 100% 动态。Juby 是一个动态的 Duby，或者可能是一个带有 Ruby 语法的动态 Java。这并不难理解。
其实很难理解。
2. 有人能详细说明一下这个区别是什么吗？
3. 为什么我们需要（需要！）另一种与 Ruby 相关的语言？或者，更确切地说，是另外两种与 Ruby 相关的语言？
我将不按顺序回答问题，从最简单的问题开始：
2. 有人能详细说明一下这个区别是什么吗？
Duby是静态类型的，Surinx（这是在短时间内称为Juby的最终名称）是动态类型的。这已经是它的全部了。
实际上，由此产生的一个小细节：Surinx语法是Ruby语法的严格子集，即每个语法上有效的Surinx程序也是语法上有效的Ruby程序。Duby OTOH几乎是一个语法子集，除了它的强制方法参数类型注释：
def foo(bar => Integer, baz => String) => Array
# ...
end
这在Ruby中是非法的。
3. 为什么我们需要（需要！）另一种与Ruby相关的语言？
首先：除了句法上的相似性之外，这些语言在任何方面、形状或形式上都与Ruby无关。
那么， Charles Oliver Nutter为什么要创建Duby呢？他是JRuby Ruby实现的首席开发人员，该实现是用于 JVM的Ruby 编程语言的实现。像大多数Ruby实现一样，它是用底层平台的主要编程语言编写的：MRI、YARV和tinyrb 100% 用 C 实现，MacRuby主要用 C 和一些 Objective-C、Ruby.NET和IronRuby 100% 用C 实现C#，ECMAScript中的HotRuby， ActionScript 中的Red Sun，红衣主教在 PIR 和 NQP 等。（唯一包含大量Ruby代码的 Ruby 实现是Rubinius （大约 70% Ruby，30% C++）和MagLev（未知数量的Ruby和Smalltalk）。）自然，XRuby和JRuby 100% 用 Java 实现。
现在，有趣的是，查理来到了Ruby，因为他不喜欢他的日常工作，做 Java 开发。而现在，他仍然整天写 Java 代码！当然，他不喜欢这样，所以他一直在寻找另一种编程语言来实现JRuby的核心。一种选择当然是全部用Ruby编写，但是对于元循环实现，通常会出现收益递减点，即实现退化为学术手淫。重写库、提前编译器（实际上，这已经完成）和一些核心类肯定是有意义的Ruby，但引擎核心的某些部分最好用更接近 JVM 本身的执行模型的方式编写。
Charlie正在研究可用的选项：Scala、Groovy、Fan、Clojure、Nice，但它们都有一个明显的缺点：相当大的语言运行时。JRuby运行时的大小在内存消耗和启动延迟方面已经是一个大问题（尤其是与MRI或YARV相比，如果您实际上将 JVM 本身包括在您的测量中，则更是如此），并用一种添加的语言重写它它自己的运行时间到那个重量是不可能的。不幸的是，没有一种编程语言可以满足查理的两个基本标准一直在寻找：没有运行时并编译为至少与等效 Java 一样高效的 JVM 字节码。
于是，他决定自己创作。他之所以选择使用类似于Ruby的语法，其实很简单：他不需要为它编写解析器，Duby只是使用JRuby已有的解析器，稍加修改即可支持方法参数类型注释。（其实他也喜欢Ruby的语法，这当然也是一个因素。）
如您所知，语法实际上是编程语言中最不重要的部分。（从争论的数量来看，它的不相关性并不总是很明显，但这只是因为语法是你唯一可以争论的东西，而不必真正理解你在说什么。）比语法更重要的是类型系统和评估语义。诀窍来了：杜比也没有！它只有语法！它就像一个寄生虫：它只是从其底层平台“借用”类型系统和语义。也就是说在JVM上，Duby的类型系统是Java类型系统，而Duby的语义是Java的语义。换句话说：Duby根本不是一种编程语言，它“只是”Java 的一种替代语法。
这意味着Duby和 Java 之间没有映射，没有转换开销，也没有速度差异。这意味着JRuby的内部可以用Duby编写，而不会丢失任何特性。
所以，这就是杜比。
为了解释Surinx，我将首先回答您的第一个问题：
1.什么是invokedynamic，为什么Duby “需要一个玩伴”？
invokedynamic特别是一个新的字节码，它将被添加到 JVM 规范的第 3 版中，并将在 JDK7 中发布。但是，更一般地invokedynamic，通常用作替代来指代一大堆功能，其中实际的 invokedynamic字节码只是其中一个，目前正在JSR-292“支持 Java 上的动态类型语言”的保护伞下开发平台”。更普遍的是，该名称invokedynamic被用作 Sun 和整个 JCP 战略的一般变化的绰号，以将 Java 平台转变为适用于各种语言的通用语言平台。
JSR-292的特定目的（查理在他的博客文章中提到的）是使动态方法分派更快——实际上，几乎与Java 中的静态分派一样快，至少在最好的情况下是这样。
Surinx是一种动态类型的编程语言，它基本上和 Duby 做同样的事情：像Duby一样，它也只有语法，像Duby一样，它也使用Java 类型系统。但与Duby不同的是，它没有使用Java 的方法调用语义，而是使用了方法调用语义。IOW：它是动态类型的并使用动态调度。 invokedynamic
所以，这就是Surinx。
现在，我可以回答你第三个问题的后半部分：
3. 为什么我们需要（需要！）[...] 两种与 Ruby 相关的语言？
我已经回答了Duby，这里是Surinx的答案：这就是Groovy 应该是的——一种用于 JVM 的轻量级（实际上是零权重）动态表达脚本语言。此外，它是目前玩弄invokedynamic. （目前JRuby 1.4的开发快照也支持它，但这是一个复杂得多的项目。）
我遗漏了两件事：Duby实际上使用局部变量类型推断，因此，与 Java 不同，您只需声明方法参数的类型，但方法内的所有内容都将进行类型推断。
其次，Duby和Surinx实际上都没有与 JVM 绑定。由于它们只是从底层平台窃取语义和类型系统，因此它们几乎可以移植到任何地方，在那里你可以粗略地映射从Ruby语法到平台概念。在我的脑海中，我可以想象Duby到 C、C++、Objective-C（iPhone，任何人？）、D、CLI和 ActionScript 的端口以及Surinx到DLR、Smalltalk、Parrot、ECMAScript、Python、Perl的端口, PHP和Objectice-C。事实上，Duby 的 C 端口已经开始了。
Mirah（以前的 Duby）存在，因为静态类型可以显着提高 Java/Hotspot 的性能。Surinx（以前称为 Juby）也是一样，除了它还利用 JDK7 中的新性能特性来进一步提高性能。
性能特性通常称为“invokedynamic”，Nutter 的博客上也提供了很好的解释。
刚刚从查尔斯本人那里遇到了这个问题，这部分解决了这个问题（re：它们之间的区别）：
这让我想到了 Surinx 的未来。它甚至比 Duby 的未来更简单：两者将合并。当我在 Surinx 和 Duby 上工作时，我发现它们本质上是同一种语言，具有不同的调度机制和类型声明要求。而且由于 Duby 可以轻松地将无类型或动态类型的表达式视为需要动态调用，因此没有理由不将 Surinx 同化为 Duby 的一个特性。
与语言一样，我们创建它们不是因为我们“需要”它们。人们出于任何原因创造它们，除非我们需要它们，否则它们仍然是模糊的。
那里有很多晦涩的语言。玩起来很有趣，但可能不是你想做一个真正的项目的东西。
我怀疑在某个时候，我可能能够在 Plain Ol' Dynamic Ruby 中对一段代码进行原型设计，并且当它可以工作但需要显着更快时，将其移植到一个密切相关的关系上，而痛苦程度相对较小编译为优化的 JITted Java 字节码。或者很可能 IronRuby#.NET、Sapphire或其他东西。
图形处理、重数学、人工智能，诸如此类。我怀疑我这样做会很有趣...