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页中最重要的三件事:
人们通常会问我是否将Julia视为R/Python的替代方案。在这方面,我的想法是这样的:
InfoQ:对于Julia的演化,您的观点是什么呢?
Kamiński:首先,我要说,我同意你在这个问题中所隐含的意思:这将是一个“演进”,而不是“革命”。Julia的设计已经被证明是健壮的,我不认为它会有颠覆性的变化,而是在很多领域会看到渐进式的改善。 如果具体说明几个主要的维度的话,那么将会是:
原文链接:
领取专属 10元无门槛券
私享最新 技术干货