“ Julia”科学计算语言项目的成熟程度如何？

我正在考虑学习一种用于数值/模拟建模项目的新语言，以（部分）替代当前使用的C ++和Python。我遇到了朱莉娅，这听起来很完美。如果它能完成它声称的一切，我可以用它来代替C ++ 和在所有项目中 Python，因为它可以访问高级科学计算库代码（包括PyPlot），并且可以以与C相似的速度运行循环。我还将受益于其他语言中都不存在的诸如适当的协程之类的东西。

但是，这是一个相对较新的项目，当前版本为0.x，我发现各种警告（在过去的不同日期发布）表明它还不能为日常使用做好准备。因此，我想立即获得有关该项目状态的一些信息（2014年2月，或每当发布答案时），以帮助我评估我个人是否应考虑在此阶段花时间学习这种语言。

我希望您能获得有关朱莉娅项目具体相关事实的答案。 ; 我对基于其他项目经验的观点不感兴趣。

特别是，Geoff Oxberry的评论表明，Julia API仍处于不断变化的状态，需要在代码更改时对其进行更新。我想了解一下这种情况的程度：API的哪些区域是稳定的，哪些区域可能会发生变化？

我想通常我通常会做线性代数（例如，解决本征问题），对具有多个变量的ODE进行数值积分，使用PyPlot和/或OpenGL进行绘图以及低级C样式数字运算（例如，用于蒙特卡洛模拟） ）。朱莉娅的图书馆系统在这些领域是否得到充分发展？尤其是对于这些类型的活动，API或多或少是稳定的，还是我会发现我的旧代码在升级到新版本的Julia后会趋于破坏？

最后，在确定当前是否使用Julia进行认真的工作时，还有其他值得考虑的问题吗？

朱莉娅（此时，2019年5月，朱莉娅v1.1和v1.2即将问世）对于科学计算而言已经相当成熟。v1.0版本标志着年度代码破坏的终结。这样一来，许多科学计算库就有时间简单地成长而不会受到干扰。可以在pkg.julialang.org中找到Julia软件包的广泛概述。

对于核心科学计算，将DifferentialEquations.jl库微分方程（常微分方程，随机微分方程，泽斯，延迟微分方程，Gillespie的模拟等），Flux.jl用于神经网络，以及跳为数学规划（优化库：线性的，二次的，混合整数等编程）是科学计算生态系统的三个基石。尤其是微分方程库比您在其他语言中看到的要强大得多，拥有庞大的开发团队来实现诸如EPIRK积分器，Runge-Kutta-Nystrom，Stiff / Differential-Algebraic延迟微分方程和自适应时间刚性随机微分的功能方程积分器，以及其他许多优点，例如伴随灵敏度分析，化学反应DSL，无矩阵的Newton-Krylov和完全（无数据传输）GPU兼容性，以及神经微分方程的训练，所有这些出色的基准测试结果（免责声明：我是首席开发人员）。

关于成熟的Julia生态系统，令人难以置信的是它的可组合性。本质上，当有人构建像DifferentialEquations.jl中的泛型库函数时，您可以使用任何AbstractArray / Number类型即时生成新代码。因此，例如，有一个用于错误传播的库（Measurements.jl），当您将其粘贴在ODE求解器中时，它会自动编译ODE求解器的新版本，该版本无需参数采样即可进行错误传播。因此，您可能找不到记录在案的某些功能，因为这些功能的代码会自行生成，因此您需要更多地考虑库的组成。

合成最有用的方法之一是线性代数。例如，ODE求解器允许您指定jac_prototype，让您为其指定将在内部使用的Jacobian类型。当然还有东西在LineraAlgebra标准库一样Symmetric，并Tridiagonal可以用在这里，但鉴于composibility的类型泛型算法的效用，人们现在走了，并内置全阵列类型库。BandedMatrices.jl和BlockBandedMatrices.jl是定义具有快速lu重载的（块）带状矩阵类型的库，这使它们成为加速求解偏微分方程组的刚性MOL离散化的好方法。PDMats.jl允许指定正定矩阵。Elemental.jl允许您定义分布式稀疏雅可比行列式。CuArrays.jl在GPU上定义数组。等等。

这样便拥有了所有的数字类型。Unitful.jl在编译时进行单元检查，因此它是一个无开销的单元库。DoubleFloats.jl和Quadmath.jl和ArbFloats.jl一起是一个快速的高精度库。ForwardDiff.jl是使用双数算法的前向模式自动微分库。我可以继续列出这些。是的，您可以将它们放入足够通用的Julia库（如DifferentialEquations.jl）中，以编译专门针对这些数字类型优化的版本。甚至像ApproxFun.jl之类的东西它可以作为代数对象（例如Chebfun）使用此通用系统，从而可以将PDE指定为函数空间中标量上的ODE。

鉴于可组合性的优势以及可以使用类型在通用Julia函数上生成新的高效代码的方式，为将核心科学计算功能的实现转化为纯Julia进行了大量工作。Optim.jl用于非线性优化，NLsolve.jl用于求解非线性系统，IterativeSolvers.jl用于线性系统和本征系统的迭代求解器，BlackBoxOptim.jl用于黑盒优化，等等。甚至神经网络库Flux.jl也仅使用CuArrays。 jl自动将代码编译到GPU，以实现其GPU功能。这种可组合性是在DiffEqFlux.jl中创建诸如神经微分方程之类的事物的核心。诸如Turing.jl之类的概率编程语言现在也已经相当成熟，并使用了相同的基础工具。

由于Julia的库从根本上就是基于代码生成工具的，因此围绕代码生成有很多工具就不足为奇了。Julia的广播系统会动态生成融合内核，这些内核会因数组类型而过载，从而提供了上述许多功能。CUDAnative.jl允许将Julia代码编译为GPU内核。ModelingToolkit.jl自动将AST解糖到用于转换数学代码的符号系统中。盒式磁带使您可以“重叠”他人的现有功能，使用规则在编译之前更改其功能（例如：将其所有数组分配更改为静态数组分配，并将操作移至GPU）。这是更高级的工具（我不希望每个从事科学计算的人都可以直接控制编译器），但这就是构建许多下一代工具的方式（或者更确切地说，功能是如何编写的）。

至于并行性，我已经提到了GPU，Julia具有内置的多线程和分布式计算。Julia的多线程很快将使用并行任务运行时（PARTR）架构，该架构允许自动调度嵌套多线程。如果你想使用MPI，你可以只使用MPI.jl。然后，当然，最简单的方法就是使用AbstractArray类型设置在其操作中使用并行性。

Julia还拥有您期望的用于科学应用的通用语言的基本基础生态系统。它具有带有断点的内置调试器的Juno IDE，具有用于制作各种图的Plots.jl。许多特定的工具也很好用，例如Revise.jl在保存文件时自动更新您的功能/库。您拥有DataFrames.jl，统计资料库等。实际上，最好的库之一是Distributions.jl，它使您可以编写对该发行版通用的算法（例如：rand(dist)接受传入的任何随机分布的数字），并且存在单变量和多变量分布的全部负载（当然，调度是在编译时发生的，这与硬编码特定于该分布的函数的速度一样快）。您可以命名为一堆数据处理工具，Web服务器等。在这一点上，它已经足够成熟，如果有一个基本的科学知识并且您希望它存在，您只需使用.jl或Julia对其进行谷歌搜索，它就会显示出来。

然后，有几件事需要牢记。PackageCompiler希望从Julia库中生成二进制文件，它已经取得了一些成功，但还需要更多的开发。Makie.jl是一个具有交互性的GPU加速绘图的完整库，它仍然需要做更多的工作，但它确实希望成为Julia中的主要绘图库。Zygote.jl是一个源到源的自动差异库，它不存在基于跟踪的AD（Flux的Tracker，PyTorch，Jax）的性能问题，并且希望在所有纯Julia代码上运行。等等。

总而言之，您可以在许多地方找到很多活动，但是在大多数地区，已经有一个成熟的库。它不再是您问“会被采用吗？”的地方：Julia已经被足够多的人（数百万下载）采用，它有良好的发展动力。它有一个非常不错的社区，因此，如果您只是想轻轻松松地谈论并行计算或数值微分方程，那么Julialang Slack就是其中一些最好的聊天室。是否应该使用该语言是一个个人问题，是否适合您的项目使用的语言是一个技术问题，但这是不同的。但是，它是不是一种成熟的语言，并得到了一大批一致的开发人员的支持？这似乎是肯定的。

如果没有，是否可以给出一个粗略的数量级估计，以便在我再次考虑之前应该等待多长时间？

我对计算科学语言成熟需要多长时间的粗略数量级估计大约是十年。

示例1：SciPy始于2001年左右。在2009年，Scipy 0.7.0发布了，ODE集成器具有与VODE的接口（ode15s大致等效于；ode15s基于NDF，VODE取决于BDF / Adams-Bashforth）。使用SciPy 0.10.0（dopri5与MATLAB的接口大致相同）的接口ode45Runge-Kutta 4阶方法通常作为本科生的第一个实用数值积分方法引入。SciPy 0.10.0于2011年12月发布，他们花了大约10年的时间才将MATLAB的功能引入我所认识的每个工程学本科生。

例2：Mathworks成立于1984年。在他们的第一个版本中，他们使用了一个通向C的LAPACK端口，命名为JACKPAC（以编写它的MathWorks工程师Jack Little命名）。他们直到2000年才用LAPACK取代它。

朱莉娅可能会花更少的时间，但我估计从成立到成为主流大约需要10年。（已经过去一年左右了；那么可能是9-10年？）

朱莉娅的图书馆系统在这些领域是否得到充分发展？尤其是对于这些类型的活动，API或多或少是稳定的，还是我会发现我的旧代码在升级到新版本的Julia后会趋于破坏？

我不使用朱莉娅，所以我只说一句盐就可以了，因为我只看到杰夫·贝赞森（Jeff Bezanson）发表有关朱莉娅的演讲。他们向后弯腰以使其易于链接和使用C，Python和Fortran库。如果找不到能够满足您需求的Julia库，请使用一种更加完善的语言为该库编写Julia垫片。因此，我认为缺少库不会成为问题。我认为需要关注的是，确保对核心语言功能的更改不会对您造成伤害。如果查看一下Julia Git回购中的里程碑，您会发现使用了“ breaking”标记的次数很多（0.2版本中使用12次，0.3版本中使用5次）。对我来说，这表明核心语言仍在不断发展，这就是为什么我现在犹豫使用该语言。

编辑：Aurelius提出了一个好点：

是什么让您认为Julia会真正成为主流，而不仅仅是像许多其他语言那样默默无闻地消亡？SciPy / numpy拥有/拥有不断增长的python社区的支持，而Julia却没有。

在最初的答案中，我决定避免回答“朱莉娅会成功成为主流吗？”的问题。越多越好。失败很容易；成功很难。我认为Julia的最佳比较是与MATLAB，R和Octave等技术计算语言的比较。HPC语言（教堂，堡垒，UPC等）的受众比技术计算语言要窄，而通用语言（C，Python，C ++等）的受众比技术计算语言要广。

我认为对Julia有所帮助的是在不牺牲表现力的情况下设计性能。与MATLAB，R甚至Python相比，Julia在C之类的编译语言上更具竞争力。此设计目标也是一项可以从现有语言吸引人们的功能，例如：

• 谁很在意性能和来自像C和Fortran语言，但愿意牺牲一个人的微小的性能位（2ish的可能因素），从编译的语言去解释语言的较少行（连同REPL为更快速的开发和测试）。
• 那些关心高生产率的人来自Python，R和MATLAB之类的语言，但希望获得更高的性能。在执行方面，纯Python，纯MATLAB和纯R都很慢。这些语言的开发人员已经竭尽全力将库包装为已编译的语言，但是您无法包装所有内容，并且在某些时候，核心语言会降低您的速度。Julia Julia的速度更快，可让您更快地完成更多科学工作。
• 关心自由软件的人。Julia被解释并且是免费的（Python，Octave等也是如此）；MATLAB不是。

朱莉娅还试图促进并行性。我觉得在这一点上没有足够的扩展能力，我也不认为这是该语言的主要吸引力，但我认为这是他们正在努力的卖点，我希望其他人可以对此有所了解。

但是，即使具有技术优势，语言创建者也必须尽一切努力来推广该语言并传播福音。Jeff Bezanson，Alan Edelman，Stephen Karpinski和Viral Shah都在努力使该语言成功。艾伦·爱德曼（Alan Edelman）与计算科学界有着深厚的联系，他之前曾从事语言级项目（特别是对MATLAB的Star-P扩展）。杰夫·贝赞森（Jeff Bezanson）一直在进行会议巡回宣传，以将朱莉娅（Julia）提升为计算科学家和工程师。在麻省理工学院，他们一直在出色地招募学生和员工（特别是史蒂文·约翰逊），为朱莉娅添加图书馆做出了贡献。他们仅在一年后就在Wired上发表了一篇文章，并设法自己获得了Wikipedia文章。他们的Git仓库有数千个星星，数百个叉子，以及数百只手表，因此按照开源标准，他们的项目取得了成功。我认为到目前为止，他们已经做了所有正确的事情，因此，这是维持这种努力并建立社区的问题。他们仍然可能失败，但走到这一步对我而言意味着他们有一定的成功机会。

我相信茱莉亚值得学习。我用它来生成一些研究有限元代码，并很快地生成它们。我对自己的经历感到非常满意。

Julia为我启用了一个工作流，我发现使用其他语言很难做到这一点。您可以将其用作MATLAB之类的原型语言，但与MATLAB不同，当您拥有有效的代码并正在进行概要分析迭代以加快速度时，用C代码替换热点就很容易了。他们将与C（和Python）的接口作为设计的优先事项。

因此，该语言使我能够非常迅速地从数学公式过渡到功能代码，然后再从功能代码过渡到高性能代码。我认为茱莉亚（Julia）的这一功能不算什么，但它增加了巨大的价值。

在许多情况下，在生成功能有限元代码后的几个小时内，我就获得了C性能（与我自己的C代码相比）。到目前为止，如果我仅使用Julia功能，通常速度会比C慢3倍左右。之后，我用C函数替换了热点（Julia附带了堆栈采样探查器以帮助识别这些功能）。通常，这仅需要用“调用”替换有问题的热点代码行，而Julia可以处理任何编组。

我认为茱莉亚现在缺少的主要东西，尽管这让我犹豫不决，因为在大型项目中缺少完整的调试器以及对绘图的不良支持（现在，您在绘图中的最佳选择实际上只是matplotlib的接口）我经常休息的时间）。立即反馈代码非常重要。我也不知道如何在不进行交互式调试的情况下生存下来，在这一方面，我对MATLAB和GDB十分满意。

根据我的经验，Julia尚未准备好（科学）日常使用（我说的是2016年3月的稳定版本0.4）。语言本身很好，功能丰富且一致；matlab和python向前迈出了令人耳目一新的一步。在某些情况下，即使在这个早期阶段，Julia也是一个不错的选择。但是，如果您需要可靠且成熟的科学图书馆，我不建议立即采取行动。我遇到的主要问题是：

• Julia核心以外的软件包不可靠。它们会随着更新，更改，被替换而中断，有时是不完整的或只是被破坏了。
• Julia的并行性功能（最有希望的潜在Matlab杀手功能）是不成熟的。您将遇到分段错误，内存泄漏，崩溃和令人失望的性能。有时它们不能与julia的其他部分配合使用，例如线性系统的某些求解器或核心外部的程序包。这些功能听起来很有前途，但对于我来说，它们经常失败了。@parallel在理论上应该在for循环的前面简单地编写几乎几乎是不够的。
• 许多小事情，小错误和问题可能会存在：不太好，有时错误的调用堆栈跟踪，解释器历史记录有些错误，程序包加载缓慢，一个或另一个程序包/功能的性能不佳，等等。大多数是PyPlot程序包，它是matplotlib的包装程序，目前没有其他选择。它在那里并能正常工作真是太好了。但是，如果需要绘制数据，请为非常慢的性能和问题做好准备。

这一切都会好起来的。我相信，将来有一天julia在几乎所有方面都将优于matlab和python。很有可能为此开发创新的软件包。似乎已经有一个大社区。即使是现在，仍然有大量的软件包，用例范围从opencl到Web服务器。使用python或c库非常容易，因此就库可用性而言，您可能不会碰壁。Julia的强大优势在于它可以毫不费力地使用现代一致的高级语言将各种来源的高性能功能粘合在一起（请参见上面的答案）。但总体而言，我发现它既不成熟也不稳定，无法有效地使用。