Julia有什么不好地方?缺点是啥?- viralin

21-07-27 banq

这篇文章是关于 Julia 的所有主要缺点。其中一些只是对我特别不喜欢的事情的抱怨,这样的帖子必然是主观的。例如,有些人认为 Julia 缺乏 Java 风格的 OOP 是一个设计错误。我不知道,所以这篇文章不会涉及。Julia 是我最喜欢的编程语言。更重要的是,也许我是一个狂热的粉丝。

 

编译时间延迟

您了解 Julia 的第一件不好的事就是它没有响应。你打开你最喜欢的 IDE,启动一个 Julia REPL,开始输入......并在任何文本出现之前看到明显的延迟。就第一印象而言,这并不是很好,尤其是对于一种因其速度而受到吹捧的语言。

内部发生的事情是 Julia 正在编译其 REPL 所需的代码以及它与您的编辑器的集成。这种“运行时”编译会导致我们称之为编译时延迟的延迟。因此,如果我们在新的代码中提取从外部包效果更大:使用包一个小脚本BioSequences,并FASTX可能有2秒的延时,即使计算本身需要微秒。

它仍然可能变得更糟。在 Julian 中,延迟通常被称为 TTFP: Time To First Plot。图形绘图成为这个问题的典型代表,因为绘图涉及大量代码,但工作量相对较少。导入Plots和绘制最简单的线图需要 8 秒。

我听说过一些组织的代码库在 Julia 中,启动一个 Julia 进程并加载他们的包需要 5 分钟。

这个问题从根本上是无法解决的,因为它是在基本设计级别上内置到 Julia 中的。

  

内存消耗大

这个很容易证明:

$ /usr/bin/time -f "%M" julia hello_world.jl
Hello, world!
148724

一个 hello-world 脚本大约需要 150 MB 的内存消耗。Julia 的运行时间是巨大的——这些兆字节不仅被 Julias 编译器使用,而且它显然预先分配了 BLAS 缓冲区,以防万一用户想要在他们的 hello-world 脚本中乘以矩阵,你知道。忘记延迟吧,150 MB 的后台消耗完全排除了将 Julia 用于除了在 PC 或计算集群上运行的应用程序级程序之外的任何事情。对于其他任何东西,无论是移动、嵌入式、守护进程等,您都需要使用其他东西。

想想 Electron 因浪费资源而受到的所有仇恨。在这方面,每个Julia 程序都与 Electron 处于同一范围内。用 Julia 编写的命令行计算器比 2003 年的视频游戏“命令与征服:将军”消耗更多的内存。

 

Julia 无法轻松集成到其他语言中

Julia 庞大的运行时间的另一个后果是,从其他语言调用 Julia 变得很烦人。如果您的 Python 脚本需要依赖 Julia,则您需要预先支付:延迟和150 兆字节。

将其与 C 之类的静态语言进行比较,您可以将 C 库编译为其他程序只需调用的二进制文件。Julians 通常对 Julia 社区中大量的代码共享和代码重用感到非常自豪,但值得注意的是,这种共享在语言障碍上突然停止:我们可能能够在 Julia 中使用 Rust 库而不会产生摩擦,但是如果可以避免的话,没有人会使用 Julia 库。所以如果你想编写一些普遍使用的库,你最好使用静态语言。

 

弱静态分析

静态分析很有用。但是为了确保程序的正确性,无论如何您都需要测试,这些测试将捕获绝大多数编译时错误。你在动态语言中失去的小安全性不仅仅是由节省的时间弥补的,你可以用它来编写更好的测试。

当您可以安全地重构时,静态分析为大型项目提供的生产力靴子,因为如果您做错了什么,您会立即知道。

 Julia在静态分析和安全方面介于 Python 和 Rust 之间。您可以为函数添加类型注释,但错误仍然在运行时出现,Julia 的Linting静态分析正在慢慢出现和改进,但与 Rust 相比,它们只能捕获一小部分错误。在编写类型在运行时大部分时间不确定的通用包代码时,他们不能做太多的类型分析。

Julia 中静态分析的另一个问题是,有很多代码根本无法进行静态分析。根据静态分析器,您可以拥有一个 Julia 包,其动态样式会导致大量“问题”,但它仍然可以正常工作。如果您的包依赖于这样的包,您的静态分析将充斥着源自第三方代码的误报。

批评动态语言没有静态分析是否不公平?

 

核心语言不稳定

Julia 于 2018 年发布了 1.0,并且从那时起就一直致力于不破坏。那么我怎么能说语言不稳定呢?

不稳定不仅仅是破坏变化。它还与错误和不正确的文档有关。我在 1.0 之前就使用了 Julia,我经常遇到核心语言中的错误。不经常,但也许每两个月一次。我不记得曾经在 Python 中遇到过错误。

如果您对此表示怀疑,请查看标记为 bugs的未解决问题

我不认为这是因为 Julia 开发人员粗心,或者 Julia 没有经过很好的测试。这只是不断发现错误的问题,因为 Julia 是相对年轻的软件。随着 1.0 之后的成熟和稳定,错误数量已经下降,并且在未来还会继续下降。但在此之前,不要指望使用 Julia 时会有成熟、稳定的软件。

 

生态系统不成熟

Julia 作为一种年轻的、不成熟的语言的一个更重要的后果是包生态系统同样不成熟。与拥有大量用户和更多开发人员的核心语言相比,生态系统的建立速度更慢。

 

类型系统运行不佳

在 Julia 中,类型可以是抽象的或具体的。抽象类型被认为是“不完整的”。它们可以有子类型,但它们不能保存任何数据字段或被实例化 - 毕竟它们是不完整的。具体类型可以被实例化并且可能有数据,但不能被子类型化,因为它们是final最终的。

 

您不能使用数据扩展现有类型

在 Python 中,您不会遇到想要子类化但不能子类化的类型。你可以子类化任何你该死的东西。

 

抽象接口是非强制和不可发现的

.. 更多点击标题

 

子类型化是一种全有或全无的事情

....

 

迭代器协议太难用了

....

 

函数式编程原语没有很好的设计

直到我尝试了 Rust 和 Julia 的Transducers包,我才真正注意到这一点,它们都比 Julia 本身更好地实现了函数式编程的基础(我指的是映射、过滤器等)。

.....

更多点击标题

 

猜你喜欢