「人生苦短，我用 Python。」这是 Python 开发领域广泛流传的一句话。在过去的几年中，Python 也的确凭借其在易用性、生态等方面的优势一路高歌猛进，在很多编程语言排行榜中稳居前三。
但伴随着 Julia 等新势力的崛起，这种局面正在发生变化。在前段时间出炉的「Stack Overflow 2021 全球开发者调查报告」中，Python 受开发者喜爱程度仅排第六，而 Julia 则排在了第五。虽然生态等方面依然存在不足，但毋庸置疑，Julia 已经成为 Python 有力的竞争对手，其竞争优势包括速度快、简洁等。在 Julia 中，我们可以用类似 Python 的优美语句获得类似 C 的性能。
最近，这种趋势甚至影响到了主流深度学习框架对编程语言的选择，比如 PyTorch：
「PyTorch 将走向何方?为什么它越来越像 Julia，但又不完全像?」这是 PyTorch 核心开发人员 Edward Z. Yang 参与讨论的一个问题。在这个问题下方，他回答道：
我们曾经开玩笑地说：下一个版本的 PyTorch 是用 Julia 编写的。之所以废弃了 Lua Torch 而主要使用 Python 编写的 PyTorch，一个重要的原因是想利用 Python 庞大的生态系统。直到今天，都很难有一种新语言能够克服 Python 的网络效应。
| 我们曾经开玩笑地说：下一个版本的 PyTorch 是用 Julia 编写的。之所以废弃了 Lua Torch 而主要使用 Python 编写的 PyTorch，一个重要的原因是想利用 Python 庞大的生态系统。直到今天，都很难有一种新语言能够克服 Python 的网络效应。
然而，最近我一直在思考我们在 PyTorch 中进行的各种项目，包括：
这些项目都有一个共同点：有些功能以前只能用 C++ 实现，而现在 PyTorch 使得用 Python 完成这些功能成为可能，提升了 hackability，并让开发变得更加简易。 PyTorch 以前主要是用 Python 编写的，后来我们将所有内容都移到了 C++，以使其运行得更快。因此，我们越来越多地处于这样一种情况：我们想要拥有这块蛋糕(hackability)，同时吃掉它(性能)。 这与 Julia 讲了近十年的故事不谋而合。Julia 的开发团队一直认为： 一种语言必须能被编译为高效的代码，Julia 语言添加了一些限制(类型稳定性)，以确保这一点;一种语言必须允许后续可扩展(多重派发，multiple dispatch)，Julia 语言围绕 JIT 编译组织生态系统使这一点成为可能。 上述两个特性的结合为用户提供了一个兼具动态语言灵活性(可扩展性)和静态语言性能(高效代码)的系统。 实际上这也是 PyTorch 一直追求的。我们已经从 Julia 语言中获得了很多灵感，例如 ATEN 的作者 Zachary DeVito 将 PyTorch 调度器中多重派发的设计灵感归功于 Julia。 总体来说，我认为 Julia 可以作为一个非常强大的愿景，并且相比于 Julia，PyTorch 本身也有一些优势。例如 Julia 经常称用户可以直接使用数学运算编写循环并将其编译为高效代码，而我们不需要尝试这样做，因为我们的内核非常复杂，在任何情况下都能实现最佳的低级别实现。 为什么不直接使用 Julia?因为我们既想要 Julia 的愿景，也想要 Python 强大的生态系统。这个方向具有巨大的潜力，但我们也有很多要做的工作和许多未解决的设计问题。我对接下来的发展感到非常兴奋。 |
从这份回答我们可以看出，PyTorch 逐渐靠近 Julia 已成定势，但鉴于 Python 在生态系统方面的绝对优势，下一代 PyTorch 不太可能直接用 Julia 编写。
对于这一做法，有人表示非常不理解。ta 认为，以 PyTorch 的生态号召力，如果下一版他们直接宣布用 Julia，那么生态问题很快就会迎刃而解。
而且，长远来看，转向 Julia 似乎收益更高。
但也有人认为，PyTorch 的这种做法其实是为用户着想，即把麻烦留给自己，把简单留给用户，这是一种非常值得肯定的态度。
如果你也是一位 PyTorch 用户，你会赞成哪种做法呢?
参考链接：
- https://dev-discuss.pytorch.org/t/where-we-are-headed-and-why-it-looks-a-lot-like-julia-but-not-exactly-like-julia/276
- https://news.ycombinator.com/item?id=29354474
【本文是51CTO专栏机构“机器之心”的原创译文，微信公众号“机器之心( id: almosthuman2014)”】
