《人生苦短，我用Python》。这是Python开发领域广为流传的一句话。在过去的几年里，Python凭借其在易用性和生态性方面的优势，确实取得了长足的进步，在多项编程语言排行榜中位列前三。但随着Julia等新势力的崛起，这种情况正在发生改变。在前段时间发布的《StackOverflow2021全球开发者调查报告》中，Python仅被开发者排在第六位，而Julia则排在第五位。虽然在生态等方面还存在不足，但毫无疑问，Julia已经成为Python的有力竞争者，其竞争优势包括速度和简洁。在Julia中，我们可以获得类似C的性能和类似Python的优雅。最近，这种趋势甚至影响了主流深度学习框架的编程语言选择，比如PyTorch：“PyTorch往哪里去？为什么越来越像Julia，却又不太像？”这是PyTorch的核心开发人员EdwardZ。.杨参与讨论的一个问题。在问题下方，他回答说：我们曾经开玩笑说：下一个版本的PyTorch是用Julia编写的。放弃LuaTorch而主要使用Python编写的PyTorch的一个重要原因是利用Python庞大的生态系统。时至今日，一门新语言很难克服Python的网络效应。我们曾经开玩笑说：下一个版本的PyTorch将用Julia编写。放弃LuaTorch而主要使用Python编写的PyTorch的一个重要原因是利用Python庞大的生态系统。时至今日，一门新语言很难克服Python的网络效应。然而，最近，我一直在思考我们在PyTorch中开展的各种项目，包括：functorch：直接在Python中编写像vmap/grad这样的转换，以前只能作为调度程序的C++扩展；FX：graphtransformations，以前只能用C++TorchScript来完成；Pythonautograd实现：对autograd实现的实验性更改，以前仅在C++中可用。这些项目都有一个共同点：有些功能以前只能用C++实现，现在PyTorch让使用Python完成这些功能成为可能，提高了hackability，让开发变得更简单。PyTorch过去主要是用Python编写的，我们将所有内容都移到了C++上以使其运行得更快。因此，我们越来越希望在吃蛋糕（性能）的同时拥有这块蛋糕（可攻击性）。这与朱莉娅讲述了近十年的故事不谋而合。Julia的开发团队一直认为：一门语言必须能够编译成高效的代码，而Julia语言加入了一些限制（类型稳定性）来保证这一点；一种语言必须允许后续可扩展性（多分派，多分派），这是由围绕JIT编译的Julia语言组织生态系统实现的。以上两个属性的结合为用户提供了一个结合了动态语言的灵活性（可扩展性）和静态语言的性能（高效代码）的系统。其实这也是PyTorch一直在追求的。我们已经从Julia语言中汲取了很多灵感，例如ATEN的作者ZacharyDeVito将PyTorch调度程序中的多重调度的设计灵感归功于Julia。总的来说，我认为Julia可以作为一个非常强大的愿景，PyTorch本身也比Julia有一些优势。例如，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/276https://news.ycombinator.com/item?id=29354474【本文为专栏组织《机器之心》原译，微信公众号《机器之心（id：almosthuman2014）》]点此阅读作者更多好文
