耗时18个月,开发者用 Rust 重写系统后痛批:这门语言烂透了!

在近几年的 Stack Overflow 年度开发者调查报告中,有一门编程语言连续多年被评为“最受喜爱的编程语言”——那就是 Rust。

凭借其独特的安全性和与 C++ 不逞多让的性能,Rust 成为许多开发者想要尝试的语言,本文作者正是其中一位。而他在用 Rust 重写整个开源算法交易系统后,得出了一个不同于多数人的结论:Rust 这门语言,真的烂透了。

作者 | Austin Starks     编译 | 郑丽媛

出品 | 程序人生(ID:coder_life)

曾经,我是一个年轻而充满希望的 Rust 狂热者。因为我一直听说,Rust 完美得像是上帝设计的编程语言:不仅很快,还是最安全的编程语言之一。

如果在网上查找有关 Rust 的信息,你会发现认为 Rust 完美的人,远不止我一个:Medium 上的每一篇指南、Reddit 上的每一篇帖子、Stack Overflow 上的每一个答案……对 Rust 都是铺天盖地的正面评价。

有鉴于此,我决定放弃 TypeScript,用 Rust 来重写我的开源算法交易系统 NextTrade。

用 Rust 重写的好处是有,但代价巨大

起初,NextTrade 是用 TypeScript 构建的,以注重可维护性、可读性和可重用性。然而,当核心交易逻辑开始出现严重的性能问题时,为了构建一个可扩展至数万用户的纸面交易和回测平台,有必要进行全面重写。于是,Rust 成为了最热门的候选者,并在经过我的大量研究后最终胜出,成为进行全面重写 NextTrade 的编程语言。

前后花了 18 个月,最后的重写结果还不错。由 Rust 重写后的 NextTrade 变成了 NexusTrade,而 NexusTrade 在速度和可配置性方面明显优于重写之前:例如,在 NextTrade 上需要数秒才能完成的回溯测试,在 NexusTrade 上只需几百毫秒即可完成——这意味着性能提升了 1000 倍,平台也能支持更复杂的功能。

有这些好处固然很好,但我付出的巨大代价也不容忽视。

Rust 最大的优点,是完全消除了整类错误,而这同时也是它最大的弱点——借用检查器让这门语言变得异常困难,尤其是与 TypeScript 和 Go 这样的语言相比,入门门槛相当高。我根本无法像以前学习一门新语言那样边学边做,尤其是还要兼顾着一份全职工作:Rust 太难了!

说实话,如果 OpenAI 没有推出 ChatGPT,我真的可能会转而使用 Go。

所幸在 ChatGPT 的指导下,我克服了每一个障碍,深入了解了 Rust 的细微语法及其强大而复杂的类型系统。ChatGPT 就像一位经验丰富的 Rust 开发者在我身边,随时为我讲解生命周期的复杂性或匹配表达式的优雅性。

综合以上,我当时对 Rust 的评价是中等,也没有真正爱上这门语言,并基于以上经历写了一篇博文。没想到这篇文章在 Reddit 上遭到了许多抨击,其中还有一条高赞评论骂我用 ChatGPT 写文章。

看到这些评论后,我当时想着:可能是我还不够了解 Rust,对它的判断有失偏颇吧。

于是,在那之后我虽然没有多喜欢 Rust,但我还是坚持使用了一段时间。如今 4 个月过去了,我终于可以自信地得出一个结论:Rust 这门语言,真的烂透了。

可怕、冗长、不直观的语法和语义

在我看来,所有说 Rust 没有残暴语义的人都是在撒谎。在某些情况下,如果你无法使用极其强大的大型语言模型,那么编写函数简直就是不可能的事情。但我真的不想花 90 分钟来弄清函数中的子句,我只想写出一个想写的函数而已!

最后,我还不得不完全放弃辅助函数的想法,因为我真的无法让代码编译成功。人们所说的 Rust 最大的优点(严格的编译器可以消除错误),正是 Rust 最大的缺点之一。只要给我一个垃圾回收器,让我做我想做的事情就可以了!

相比之下,如果我用 Go 编写这个完全相同的函数,它看起来会是这样的:

虽然功能的核心相对不变,但这样你就不必翻来覆去地琢磨如何让代码正常运行了——它本身就能运行!

可怕的错误处理

Rust 确实能对错误进行很好的处理。只要避免出现不安全的错误,就能确保代码正常运行。NilPointerException 异常和未处理的错误再也不会发生了,对吧?

不对!因为当你的数据出错或发生意外情况时,你会拼命去弄清楚到底发生了什么。也许我是个白痴,不知道如何启用堆栈跟踪。但当我的应用程序出现一个错误时,我却不知道为什么!

(我的堆栈跟踪到底在哪里?)

相比之下,在 Python 这样的语言中,你会得到一些漂亮的、艺术般的堆栈跟踪,告诉你发生了什么,甚至精确到行号!即使在 Go 语言中,你也有 errors.Wrap(…) 这样的工具,能够让你查看整个应用程序的错误堆栈。或许我真是个笨蛋,只要我在 Rust 中遇到错误时,我就会陷入茫然,完全搞不清发生了什么。我需要在应用程序的各个地方都加上 eprintln!(…)。

事实上?不,我不是白痴。这就是一种有缺陷的语言设计。

Rust 社区

有一个热评是:Rust 社区并不像他们假装的那样友好和冷静。更具体来说,我认为他们是一群自恋的家伙,尤其讨厌别人说 Rust 有缺陷。

(有个 Rust 社区成员对我的问题给出了一个“有益的”建议)

例如,我在 Rust 的 subreddit 上问了一个关于如何改进 MongoDB Rust crate 错误处理的问题,得到的回答包括:

  • 改用 Postgres。(笑死,难道我要因为一些糟糕的错误信息就重新设计整个数据库吗?)
  • 你为什么要用 MongoDB?(我喜欢,下一个问题?)
  • MongoDB 在 Go 和 Python 中也很糟糕。(我不知道,但它在 TypeScript 中很好。你转移了话题并没有回答我的问题)
  • 出现一个真正有用的改进错误信息的建议。(非常罕见)

在我目前接触的所有编程社区中,没有一个像 Rust 这样像个邪教。他们无视 Rust 的所有明显缺陷,比如陡峭的学习曲线、冗长的代码、可怕的错误信息、复杂的语法和有争议的语言设计选择——他们把这一切问题,都归结于开发者自己的技能问题。在我看来,这简直是疯了!

总结

尽管如此,Rust 还是有一些优点的。它运行速度很快……嗯,这基本上就是它的主要优点了。

另外,它应该也很安全。如果我们把它和 C++ 比较,Rust 显然是更好的语言。但与其他语言(比如 Go)相比,Rust 的“安全性”对我来说更像是一种拖累。如果能把开发时间减半,那我宁愿应用程序的运行时间多加几十毫秒。

好的一面是,如果我选择用 Go 编写应用程序,我可能也会有些后悔。我会想:“如果 Rust 能更快呢?” “又有一篇文章说 Rust 是最棒的语言。天啊,我是不是选错了!”

至少,现在我学会了 Rust,我觉得自己可以学任何东西了。也许后面我会为了好玩去试试 OCaml,它总不会比 Rust 更难学吧?

本文文字及图片出自 CSDN

你也许感兴趣的:

共有 58 条讨论

  1. 我绝不是 Rust 的粉丝,但感觉这篇咆哮并不完全知情。比如

    > 只要给我一个垃圾回收器,让我做我想做的事!

    > 但与其他语言(如 Go)相比,它的 “安全性 “对我来说更像是一种损害。

    听起来作者并不清楚什么是 “内存安全”。很多语言都是内存安全的。不同之处在于,Rust 以零成本(实际上是 “非常低 “的成本)实现了内存安全。如果垃圾回收语言可以在不牺牲其简洁性的前提下做到这一点,那么它们就会这么做。

    这是一种权衡。如果你觉得 Kotlin 在性能方面没问题,那就用它吧!Rust 更像是 C/C++ 的替代品,因为性能很重要。如果你喜欢 Rust,可以在任何地方使用它,但如果你讨厌它,就不要在性能不重要的时候使用它!

    1. 问题出在 Rust 的营销上。他们把这种语言卖得太好,让它适用于那些不需要同等安全性或速度的用例,而 Java(或 Go,或 C#)会是更实用的选择。

      如果你正在编写操作系统或浏览器,Rust 会是一个不错的选择。基本上,C++ 可以替代任何其他语言。

      1. 我有一种模糊的直觉,之所以选择 Rust,是因为它支持高质量的抽象,而这正是现代语言所缺乏的。我一直在开玩笑,但不变性对于一般的软件开发来说非常重要。主流语言都不支持这一点,但 Rust 实现了同样的优势(即使方式不同)。Rust 的类型系统是健全的,而现代语言还在处理有问题的空值和缺乏高级类型(比如 typescript 可以做到的)。

      2. 100%.我担心的是,这种反弹会像炒作(关于 rust 最适合一切)那样传播开来,突然之间 rust 就成了无用之选。我的经验是非常积极的,但我的工作主要是在 Rust 所设计的 C、C++ 和系统领域的狭义情况下。

        1. > 我最担心的是,反弹会像炒作一样(关于 Rust 最适合一切的说法)传播开来,突然之间 Rust 就成了无用之选。

          我完全可以想象,在那些垃圾语言盛行的地方,它的受欢迎程度会下降,但是……难道你不认为它在那些需要 C/C++ 的地方(比如你提到的系统领域)会有前途吗?

          要想让 Rust 在所有地方都失利,就必须让 C++ 战胜 Rust。不知道这是否可能。

          1. 垃圾回收并不是唯一的优势。

            得益于和类型、枚举和 Rust 的其他特性,程序的直接正确性得到了大幅提高。

            这些都需要一定的前期成本。在使用 Rust 多年之后,我认为这些成本往往被夸大了。它们对新手的影响更大(这本身就是个问题!),尤其是那些不关心学习如何习语化编写新语言的人。尽管如此,从零开始到完全投入使用,通常至少要慢一点。

            不过,根据我的经验,Rust 程序所需的持续维护要少得多,而这正是软件开发中花费时间最多的地方。新功能的添加往往更加容易,而且类型系统可以完全避免各种类型的错误(不仅仅是内存安全问题)。即使是大型重构,通常也相对容易,而且一旦编译成功,很可能也能通过测试。

            在某些情况下,每延迟一天上线都是灾难性的。但当情况并非如此时,由于无需追查运行时错误、nil 取消引用、未处理异常、新枚举变体和部分处理枚举变体引起的问题等,所节省的时间最终会十倍地收回前期成本。

            前期成本确实会降低 Rust 在需求快速变化领域的竞争力。这是完全合理的,没有一种语言在所有方面都是完美的。但是,越是远离以销售为导向的用户,越是接近移动速度较慢的核心基础架构,降低的维护成本就越有回报。

            1. 在这方面,你将 Rust 与哪些语言进行比较?Swift?Kotlin?Go?

          2. 我认为下滑的程度会比人们预想的要深。回到非常小众的情况。事实上,Linux 和 Windows 正在使用越来越多的 Rust(尽管使用得很谨慎),我认为这将确保 Rust 在未来成为 C/C++ 的系统增强工具。

            大型 C/C++ 领域还没有真正采用 Rust,而我希望他们在此之前会采用 Rust:汽车、航空航天、机器人、桌面、嵌入式。对于其中的一些领域来说,它非常适合,但他们正在与没有生态系统支持的现任者作战,因此这需要很长的时间。这不像重写 sudo 或 ls,你必须重写一切才能从 C RTOS 转向 Rust 嵌入式 HAL。

            1. Rust 甚至还没有标准。C和C++(还有Ada!任何内存安全爱好者还记得Ada吗?

                1. 人们没有用它来建造东西。你做得越多,它就越受欢迎。

                  1. 我认识的目前用 Ada 制作东西的人比用 C 制作东西的人还多(从专业角度讲,因为我认识的几乎所有 Ada 开发人员都至少有一个 arduino)。

                    老实说,这与其说是语言的问题,不如说是我认识的人的问题。

                    1. 是啊,不幸的是,全世界都超级喜欢 c 和 c++,以至于花费了数十亿美元通过 frama-c、astree 和朋友们来提高其安全性,而不是资助真正安全的语言。

              1. 语言的 ISO 标准并不是必要条件,Rust 在这些行业,尤其是汽车行业正在取得进展。

          3. > 要想让 Rust 在所有领域都败下阵来,就必须让 C++ 战胜 Rust。不知道这是否可能。

            或者一种新的类 C 语言,比如 Zig。

      3. 没错。Go 在当时也是如此。他们的营销听起来就像其他人都做错了垃圾回收,而他们的方法最适合所有用例和利基市场。

    2. > 只要给我一个垃圾收集器,让我做我想做的事!

      这句话完美地说明了作者根本不知道自己在说什么。

      请作者注意:Rust 是专门为无法使用垃圾回收器的情况而设计的。

  2. > 是最安全的

    这似乎是一个严重的误解,基本上所有类型化的纯函数式语言都更安全:Haskell、SML、Ocaml 等。

    没有垃圾回收器也很安全,这就是它的核心优势。

    1. 我认为,当人们说最安全时,他们指的是最安全的 “类似 C 语言 “的零成本抽象语言。

      1. 我对此不以为然。我认为,很多人都是通过 Rust 才发现 “内存安全 “这一概念的,并认为只有 Rust 才能提供内存安全。祖父母说得没错:Rust 以低成本实现了内存安全,这才是关键所在。

      2. 是啊,但作者从 typescript 转到 Rust……他们还能指望什么呢。

        1. 讽刺的是,typecript(以及 Javascript)具有完全的内存安全性。当他改用 rust 时,segfaults 的变化才会增加。

  3. 从昨天开始,各种 reddits 上都在热烈讨论这篇文章。

    作者说

    > 我想尝试用煽动性的文体来写这篇文章,以吸引读者。

    但我还是想对一些说法做出回应,供好奇的人参考:

    > 只要给我一个垃圾收集器,让我做我想做的事!

    这绝对是一个合理的观点,但这意味着 Rust 并不是一个正确的选择。这并不意味着 Rust 是糟糕的。

    > 也许我只是个白痴,不知道如何启用堆栈跟踪。但当我的程序出现错误时,我却不知道为什么!

    Panics 有一个环境变量,可以设置为打印堆栈跟踪。您也可以使用 std::backtrace 中的工具自行获取堆栈跟踪,而且许多错误库(如 anyhow)也会让您获取回溯结果。不过,作者在这里感到痛苦的部分原因是,他们的示例代码没有直接使用错误对象,而是将其转换为字符串,然后以这种方式返回。这将使事情变得更难弄清,但这是因为你没有使用所提供的工具。

    1. 是的,但这种语言让人很难使用给出的工具。说这是技能问题很容易,说他们应该发现 RUST_BACKTRACE=1,但当你在学习语言并试图找出如何使用错误对象时,首先给出的工具不起作用,只是给我一个字符串,说我做了一个哑巴不应该这么难。

      1. 当遇到恐慌时,运行时输出会告诉您如何获取回溯:

            thread 'main' panicked at src/main.rs:3:7:
            called `Option::unwrap()` on a `None` value
            note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
        

        的确,rustc 和 clippy 都没有抱怨有一个 `Result<_, String>` 返回类型。也许他们应该这样做。实现这样的提示并不难,但我希望人们会因此而烦恼。

        我认为,在 18 个月内,我们有很多机会接触到任何解释这一点的文档和博文,或者在 https://users.rust-lang.org 上提问。

        我希望我们的工具链尽可能简单易用,成为同类产品中的佼佼者。我有一长串希望在 Rust 中得到改进的地方。文章中的批评既没有建设性,也没有实质内容。

        1. > 确实,rustc 和 clippy 都没有抱怨有一个 `Result<_, String>` 返回类型。

          我很想知道原作者是从哪里得到这个不幸的想法的。我从未见过有人这么做,而且通过将错误信息转换为字符串,它非常明确地丢弃了所有额外的错误信息。难怪你搞不清楚错误从何而来!

          1. 如果让我猜一个完全陌生的人,他们似乎是一个 printf 调试器。不瞒你说,我也是。但是,”我处理错误的方法是将它们打印到屏幕上,而你将字符串打印到屏幕上,所以字符串作为错误条件是有意义的”,这并不是一个巨大的飞跃。

            此外,他们似乎很喜欢 Go,而 Go 版本的 Rust Error 特质提供了一个返回字符串的方法 Error。虽然我没有写过有意义的 Go 语言,对它的习语也无从谈起(不过据我所知,”把它变成字符串就可以了 “并不是 Go 的习语),但这是另一个指向 “处理错误最简单的方法就是把它们变成字符串 “的信号,尤其是当你只是想发布一些东西而不关心细节的时候。

            1. > 虽然据我所知,”将其转化为字符串 “并不是围棋的惯用语)。

              遗憾的是,虽然我看到很多人争辩说这不是成语围棋,但我还没见过有几个项目不是简单地 “return nil, err”,因为任何给定项目中这样的行数多到令人难以忍受。

          2. 我无法引用我的资料来源,但我最近开始学习 Rust,并一直在做这件事。我猜我是从 Rust 书中学习的,因为那是我学习的主要来源。

            我知道我_可以_定义自己的错误类型,但这很乏味,尤其是在有许多错误类型需要处理的情况下。对我(非生产)来说,这很好。

            处理错误的惯用方法是什么?是否有办法在不使用过多模板的情况下收集更详细的错误信息?

            1. 常见的建议是 “在应用程序中使用 anyhow,在库中使用 thiserror”,但实际上,anyhow 适合处理错误,而 thiserror 适合定义自己的错误类型。

              文档中有很好的基本用法示例: https://docs.rs/anyhow/latest/anyhow/

        2. 我就直说了吧,Rust 社区并不是一个让人感到温暖的地方,你可以在这里问一些愚蠢的问题,然后走的时候不觉得自己是个傻逼。寄希望于人们会到正确的地方去问 Rust 问题是不切实际的。

          你无法控制 Stack Overflow 或 Reddit,也无法控制任意数量的 slack/discords,所以我不知道该如何解决这个问题,但这确实是事实。

          1. > 希望人们在正确的地方提出rust的问题是不可能的。

            https://users.rust-lang.org 由该项目主持。https://www.rust-lang.org/ 的页脚链接了该论坛,而 https://www.rust-lang.org/community 的链接更为显眼。搜索 “rust 论坛”,首先出现的就是它。

            Reddit 也有版主,但整个网站的文化问题以及 StackOverflow 的文化问题现在已众所周知。

            只要有可能,我都会尽力定下基调,以身作则。在我看到的大多数情况下,线程变坏通常是由于人们不愿意倾听,一开始就表现得很激烈。我曾在 r/rust 讨论中看到,所讨论的文章对语言/工具链的批评远比这篇要严厉得多,但交流风格和实质性分析却更有建设性。这种情况下的对话质量要好得多。

            请随时向我指出有毒的社区行为,我会尽我所能通过一切可用的方式来解决这些问题。我不能保证会有翻天覆地的变化,但我一定会尽我所能指出不良行为,并努力营造一个让我引以为豪的空间。话又说回来,我在你提到的任何一个网站上花费的时间都不多,所以我很容易错过不良行为。

            我还想说的是,即使你不想与人交流(无论出于什么原因),这也不能成为你不寻找官方或非官方文档的借口。https://www.rust-lang.org/learn 上有一个不全面的列表。

            OP 有可用的资源来学习如何以比他更习惯的方式处理错误:

            https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi

            https://doc.rust-lang.org/rust-by-example/error/multiple_err

            https://doc.rust-lang.org/rust-by-example/error/multiple_err

          2. 真的吗?我感觉 Rust 社区对新手比一般人更友好。并不是说平均水平很高,但还是有的。

      2. 我同意只说 “技能问题 “不是最好的办法,但同样,寻求帮助而不是写一篇博文说 “这是一个有缺陷的语言设计 “也是完全可以的。

        1. 我同意你的看法,作者应该为此付出代价。使用调试器可以解决这个问题,但有时调试器无法使用,而且以正确的方式传递 Result<Option <String>,Box<dyn Error>>(结果<选项<字符串>,方框<dyn 错误>>)或其他东西来处理错误是非常困难的。我最终还是想通了,但与 Python 相比,学习曲线还是很陡峭的。有些人可以胜任,有些人则不行。我个人认为这没什么,并不是所有东西都必须像 Python 一样简单。把关并不一定是坏事。现实的尴尬在于,并不是每个人都有那种推理能力来真正理解它,而因为他们不懂或无法理解它而把他们拒之门外并不一定是坏事。不过,当有人对此抱怨时,我们也不应该感到惊讶。

          1. 我确实认为 “项目不挑选优胜者 “的一个不幸的副作用是,让新人知道 “无论如何 “的存在肯定会有所帮助。这可以让最初的步骤变得更容易。

  4. 我用 Python 构建了一个算法交易平台,并使用 Cython 加速热点。无怨无悔。

  5. 我对生命周期注解很好奇。这基本上是语言设计者的意图,即 “在该数据字段上放置一个标记,以便编译器可以跟踪该字段的使用情况,确保在内存释放之前或之后不会访问该字段”。

    因此,生命周期是通过额外的抽象表达的,需要相关的语言语法、编译器设计、额外的规则集等。

    为什么同样的概念不能表达为自己的数据类型,然后作为数据传递呢?在这种情况下,你就去掉了额外的抽象。看来 Jai 正在走这条路,即传递一个竞技场类型实例并与之交互。

    1. 数据是在运行时产生的,而类型(也就是生命周期)是在编译时产生的。

      你可以去掉一个抽象概念,但也会失去效率。

  6. 我认为这里遗漏了一个可能相关的项目。它谈到了 Rust 的快速性。Rust 的编译速度可能相当慢。如果开发速度与此有关,那么 Rust 的 “快 “可能还不如编译速度快。当然,有些人不惜一切代价追求速度(并为此花费 18 个月重写代码)。Rust 可能很适合这种情况。

  7. 我不明白为什么要花这么长时间才能得出这些结论。如果它们对你造成困扰,每一个都会很快给你一记响亮的耳光,所以在决定它们是否值得一试之前投入这么多时间是很奇怪的。

  8. > 如果与 C++ 相比,显然它是更好的语言。

    这取决于 “更好 “的含义是什么。我喜欢 C++ 的地方在于它的问题是众所周知的,如何解决这些问题也是众所周知的。而 Rust 让我担心的是,在实践中我们并不了解它的所有问题。当然,我们最终会知道的。

    有时候,我觉得我们没有足够重视我们在一种语言上的集体经验有多重要。

    1. 我们意识到了 C++ 的问题,但如何解决其中的许多问题仍是一个悬而未决的难题(直到我们发现或发明出完美的人类)。

      1. 我们并不是没有解决方法,我们只是没有普遍接受和认同的解决方法。你有选择。例如,在 C++ 中就没有公认的手动内存管理解决方案。你可以开发自己的策略,但你可能无法在不创建垫片(或 monads)的情况下使用开箱即用的库,但问题是:我们知道如何做这些事情。生产中的大部分代码都已经完成了这些工作,很少有人有兴趣将这笔巨额投资重构为 Rust 代码。

  9. 我讨厌 Rust,但我认为这篇文章有失公允,因为作者搞错了预期。

    我的意思是,他把 rust 与 pythons 和 typescript 相提并论?

  10. > 只要给我一个垃圾回收器,让我做我想做的事!

    是的–这清楚地表明您还没有找到安全、保障和底层控制与开发人员速度之间的最佳应用。系统、安全关键型、嵌入式等。

    除了炒作和陷入分布式系统开发的空白之外,我不清楚它为什么会扩展到这一领域,而围棋出于某种原因从未填补过这一空白。

  11. 关于 Rust 社区不友好的评论(好吧,用词比这更严厉)可能是 Reddit 子站特有的。

    1. 如果有一个友好的 Rust 社区,请提供链接,否则我们只能认为它不存在。

      编辑:坎宁安法则:)

  12. 我以前用 C++ 编程,主要是做高性能方面的工作。和其他用过一段时间 C++ 的人一样,我对这种语言也有意见。以下是我不喜欢它的原因:

    1.编译时间。从点击 “编译 “到得到关于你犯了什么错误的反馈,这之间的时间从 <10 秒到 >30 秒,用户体验差别很大。

    超过 15-20 秒,我就会把注意力转移到其他事情上。这意味着当我读到错误信息时,我必须将上下文切换回任务。根据我的经验,快速构建(说实话,Go、D 甚至 Python)带来的生产力提升是巨大的。

    2.语法不好。很少有少于 70-90 个字符的有意义的代码行。你的眼睛会横着看,也会竖着看。因为是模板或语言的特殊性,你需要花费大量的时间去了解哪些内容可以跳过不读。

    3.构建 C++ 是个无稽之谈,每个人都有自己不同的解决方案,因此在项目中引入非头文件的外部库简直就是地狱。而只有头文件的库会让问题 1 变得更糟。

    C++ 不安全不是我的问题。Rust 专注于解决不安全问题,但 Rust 很少关注问题 1 和问题 2。他们确实解决了第 3 个问题,他们有一个包管理器,这很好,但其他语言也都这么做了,所以这对我来说并不是什么竞争优势。

    我严重怀疑,如果大多数人列出他们对语言的优先级,他们是否会与 Rust 保持一致。实际上,很少有人在编写可能会暴露危险内存错误的 Linux 内核代码或核心系统库。

    1. 关于 #1,在编写 Rust 时,可以考虑使用 cargo check 而不是 cargo build。它能在代码生成前的几个阶段停止,因此能更快地给你反馈。它对运行测试没有帮助,但会加快代码编译的周期。

    2. 我认为,如果能有一个资源,针对不同的用例,以平衡的方式对不同的编程语言进行这样的评估,将会非常有用。

      我能想到的唯一类似的东西就是 “你的编程语言糟透了 “的主题,这更像是一种幽默的夸张。

    1. 一样,然后他们又提供了一个 Go 的例子,……基本相同?然后他们抱怨 Rust 不提供错误的堆栈信息,但与此同时,Go 的等价实例只是在所有地方都 “return nil, err”,也丢弃了堆栈跟踪。

      他们正确地指出,在 Go 中你可以用 `errors.Wrap(…)` 封装错误。但在 Rust 中,你也可以使用 `std::backtrace`、`failure` 或 `anyhow` crate 做同样的事情。

    2. 是啊,我觉得他只是来自一个完全不同的操作领域。我甚至无法想象从 Typescript 到 C/C++/Rust 的转变。我甚至对 OP 能做到这一步感到佩服……

  13. 在无穷无尽的构建器模式和 let if/match 语法之间,相对于 C 或其他语言,它确实变得相当宽泛和丑陋。但它绝对有它的优点。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注