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 本身更好地实现了函数式编程的基础(我指的是映射、过滤器等)。
.....
更多点击标题


 

猜你喜欢