为什么我们没有选择Rust?


为什么我们没有选择Rust?文章插图
作者 | Paul Biggar
译者 | 弯月 , 责编 | 杨碧玉
头图 | CSDN 下载自东方 IC
出品 | CSDN(ID:CSDNnews)
以下为译文:
我们编写了一门语言 , 其中集合了编程语言、结构化编辑器以及基础设施等所有功能 , 我们的目标是将构建后端服务的难度降低100倍 。
我们的这门语言采用了F# , 很多人都对此表示很惊讶 , 包括我在内 。 多年来 , 我们一直在讨论如何使用 Rust 重写我们的代码 , 我们有一个用 Rust 编写的命令行工具和两个服务 , 所以我一直坚信我们会采用 Rust 。
为什么我们没有选择Rust?文章插图
为什么不选择Clojure / Haskell / Scala?常常有人问我们为什么不选择其他几种语言 , 所以我先来介绍一下我们将它们排除在外的原因 。
1、Clojure我有很多使用Clojure的经验 , 因为CircleCI几乎都是用Clojure编写的 。 但是 , 我们花费了大量时间来处理“意外情况” , 特别是“这个字段是什么类型?” , 以及遍布各处的 。 因此 , 我故意没有选择使用动态类型的语言 , 尽管Clojure是一门讨人喜爱的语言 。 此外 , 我们还可以避免Clojure社区对Rich Hickey(Clojure的作者)的崇拜 。 听完他的题为“Maybe Not”()的演讲后 , 我更加坚定地认为动态类型的水太深 , 而且我十分不同意对动态类型的看法 。
2、Haskell我曾经非常努力地尝试Haskell , 还曾尝试编写Haskell的解释器 , 但我还是不太喜欢这门编程语言 。 下列用户的留言说出了我的心声:
我认为 , Haskell 社区太过于学术化 。 最近 Haskell 库的邮件列表中有一篇帖子表示:
“在一次私人交流中 , 有人向我指出 , 元组函数\x->(x,x) 实际上是对双应用和一些相关结构进行单子形式的对角化的特殊情况 。 ”
这篇帖子收到了39条回复 。
3、Scala我没有使用Scala的经验 , 但是我感觉这门语言及其社区都是一团糟 。 所以我没有予以考虑 , 而且现在也不会 。
为什么我们没有选择Rust?文章插图
为什么没有选择Rust?首先 , 我来简要总结一下 , Rust的优势在于:

  • 优秀的工具
  • 优秀的库生态系统
  • 优秀的社区
  • 优秀的宏(尽管我感觉为了解决语言本身的问题 , 我有点过度使用宏)
Rust的缺点:
  • 需要自行管理内存
  • 模式匹配无法正常工作
  • 做事情的方式太多(Arc与Rc , 异步与同步 , 不同的stdlib)
  • 语言并非不可变
  • 无休止地与编译器作斗争
在做最终决定的时候 , 导致我没有选择Rust的主要因素包括:缺少GCP库 , 以及语言本身太接近底层 。
1、库Rust 有数不尽的库 , 而且运行良好 , 集成得也很好 。 Rust 拥有 Honeycomb、LaunchDarkly 以及 Rollbar 等第三方库 , 这些库对我们的服务来说非常重要 。 然而 , GCP 的库似乎非常草率 。 它是自动生成的 , 而且种种问题表明在这项技术上他们已经黔驴技穷 。 鉴于我们想要一个更加丰富的库生态系统 , 选择 Rust 似乎非常冒险 。
2、异步最近 , 我刚刚得到了 Rust 性能测试的同步版本 。 于是 , 我尝试将其异步化 。 然而 , 我却发现异步的难度太大了 。 显然 , 递归会导致异步的复杂度加剧 , 但最终导致我崩溃的是 Pinning 。
下面 , 我来介绍一下详情 。 在使用 tokio 运行时编写异步的多线程服务器时 , 你可以在线程之间移动异步进程 。 这意味着你可以复制内存 , 因此你需要 pin?算了 , 我只记得这么多 。 代码在这里() , 我相信有人能更好地解释这个问题 。
我曾努力尝试解决这个问题 , 但最后证明只是白白浪费时间 。 显然 , 这类的boxing和pining只能在没有GC的时候使用;在拥有GC的情况下 , 你根本不需要理会 。 而这就成了我的最后一根稻草 。
3、Rust是一种低级语言我正在实现的语言本质上就是F#/OCaml , 因此使用F#/OCaml实现理应更加容易 。 有人指出 , 我在尝试用Rust编写OCaml , 但Rust的设计初衷并非如此 , 我认为这话没错 。 Rust的语义简化了很多工作 , 但不适用于我的工作 。
我认为我们大多数人都不需要Rust 。 我认为Rust拥有一个很棒的社区、生态系统和许多工具 , 它包装的语言很好地解决了我们很少有人遇到的问题 。 虽然表面看起来非常出色 , 但实际编写代码的时候 , 你才能真实地体会 。