PyTorch核心开发者灵魂发问：我们怎么就越来越像Julia了呢

PyTorch 社区最近有一种声音:下个版本应该抛弃 Python 改用 Julia 语言。

现在就连 PyTorch 团队内部也会拿这个说法来开玩笑。

对这个问题，核心开发成员中的 Edward Yang 在论坛上作出过一些回应。

他认为 PyTorch 的确越来越像 Julia 了，比如借鉴 Julia 的多重分派特性开发了 Pytorch Dispatcher。

PyTorch 总体的发展方向也和 Julia 的愿景一致，也就是同时具备拓展性，易用性和执行性能。

一方面 PyTorch 的底层代码后期用 C++ 重写以获得更好的性能，另一方面 functorch，fx 等新功能又让用户可以直接使用 Python 做以前必须借助 C++ 完成的工作。

那为什么不直接改用 Julia 呢。

害，其实是舍不得 Python 那无可替代的生态。

当初从原版 Torch 使用的 Lua 改用 Python 就是看中了生态这一点这么多年过去了其他语言生态连一点可能超过 Python 的迹象都没有

简而言之，Julia 语言本身的特性和 Python 的生态他们全都要，向 Julia 的优点学习也是团队未来的努力方向。

那么，Julia 这种语言到底好在哪，让 PyTorch 开发团队都向它学习。

面向科学计算设计的语言

Julia 来自麻省理工 CSAIL 实验室，设计初衷就是想要一个既有 C 的速度又有 Ruby 的动态性，既能像 Matlab 一样使用数学表达式又有 Python 的通用性。

Julia 要能像 Perl 一样自然地处理字符串，像 R 一样适用于统计，像 Shell 一样作为胶水语言去和其他语言交互。

要有 Hadoop 的并行计算能力，又不想要那些繁杂的配置。

最后做出来的 Julia 采用即时编译，速度比需要解释器的 Python 快得多，又没有失去交互性。

通过多重分派特性来实现类型稳定又不时脚本语言的简洁灵活。

同一个函数名对不同参数类型的调用分派不同的操作，因为适合处理多种数据类型还被 PyTorch 给学了去。

具体到机器学习来说，Julia 执行各类算法包括矩阵运算的速度都比 Python 快得多。

Julia 生态里也有自己的开源深度学习框架 Julia Flux。

此外 Julia 还在语法上对线性代数，数据处理这些场景有额外的优化。

比如支持 Unicode 数学符号，数字乘以变量时候可以省略「*」，以及索引从 1 而不是 0 开始更符合人类直觉….

Julia 代码可以写成这样:

α = 0.5 f = α*u，

以至于有些数学背景的开发者认为，Julia 代码写起来就像在黑板上做数学题一样的，很亲切。

相比之下，用 Python 做矩阵运算感觉就 不是那么好

Python:

np.dot

Julia:

array1.*array2

Julia 的历史可以追溯到 2009 年，由于想实现的功能太多，直到 2018 年才对外发布 1.0 正式版。

不过最近几年 Julia 已迅速被金融，医药，航天等一些行业接受，使用者包括摩根大通，辉瑞，NASA 等。

TIOBE 指数中的 Julia 流行趋势变化

Julia 改变了过去他们只能用 C 等高性能语言做底层开发，同时用高易用性的 Python 等语言做扩展开发的割裂问题。

今年 7 月，Julia 创始团队成立的公司 Julia Computing 还获得 2400 万美元的 A 轮融资。

Julia 语言速度快，天生适合机器学习又在高速成长，也难怪 PyTorch 社区会有用 Julia 替代 Python 的声音出现。

有人认为 Python 是一种糟糕的语言，虽然有优秀的生态，但生态中对机器学习最有价值的部分其实是用 C 实现的。

Python 生态虽然强大，但人们对其中的混乱也有不少诟病，各种重复开发的包管理系统让配置好 Python 开发环境都不是一件容易事。

相比之下，Julia 的包管理方案就很统一，虽然有可能是还在起步阶段没来得及混乱。

也有人认为 Python 这些所谓的缺点其实正是它流行的原因。

像 Python，Javascript 和 PHP 这种看起来糟糕的语言，正是因为能够轻松的编写糟糕代码，降低了门槛而流行。

这位要提醒大家 Julia 自身就带有和其他语言的交互功能，他平常会在 Julia 代码里调用 Huggingface 的 Python 模型作开发，两种生态都用上才是坠吼的。

最后，有人很不理解 PyTorch 开发团队不选择迁移到 Julia 的做法，既然 Julia 语言有所有他们需要的特性，还要花时间在 Python 里重新造轮子是自找麻烦。

另一位的视角有些微妙的不同:

这正是 PyTorch 团队想把方便留给用户，而把麻烦留给自己对这种态度我很感激

参考链接: