JuliaCon 2020刚刚结束，华沙经济学院的教授和DataFrames.jl项目的维护者Bogumił Kamiński总结了Julia语言的状态和生态系统，并宣称Julia终于已经达到生产环境就绪。
Kamiński教授的文章在Hacker News上引发了一些反响。有些评论者对Julia可视为生产环境就绪的通用语言提出了质疑，尤其是在文档、包、工具和支持方面。
InfoQ有幸与Kamiński教授进行了交流，以便于更好地理解他的观点。
InfoQ：您能描述一下自己的背景以及所参与的与Julia相关的工作吗？
Kamiński：我是波兰华沙经济学院的教授，主要从事运筹学和仿真建模方面的研究。
就提交的数量而言，我在Julia语言的贡献者中排名前5%，是Julia数据生态系统的重要贡献者，尤其值得一提的是，我还是DataFrames.jl的核心维护者。
在StackOverflow上，我是[julia]标签下排名第二的回答者。在全职转入学术界之前，我曾经管理数百人组成的开发人员和分析师团队超过十年的时间，为波兰最大的公司和机构部署BI/DWH/数据科学项目。
InfoQ：在文章中，您的主要观点是Julia生态环境已经达到了成熟的水平，可以投入生产环境了。您能进一步说明一下这一点吗？是什么阻碍了Julia在生产环境采用？移除这些障碍最重要的进展又是什么？
Kamiński：下面的这些定义对于我将Julia理解为生产环境就绪是至关重要的。
我将其定义为：具有达到稳定水平的语言和核心包，不会“每六个月”就发生重大变化。这意味着，在开始新项目的时候，我们可以放心地预期，在一个较长时间（几年）内所有的事情都会正常运行。
在过去，这是一个主要的问题。语言和核心包会非常频繁地变更其API，一年前创建的教程现在如果不进行更新的话就无法正常运行。对于正在开发中的语言和生态系统来讲，这是一种正常的状态。现在，我看到事情正在发生着明显的变化，尤其是核心Julia语言，但是类似的事情还在包生态系统中存在。
这并非意味着新的包没有处于“持续变化”的状态中，但这是在所有包生态系统中都能看到的现象，因为新事物总是变化得很快。
除此之外，包管理已经相当成熟，我要说在该领域它是目前最棒的。
这意味着付出了很大的努力使一切“正常运行”，尤其是对于包含二进制依赖的包。相反，在几年前，如果你安装一个包的话，它可能会因为一些外部依赖没有编译而失败。所以，我们必须要手动调整包的源码，这样才能使其正常运行，当然前提是知道该怎么做，这并不总是那么显而易见的。
尤其是，自从Julia 1.5以来，我们就有可能实现Julia无缝的企业级部署。在其之前，会出现一些问题，这是由于它所采用的用来同步GitHub的包管理协议经常会因为企业环境中的防火墙设置而崩溃。
为什么这很重要呢？我们可以很容易地“交付”一个Julia项目，并且预期任何环境中的任何人都能相对很容易地运行它。当然，会有一些极端情况导致无法正常运行，但是就我每天使用Linux和Windows 10的经验来说，在这两个平台上都能正常运行。
如果使用Julia编写项目的话，我们可以要么预期有一个包能够完成你想做的事情，要么可以使用C或Python编写代码并使其能够正常运行。在我们的博客文章中，我想要强调的是，我们已经达到了这种状态。以本周正在做的事情作为样例，Julia有一个非常棒的
LightGraphs.jl包，用来进行图处理，但是我的合作者使用Python并且更喜欢使用igraph。如下是一个使用igraph的样例（改编自igraph的Python教程）：import igraph as ig g = ig.Graph() g.add_vertices(3) g.add_edges([(0,1), (1,2)]) g.add_edges([(2, 0)]) g.add_vertices(3) g.add_edges([(2, 3), (3, 4), (4, 5), (5, 3)]) g.pagerank()现在，你可能想问同等功能的Julia代码怎么实现。如下所示：
using PyCall ig = pyimport("igraph") g = ig.Graph() g.add_vertices(3) g.add_edges([(0,1), (1,2)]) g.add_edges([(2, 0)]) g.add_vertices(3) g.add_edges([(2, 3), (3, 4), (4, 5), (5, 3)]) g.pagerank()正如我们所看到的，它是基本相同的。当然，并不是所有的场景都这么简单，比如，Julia和Python中的字典有不同的语法，但这是事物运行的通用规则。我们甚至可以使用tab补全和直接访问docstrings。
在实践中，这意味着什么呢？如果你正在做一个项目的话，那么你不会陷入这样的思考：“我可以使用Julia吗，在未来的三个月内，我可能在项目里会使用一些Julia还没有提供的东西？”但是，你应该知道，“我可以相对安全地使用Julia，因为目前很多通用的包已经就绪，而且即便是缺少了某些东西，我也可以通过其他语言来使用它，不管是C/Python/R，还是其他语言，这都不会太痛苦。”
另外，作为生产环境就绪的一部分就是
PackageCompiler.jl，借助它我们可以创建“一组文件所形成的应用，其中包含一个可执行文件，它可以发送到其他机器上并运行，在目标机器上并不需要安装Julia。”我认为它并非生产环境就绪的必备特性（很多被视为生产环境就绪的脚本语言都没有提供这样的选项），但是在很多场景下，具备这样的特性是很棒的。现在，我澄清一下，哪些是“生产环境就绪”定义中不应该包含的内容。我并不认为Julia是最适合任何项目的语言。每种语言都有其自己的定位，Julia的定位是高性能计算/数据科学（或者你所喜欢的称呼）。如果你希望获得一个占用空间非常小的二进制文件，那么Julia肯定不是首选的语言。如果你想为Android开发应用，那么Julia肯定也不是适合的语言。
我相信如果你想做一个Julia非常适用的项目，想要将其投入生产环境，很可能需要满足一些通用的需求。这些需求只是为了能够让你的核心特性能够与代码所部署的生态系统的其他部分能够很好地协作。而且，我相信Julia已经达到了一个很容易实现的成熟等级，不管是现有的包还是与外部工具集成，在Julia中都是非常简单的。
InfoQ：从Hacker News上的一些评论来看，您的声明似乎有些争议，尤其将Julia作为一种生成环境就绪的通用语言方面。您想补充一些其他的观点吗？
Kamiński：引用一下我在博客文章开头的地方所写的内容：
“迄今为止，我已经花了20年的时间在企业环境中部署与数据科学相关的项目（那时还不叫数据科学，但是我们已经在训练神经网络进行预测），我有很多同事都对企业级软件开发有很深的理解。”
这就是我这篇博客文章的框架，也就是从事数据科学，不是在“你的后花园”或“学术性研究实验室”，而是在“商业化环境”。正如我在前面所述，无论是我，还是Julia相关的任何开发人员，都不认为它是开发任何类型项目的“一站式方案”。
如果你看一下Julia开发者调查报告，在第28页，很明显，人们正在使用Julia进行计算，这是我相信Julia已经生产环境就绪的领域。
现在，关于像文档、包、工具和支持这些方面，当然这是应该进行改善的，并且我相信也将会得到改善。我同意像R/Python/Java这种更成熟的生态系统在这方面覆盖得更好。例如，作为
DataFrames.jl的维护者，我可以告诉你，最近大多数的PR都是文档相关的。但是，在这里我不会低估Julia社区。一般来讲，如果你有问题，并且发布到StackOverflow、Julia Discourse或Julia Slack上的话，通常几分钟之内就会得到答案，最多不超过几个小时。这里有一个这种情况的真实故事：人们通常对此反应很迅速，缺陷很快就能修复。如果让我指出Julia的一个主要的亮点的话，那就是在普通开发者社区中有足够熟练掌握该语言的人。我能理解产品负责人/项目经理的感受，那就是担心一旦开始使用Julia之后，面临找不到足够的人来完成项目的风险。但是，在这方面，我相信情况正在不断改善。JuliaCon 2020有超过两万人参加。另外，网上已经有很多免费的资源。
InfoQ：除了关注Julia是否已经生产环境就绪，或者它适用于哪些领域，在您看来，该语言的主要优势是什么？您认为它是Python、R或其他语言的替代方案吗，或者至少在科学计算和数据科学领域是这样的吗？
Kamiński：在这里，我觉得最好引用一下Julia开发人员调查的第8页到第11页。我主要讨论第8页中最重要的三件事：
速度：这方面相对比较简单直接。任何成熟的包，如TensorFlow或PyTorch，都需要高性能，它们大多数都是使用C++编写的。而Python只是对C++核心的一层薄薄的封装。现在，再看一下Flux.jl或Knet.jl，它们本质上是使用纯Julia实现的。因此，底线就是，如果你需要代码快速运行，并且想利用高级语言的优势的话，那么Julia是一个非常自然的选择。此外，如上所述，如果你想使用非常快的外部库的话，那么这相对是非常易于实现的。
易用性：它包含很多方面，但是根据我的经验，如果掌握了Julia原则，在进行数值计算的时候，与R/Python相比，它的语法和设计都很不错。Julia语言就是围绕支持这些任务而设计的。这不仅仅是语法的问题，它还可以是事情隐形发生，我们必须显式处理的一种可选方案（比如广播）。根据我的经验，这使得Julia代码易于维护，而且编写良好的代码在很大程度上本身就是文档化的。
代码开源且可修改：这方面有两个维度。首先，大多数的Julia包都是MIT协议的，在企业环境中，这通常是很受欢迎的。其次，大多数包都是使用Julia编写的，如果你不喜欢某些方面的话，可以自行修改（这比在R/Python中要容易得多，在这些语言中通常你需要修改的内容都是使用像C、C++、Fortran等语言编写的）。
人们通常会问我是否将Julia视为R/Python的替代方案。在这方面，我的想法是这样的：
如果正在进行需要高性能的复杂计算，那么我肯定会选择Julia作为工具完成项目中这部分功能的开发。
如果有一个非性能关键性的新任务，那么可以选择你最熟悉的任意语言（如果你在上述的第一点上做过很多工作的话，就像我这样，那么你可以安全地选择Julia）。
如果你有很多遗留的R/Python代码并且对此感觉还比较满意的话，那么可以继续坚持下去，并且要记住，如果在里面有一些性能关键性的内容的话，那么它们可以相对简单地采用Julia进行重写，然后与原有的代码库进行集成（我做过很多类似的项目）。
InfoQ：对于Julia的演化，您的观点是什么呢？
Kamiński：首先，我要说，我同意你在这个问题中所隐含的意思：这将是一个“演进”，而不是“革命”。Julia的设计已经被证明是健壮的，我不认为它会有颠覆性的变化，而是在很多领域会看到渐进式的改善。
如果具体说明几个主要的维度的话，那么将会是：
对多线程支持的改善。我认为这对Julia核心使用场景关系重大。Julia已经为此提供了支持，但是在这方面还有很多内容需要改善。与之类似，对GPU/TPU处理的改善也是值得期待的。
编译器延迟的改善。同样，随着每个版本的发布，它都在变得更好，但是这是每个人都觉得是必须要改善的地方。
提供更成熟的包管理生态系统。在这方面，我指的主要是包的质量、稳定性和文档化，就功能覆盖率而言，已经有成千上万的包可用了。强调一句，我相信许多核心包已经相当成熟，但是我同意人们的意见，应该在这方面进行改善。
社区的增长。我相信对Julia感兴趣的人正在显著增长，JuliaCon2020参与者数量的增加就说明了这一点。这意味着：a)如果需要的话，将来招聘高质量的Julia开发人员将变得更加容易；b)随着越来越多的人报告问题并参与进来，这会为Julia生态系统的质量创造一个正向的反馈循环。同时，作为DataFrames.jl的维护者，我注意到了这样一种转变，那就是从来没有参与过包“核心”开发的人正在提出issue/提交PR，并在社交媒体上讨论相关的功能。
原文链接：