为什么我不再推荐你用Julia？

从诞生之日起，不再Julia 已经走过了十多个年头。推荐

作为一个面向科学计算的不再高性能动态高级程序设计语言，Julia 在许多情况下拥有能与编译型语言相媲美的推荐性能，且足够灵活。不再

曾有开发者盛言赞美 Julia，推荐从速度、不再通用性、推荐多重派发等多个维度出发，不再认为 ​​Julia 甚至比 Python 更胜一筹​​。推荐

当然，不再也有人发现了 Julia 尚存在一些不足之处，推荐开发者 Yuri Vishnevsky 就写了一篇博客控诉 Julia，不再并表示自己在使用多年后，推荐已经正式停用了 Julia。不再

以下是博客内容：

多年来，我一直使用 Julia 语言来转换、清理、分析和可视化数据、进行统计和执行模拟。

我还发布了一些开源包，例如最近邻搜索等。但不久前我停止使用 Julia 了，我也不再推荐使用它，现在我来阐述一下原因。

根据我的经验，在我使用过的所有编程系统中，Julia 及其包的错误率最高，香港云服务器我来举例说明一下：

对概率密度进行采样会出现错误；对数组进行采样会产生有偏差的结果；乘积函数可能对 8 位、16 位和 32 位整数产生不正确的结果；将直方图拟合到 Float64 数组会出现错误；基本函数 sum!、prod!、any! 和 all!可能会返回不正确的结果。

还有一些开发者也提出了类似的问题：

OrderedDict 可能会损坏密钥；dayofquarter () 函数在闰年的情况下会出现错误；使用带有 error bar 的数字类型时，模拟结果不正确；stdout=IOStream 的 pipeline 乱序写入；由于某些 copyto! 方法不检查别名而产生错误的结果；if-else 控制流程存在 bug。

我经常会遇到这样严重的错误，足以让我质疑 Julia 中复杂计算的正确性，在尝试新的包或者函数的组合时尤其如此。

例如，我发现 Distance 包中的 Euclidean distance 不适用于 Unitful vector;还有人发现 Julia 运行外部命令的函数不适用于 substring，Julia 对缺失值的支持在某些情况下会破坏矩阵乘法，标准库的 @distributed 宏不适用于 OffsetArrays......

尤其是 OffsetArrays 被证明是 correctness bug 的重要来源。这个包提供了一种数组类型，源码库它利用 Julia 灵活的自定义索引功能来创建数组，而不必从 0 或 1 开始。

这可能会导致内存访问越界，如果你很幸运，将导致 segfault;如果不幸运，则会导致错误的结果。我曾经在 Julia 核心代码中发现一个 bug—— 即使用户和库作者都编写了正确的代码，它也可能导致内存访问越界。

我向 JuliaStats 组织提交了一些与索引相关的问题，该组织负责管理诸如 Distributions 之类的统计数据包和 StatsBase。我列出的问题包括：

存在 offset axes 的情况下，大多数采样方法都是不安全且不正确的；拟合 DiscreteUniform 分布会返回不正确的答案；counteq、countne、sql2dist、L2dist、L1dist、L1infdist、gkldiv、meanad、maxad、msd、rmsd 和 psnr 可能会返回带有 offset 索引的错误结果；@inbounds 的站群服务器不正确使用会导致统计数据计算错误；Colwise 和 pairwise 会返回不正确的 distance；offset 数组的权重向量访问内存越界。

这些问题背后的根本原因不单单是索引，还有当与 Julia 中的 @inbounds 一起使用时，就允许 Julia 从数组访问中删除边界检查。

function sum(A::AbstractArray)

r = zero(eltype(A))

for i in 1:length(A)

@inbounds r += A[i] # ←