我认为关键在于是否开始为 Julia 开发库。看到玩具示例（即使它们是复杂的玩具）表明 Julia 在 R 不擅长的任务中将 R 从水中吹了出来，这一切都很好。

但是，糟糕的循环和手工编码的算法并不是我认识的许多使用 R 的人使用 R 的原因。他们使用它是因为对于几乎所有的统计任务，有人已经为它编写了 R 代码。R 既是编程语言又是统计包——目前 Julia 只是前者。

我认为它有可能到达那里，但是还有更多成熟的语言（Python）仍然在努力成为可用的统计工具包。

我同意很多其他评论。“希望”？当然。我认为 Julia 从 R 和 Python/NumPy/Pandas 以及其他系统多年来所做的对与错中学到了很多东西。如果我比我更聪明，并且想编写一种新的编程语言作为未来统计开发环境的基础，那么它看起来会非常像 Julia。

这就是说，事后看来，这个问题可能需要 5 年的时间才能得到回答。截至目前，Julia 缺乏可以与 R 竞争日常用户的统计编程系统的以下关键方面：

（列表随时间更新......）

• 可选排序因子类型
• 大多数统计测试和统计模型
• 识字编程/可重现分析支持
• R 级，甚至 Matlab 级绘图

为了与 R 竞争，Julia 和附加统计数据包需要足够干净和完整，以便聪明的非程序员，比如社会科学专业的研究生，可以合理地使用它。要到达那里需要做很多工作。也许它会发生，也许它会失败，也许其他东西（R 3.0？）会取代它。

更新：

Julia 现在支持缺少数据/NA、模块/命名空间、formula类型和model.matrix基础设施的 DataFrame、绘图（排序）、数据库支持（但还不支持 DataFrame）以及通过关键字传递参数。现在还有一个 IDE (Julia Studio)、Windows 支持、一些统计测试和一些日期/时间支持。

对我来说，数据分析语言的一件非常重要的事情是具有查询/关系代数功能，具有合理的默认值和面向交互的设计，理想情况下这应该是该语言的内置功能。IMO，我使用过的任何 FOSS 语言都没有有效地做到这一点，甚至 R 也没有。

data.frame 交互使用非常笨拙——例如，它在调用时打印整个数据结构，$语法很难以编程方式使用，查询需要冗余的自引用（即，DF[DF$x < 10]），连接和聚合很尴尬。Data.table 解决了大多数这些烦恼，但由于它不是核心实现的一部分，大多数 R 代码没有使用它的功能。

python 中的 Pandas 也有同样的错误。

这些抱怨可能看起来很挑剔，但这些错误会累积起来，最终总体上很重要，因为它们最终会花费大量时间。

我相信，如果 Julia 作为数据分析环境取得成功，就必须致力于在用户友好的表数据类型上实现 SQL 类型运算符（没有 SQL 语法的包袱）。

我可以按照 Dirk 和 EpiGrad 所说的签名；然而，还有一件事使 R 在其利基市场中成为一种独特的语言——面向数据的类型系统。

R 是专门为处理数据而设计的，这就是为什么它以向量为中心并具有诸如 data.frames、factors、NAs 和属性之类的东西。
另一方面，Julia 的类型是面向数值性能的，因此我们有标量、定义明确的存储模式、联合和结构。

这看起来可能是良性的，但每个曾经尝试使用 MATLAB 进行统计的人都知道这真的很痛苦。

所以，至少对我来说，Julia 不能提供任何我无法用几行 C 块解决的东西，并且会扼杀很多真正有用的表达能力。