「我们已经从 Julia 中获得了很多灵感，但我们还是想要 Python。」
「人生苦短，我用 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 中进行的各种项目，包括：
functorch：直接用 Python 编写像 vmap/grad 这样的转换，以前只能作为调度程序的 C++ 扩展；FX：图形转换，以前只能借助 C++ TorchScript 完成；Python autograd implementation：对 autograd 实现做了实验性更改，以前只能用 C++ 进行。
这些项目都有一个共同点：有些功能以前只能用 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，那么生态问题很快就会迎刃而解。
但也有人认为，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/276https://news.ycombinator.com/item?id=29354474 
