rust 前景

[Mivon]

最近无聊学了下 rust，发现包管理真的很棒，就是语法晦涩了点，不知道国内有没有公司已经开始用了？

[tianshilei1992]

Rust 的 compiler 现在可以直接 emit LLVM IR 了，LLVM 那些 optimization 都可以用起来了，感觉还是很有前途的。

[cmdOptionKana]

其实语法并不晦涩，如果你需要对内存的细节进行管理、优化，rust 的语法是非常清晰易懂、易学易用的。

而如果你不需要对内存的细节进行管理、优化，用 rust 就有杀鸡用牛刀的感觉。

[zhengxiaowai]

那必然是有啊，可以看一下今年 InfoQ 上，王枞老师的 《 Rust 跨平台客户端开发在字节跳动的实践》基本上已经在我们这个大部门作为 SDK 全面铺开了

[Mohanson]

但求好事 莫问前程

[lululau]

反正我觉得市场方面没有什么前景，门槛有点高，不能像 Java 一样会点皮毛就能上手做项目开发了

[noqwerty]

微软似乎也要上 rust 了，说 C++手动管理内存太累了😂

[eslizn]

对企业、技术管理人员来说，低门槛的语言性价比高

[jeffcott]

头条一直在招 rust

[VDimos]

有啊，字节跳动已经在用 rust.了，最近在招 rust 工程师

[hLc1]

@lululau java 能和 rust 比吗？ rust 是 c++ 的同等级产品，两个领域不同，rust 可以在任何领域代替 java 反之则不行

[murmur]

大公司用任何一个语言都可以拿出来吹一下，而作为小公司来说，你只能考虑全盘语言，太多的语言养太多人养不起

[reus]

@hLc1 开发个安卓应用试试？

[MeteorCat]

语法不会晦涩难懂，if let 简直太爽了还有?的错误自动返回，主要是入门难度太高了，如果有 C/C++基础，你就会痛哭流涕

[ipixeloldc]

@reus 纯 rust 开发安卓，不太清楚行不行，但可以作为库用 如果只是 ui 用 Java 啥的写，核心逻辑用 rust,应该也算开发了安卓应用吧？ https://dev.to/robertohuertasm/rust-once-and-share-it-with-android-ios-and-flutter-286o

[darknoll]

前景为 0

[mahone3297]

rust 和 go 比呢？

[Mivon]

@cmdOptionKana 可能我对 rust 的运用还不够多，所以觉得语法有点难懂，但是对 rust 有种莫名的好感，说不定以后 web 开发也能有一席之地。

[noobma]

呜，rust 太难了，前面问题都不大，今天看到 Box RefCell Rc 这些，嵌套一多，就要停下来捋一下，尤其是那个循环引用的例子，Rc 又分 strong 的 weak 的，菜鸡懵了啊😭

[Mivon]

@noqwerty 应该是微软用 rust 重写了 windows 的某些组件，然后感觉还可以。

[noobma]

@Mivon Microsoft: We're creating a new Rust-based programming language for secure coding 😂

[coolmenu]

微软又搞了一个新的语言

[hujianxin]

感觉生命周期这部分还是很难得

[Mivon]

@hujianxin 同感，‘a 'b 'c 这种，头痛

[Mivon]

@noobma 最近新出的语言也太多了，大多感觉都是换汤不换药，很少有像 rust 这样，让人耳目一新的

[mondeo]

pingcap 也用 rust 写的 tikv

[u823tg]

自己看看玩玩就行， 吃饭还是选别的

[cco]

@hLc1 刚开始流行而已，别这么膨胀，秒跳秒地秒空气的语言或许有，但又能怎样？生态是一天两天建立的起来的？

[zjsxwc]

代替 C++，
不过我写 C++一路无脑 shared_ptr 也无所谓了

[keyfunc]

生态上还是欠缺了些

[Hanggi]

Rust 虽然有很吸引人的特性，但是泛用性和整个生态都不如 Golang。长期看好 Golang 多一些。

[dodo2012]

@Mivon 哈哈，对的，这个'a, 'b, 'c 在我第一次学时直接把我劝退了，隔了好久又回头重看了一篇文章才清楚了些，然后丢着不用，又忘记了。借用，所有权这两项在初学时会劝退一群人。

[ipixeloldc]

@Hanggi 泛用性挺高的吧，比如 Golang 可以在单片机上跑吗？ rust 可以。c/c++能干的,rust 都能干。go 能干的 rust 也都能，go 不能干的 rust 也都能....但就是学习成本等问题，两者都能干时，有些地方确实没 go 来的方便...至于生态，确实差了点，不过 rust 社区活力挺高的，靠时间就能解决。

[MeteorCat]

@noobma 这个其实 Box 可以理解为 c++的 unique_ptr,Rc 则是 shared_ptr,Weak 也能找到类似，RefCell 和 Cell 的存在主要是让不可变(没有 mut)的 struct 能够在能不直接修改属性值，实际上官网那篇确实有的地方讲解太繁琐了

[ztxcccc]

学 rust 还不如学 VB.net

[zhucegeqiu]

@mahone3297 rust 翔味冰淇淋 go 冰淇淋味翔

[crella]

@ztxcccc 我这枚菜鸟从 vb.net 转 c#竟然没什么大问题。绝大多数.net 的资料都是以 c#代码的形式展示，当然素养好的话换成 vb 代码也是默念的事。

[Raymon111111]

看前景拿着它找工作就行了

[smdbh]

痒了，圣诞有空见识一下

[loqixh]

rust 其实就是智能指针的语法化

[blless]

@ipixeloldc tinygo

[GeruzoniAnsasu]

rust 是来替代 c++的
c++有几个问题导致它“难用”

内存管理很容易爆炸
语法过于复杂，难学
模板过于无拘无束，以至于衍生了太多泛型以外的作用，写和维护都很爆炸
缺少现代的包管理 /build 机制

这几个问题里
内存，现代 c++基本已经自行解决，语言层解决不了的（如因为操作系统机制导致的泄露 /溢出） rust 也无法解决
难学和难维护的问题，rust 倒退了一步。看着封装好的宏的时候可能挺爽的，读别人的代码依然酸爽
包管理是 rust 对比 c++真正的优势，但在很长一段时间里仅仅是看起来机制更好，并不存在实际的优势。你发现想用的 package 依赖 nightly build 的 rust，依然会很难受


综上所述 估计 rust 并不有能力去淘汰正在激进地往语言里加现代特性的 c++


当 c++和 rust 能做的事和实现方式都差不多的时候，反正我还是选 c++

[ysn2233]

我真的很喜欢这语言，但只能说前景确实不是很明朗。

[shibo501c]

一些区块链公司, 非区块链有 PingCAP, 头条, 好像阿里有个做数据库的团队也在用

[TaAmSf]

c/c++ 有 Qt,Nginx,FFmpeg..., rust 是很好，但是对于没有能力造轮子的人来说没啥用呀。

[sherlockgy]

@noqwerty 最新的新闻是微软安全团队试用了 Rust,并表示语言很不错但是当前又遇到了新问题;这两天又报道准备基于 Rust 开发新的语言了,估计是 Rust 先天有问题

[noqwerty]

@sherlockgy 大厂真的都热衷于造轮子

[slanternsw]

@tianshilei1992 这也太火星了吧，rust 除了一开始用 OCaml 写的 demo 期之外一直是 llvm 做后端，都多少年了

[slanternsw]

@sherlockgy 不是微软的意思，是 msr 又手痒想造语言玩了

[ppphp]

现在大方向是需要一门真正的在目前的硬件条件下汇集了人类共识的语言，rust 比 go 要好的多，但是硬件的发展是不会停的，现在方便正确的并发安全，编译期优化都有办法了，但是未来分布式安全，量子安全优化，异构编程这种乱七八糟的东西，谁知道会不会成为未来流行的趋势，一个个加进语言特性，真的会比 c++好很多吗？

[tianshilei1992]

@slanternsw 确实火星了，还以为一直是 OCaml 的东西呢…

[FrankHB]

@noobma 这很大程度上不是 Rust 的问题，是本来就没法回避那么复杂的问题。
要回避复杂，代价是放弃准确的控制。比如，放弃显式所有权抽象，在大多数语言中实际上就是允许所有资源默认扔给 GC 管理这种特例，而没法表达更一般的情况。这个意义上，一部分问题来自用户自己，没想清楚问题自然就无法表达——大部分用只有显式释放或者有 GC 擦屁股的语言入门的用户都会习惯性地忽略这个问题：到底是谁保证你能使用资源？
想清楚了这点，之后会发现实践中能不失控的有效的套路也就那么几种。像 strong 和 weak，就算有 GC 擦屁股的语言也可能提供相应的特性，比如 java.lang.ref.WeakReference。
当然，严格说，Cell、RefCell 和 Box 的问题对没见识够多不同风格语言的用户来讲，是要复杂一点，这涉及到更普遍的语言设计策略问题。
具体一点，Cell 之类必要性和理解困难，同时来自于 Rust 想削减抽象复杂性的背景而忽略了对象可变性和对象的同一性(identity) 在更普遍的情况下正交的现实。
和这种设计对立的一个典型例子是 C++ ，它的不可变性(imutability) 由附加在一般不限制修改的对象上类型的 const 限定符来限制，这保证一般的可变和不可变对象总是简单对偶的（如果忽略 volatile 以及常量表达式之类的更麻烦的东西）。配合 C/C++ 的对象作为存储(memory) 的抽象，这很容易让只读和不只读访问的内存一一对应而容易理解。
而在 Rust 中，一般地，不存在可变和不可变存储的概念，而只有“共享只读”和“独占可读写”对象的对偶。这样的好处是简化了需同步并发的操作抽象且在许多情况下更实用，代码默认不那么罗嗦而稍微不容易出错（特别是默认不可变引用的范式能避免 C++ 新手到处丢 const 的问题），坏处就是破坏了正交性，特别是不保证单独分辨同一性的手段，而使语言难以扩展不同于简单二进制表示的可修改性来定义变化(mutate) 的不同操作。（虽然大多数用户现在日常用不到，主流编译器的 constant propagation 都还没法基于扩展可编程的不可变性来让类型系统进行推理，但这至少对语言未来的演化仍然有消极影响。）
Rust 用 Cell 和 RefCell 提供了 UnsafeCell 的安全变体。而 UnsafeCell 提供了“内部可变性”。后者在动机上相当于 C++ 的类数据成员上修饰的 mutable。在 C++ 的设计中，const 对象类型蕴含子对象类型也具有 const，这种类型系统的实现策略使 mutable 作用显得直白——无视类类型对象的 const 对子对象作用（ const 传播）这条类型系统默认规则。Rust 使用默认不可变而不是像 C++ 那样附加 const，这种内部不可变为什么必要在实现上就更加抽象而不容易理解（即使业务逻辑上“什么时候适合用”的理解难度应该是相同的）。
实际上 Rust 做得更多。为了确保安全，Rust 这里还可以具有运行时的类型检查。不过这在理解上就应该不是什么大问题了。
Box 在一定程度上也和避免表达同一性相关。这方面更典型的例子在一些传统上就不允许用户表达同一性的语言（粗略点说，就是和 ALGOL/C 相差得足够大的语言）上找到，可以参照 SRFI-111。

[hehheh]

@GeruzoniAnsasu 大公司都会搞自己的编译机制，我们公司在 cmake 的基础上又包了一层，搞了个什么 xxxmake。然后写起来确实很容易，都快赶上 python 了。。。最爽的是你还是可以用 cmake 直接配置工程的。

当然第三方包用起来还是挺麻烦。比如 qt 和 opengl 什么的。还是要稍微额外配置一下。

[hehheh]

其实编译器优化也是一个问题，我记得有的编译器如果用右值拷贝复制构造的话直接就优化调用构造函数了。再加上 c++进化的速度 2010 年以后还是稍微比原来好了点，现在新特性写起来也挺舒服。

当然不妨碍很多公司用 c++11 之前的标准，你没看错。我们用的就是 vs2010，部分支持 c++11 特性。。。

[FrankHB]

@GeruzoniAnsasu Rust 是想替代 C++ ，但历史包袱决定它做不到。
它没有足够多的难以替代的项目、厂商支持甚至用户的支持，也没有足够具有超过现有语言整体设计的格局，所以没法保证避免和更新近的语言之间菜鸡互啄（虽然大致上是鸡头）。
难学倒是未必，至少不像 C++ 有那么多鬼哭狼嚎教你如何翻车的劣质教材。
这里还有个洞，就是 C++ 理论上应该能允许用户做好，但没有核心语言特性用户实际就做不好的情形——比如早就有 mojo 结果 C++11 还是把右值引用直接内建了。这是加新特性的动力之一，但之后加进去坑就坑大。（ C++ 为什么没有 destructive move ？因为类的子对象的构造怎么都不对头……）
Rust 历史包袱更少，就意味着在更 idiomatic 的用法和初期演化效率中都占有优势。C++ 用户基数大，历史包袱也大，加的特性越多就越作死，语言本身就越难以维护。并且现在 WG21 这方面的品味和水准就实在不咋地。凉拌吧。
难维护……看人了。某种意义上 Rust 的用户大致对应 C++ 用户的中间阶层——剩下的能用 C++ 写出可维护性不比 Rust 差的项目的用户以及被教残的 C++ 用户都不怎么会转进到 Rust，而没别的语言背景上手 Rust 是比较吃力的。

@TaAmSf C/C++ 在这里不占便宜。
用 C 的主要理由就是维护轮子，造轮子都嫌破事多。
用 C++ 的主要理由是维护轮子+造轮子。只是现在要用轮子的用户，基本连 C++ 也懒得用了，结果就是整个语言的发展都不会实质上朝能控制或进一步简化实质复杂性（而不是仅仅少写特定情况下的代码）的方向节制（即便 BS 成天嚷嚷 teachability ），而更在乎有能力造轮子的用户的需求。这样迟早一样会让没有能力造轮子的用户没事可做。

@sherlockgy @slanternsw 微软也就折腾 DSL 还行（不管是研究还是产品）。
MSR 搞 PL 的能出点名堂的都偏向现有问题上搬砖的具体实现而非整体设计，造越通用的语言越不顶用，也很难看出这些人有多重视这个方向。
看看那什么 Bosque 之流的水货都能带上微软的名号就知道这些人的态度了。

@ppphp 人类共识……就凭那一整坨连换行和 indent 都拎不清的蓝星猴子，你还是指望靠分布式共识发家致富比较有现实性……
方法论来讲，靠堆砌特性来设计语言是缺乏普适意义的错误方向，这点在几十年前 RnRS 的开头就说了（显然绝大多数语言在发展方向上这里就完全不合格）。然而现在 RnRS 自己都没太能搞定这个原则……
大部分有能力在这个方向上搞语言的，一开始就栽在用户不够就没用的调调上了，而要得到用户数量上的明显优势就必须妥协自己提供足够多特性，用户越多还越难拒绝，无法回头。这导致没有谁能实际上不违反不管是 PL 理论还是工程上的理想原则。
而更多的设计者根本就是完全没这个概念，只是先想出来让人用再说，到处一大抄，甚至毫不在乎被当作是外行（比如上面拿来婊的那个 Bosque ）。
除非能保证对拒绝共识的用户专政，这就没办法收场。这是价值观问题。

[FrankHB]

@hehheh RVO/NRVO 这类 copy elision 是直接优化没掉。
替换 copy ctor 为 move ctor 是 C++11 后的内容，因为 move ctor 是 C++11 引入的。
C++17 钦定一些情况下直接没有新创建的对象，这些情况下不再是可选的优化了。这算得上是 C++17 最大的核心语言特性上的变化。
C++11 到现在包括 draft 里加起来能实用（有靠谱实现）的内容都没有一个 C++11 的变动大，之后多少特性一样要么跳票几次要么回炉重造，你说比原来好……是想 peach。

[janus77]

新版火狐就用 rust 啊

[MeteorCat]

@FrankHB 还有 socket 库问题，rust 官方附带了跨平台 socket，甚至 web 框架(actix 和 actix-web)

[abbycin]

@FrankHB 🌍果然是律师

[jjx]

学过, 用不下去

如果开发企业软件(业务类的) 用 rust , 要发疯的

[jacketma]

把 rust 改名叫 C+++就很快流行起来了

[nowgoo]

Rust 易学易用？

“明天就是五一小长假了，大家又有三天时间学习所有权系统了 ​​​​”

[Mivon]

@nowgoo 想想就很快乐

[Mivon]

@jjx 他的定位感觉就是系统编程语言，所以业务可能不太合适

[hehheh]

@FrankHB 我的意思是 10 年到现在的变化比 00 年到 10 年要好

[dodo2012]

@nowgoo 三天不够，再加一周，现在我还被'a 'b 这玩意搞的分不清

[anytk]

所有权，生命周期以及泛型枚举的设计很好，但在实际使用的时候真被语法折腾坏了，太多的 ' 太多的 <和 >，刷题倒是不错。门槛高，心智负担大

[FrankHB]

@hehheh 00 到 10 年是参与的人少，所以看起来没进展，但整体提案质量比较高，实际有效的工作量比较大（当然，还是跳票了好几次，大多数进展都堆在 09~10 年了）。如果你跟进及时，那之后的体验相比起来是一点都不好，因为之前吹的最响亮的一些东西都没有及时交付，吊胃口出反效果了。而且看现在的提案，一些基础方向并没比十年前更清楚，瞎加的没验证过设计的乱七八糟的特性一坨（还有跟 C 密谋一起干翻现有 C++ 异常的……），以后可能更混乱，建议不要抱太大希望。

[FrankHB]

@MeteorCat 这里有个重要的本质差别：决定语言设计的所谓官方不对等。就社区支持而言，跟 Rust 官方相对的其实是 isocpp.org 而不是决定语言设计的 WG14，这里会有一定的脱节，需求不容易同步，所以 C++就有更容易跳票的成分，导致容易不靠谱更明显。反过来，Rust 的官方明显在一致性上是占便宜的。Rust 没有出 spec，核心团队文档和实现一窝端，所以面对需求变化的反应迅速，不过意味着大厂商支持就比较随缘；相对地，基本上 C++标准确定的东西都是有一定厂商支持的（只不过一直有很多阳奉阴违的矛盾），所以一出乱子就很难挽回了。这决定提供和系统支持相关的库会面临不同的阻力，所以 C++网络库难产的现象很正常。
但是，要让语言面向的业务范围更广，那就不可能通过单独的官方提供大而全的解决方案，因为资源有限不可能做到所有领域的最优化而一定会有人不满——特别是网络这块至少在所谓系统编程的领域中算是很高层而且需求不稳定的东西。更根本地，无论是面对碎片化的选型还是甩掉历史包袱都是业界的正常义务，一直都是“不爽不要玩”；用钦定唯一的方案暗示用户接口的（不见得靠谱的）稳定设计，而不是方便不同需求的用户进行不同的选择，随着用户规模的扩大会越来越难以妥协，根本上不是办法。
另外一个不同是我看 C++不爽的话可以 fork 个 C++自己用，但 Rust 没 spec 所以要连同实现一起 fork （虽然 C++已经麻烦到 fork 了起来也不大有意义就是了）。

[FrankHB]

艹，WG14→WG21。

[ZiLong]

@FrankHB 听大佬的一番论述,就像上网遇到大佬的头像一样绝望.....系统编程已经凉了,只有找 Julia 感受 Hot 了

[ipixeloldc]

@Hanggi
@blless 噗，用 llvm 重写 go 编译器嘛....强...我学的那时 go 只能做上位机，现在都发展到这步了吗.....厉害

[reus]

@ipixeloldc 不算

[MeteorCat]

@FrankHB 受教了

[FrankHB]

@ZiLong 倒也不是说凉……这方面一直有刚需，混不上饭吃是不可能的。不过除了政策市，和互联网的待遇差距不大可能填平，更像搞传统硬件的。
老实说，这个领域中的理论比较封闭所以习惯吃历史包袱的红利，并据这类和其它领域不通用的经验来成为护城河，所以外人觉得门槛高（确实高，但也就那么回事）。而 PL 这种底层的技术在这方面的演进和实践相对于 app 甚至 Web 前端都非常落后——理论 PL 界基本无关心，也没能力去设计整套解决方案，包括我上面提到的不够表达正交的 object identity 的问题（题外话，除去资源管理问题，所谓“面向对象语言”这里经常设计得比理论界整的更对路，但基本就没靠谱的经验，像 Singularity OS 什么的稍微有点气候的实验性项目也都停摆了）。这决定了 C/C++ 在排除历史包袱这个最大的特色（不论算是优势还是缺陷）之后，仍然有一定的底气赖在系统编程这个领域中，我也不得不承认再辣鸡确实也没法替代。
在有兴趣的情况下，选择 Julia 这类大概是比纠结系统编程更靠谱的（市场容量也未必就小）。因为 DSL 更注重业务领域的匹配，所以就算语言设计得烂，不良后果也没那么严重。这方面，最烂的不是个别语言自己的设计问题，而是不适合解决领域问题被强行用于业务领域导致的适配问题——所以退一步讲，这些语言的设计者只要有自知之明别觉得自己什么都能干而干成半吊子，光是挖 Python 之类的墙角就都不大容易饿死了，大有可为（

[FrankHB]

回到主题，不限于 Rust，就是指通用目的语言的话，更长期的趋势不好说，但我预测应该迟早会“文艺复兴”——最终把 C/C++ 这样绝对意义上就不怎么好用而且可维护性怎么整都不咋地的方案给排除出包括系统编程领域在内的各个主流实现。
更长期地，DSL 可以从通用语言演化。我之前有粗略考虑过这方面的整体需求问题：
https://github.com/FrankHB/pl-docs/blob/master/en-US/calling-for-language-features.md#judgment-on-the-general-purposed-language
我的结论是，要满足一般意义上的一桶浆糊的目的，基本上只能靠其它领域的通用语言实现，先从克服语言演进的障碍（更新和修改语言特性的现实工程问题）开始——像 Rust 这种被用户需求逼出来的包管理器这样的表面方案是远远不够的（现在依赖外部 shell 的整合方式也不是合理的方向）。根本地，这要求语言特性应能很大程度地“反射”语言 spec （注意，不说 Rust 这种连 spec 都没给的，大多数语言在这里仍然是用不靠谱的自然语言写的，原则上根本不可编程）和实现（比如允许用户自己给编译器补丁扩充语言且兼容性仍然可控； Rust 编译器插件的存在说明了设计者注意到了部分需求，但如 rustc::plugin 这种只关心 rustc 而不是 Rust 自身的流于实现细节的备胎解决方案仍然是不靠谱的），这脱离绝大多数现在的工业界语言既有设计的能力上限，因此被主流业界接受需要很久（可能到 Rust 自然嗝屁以后）。
所有之前在这个楼讨论的内容都不是这条路线。最近能看得到的绝大多数语言，包括 Rust 在内，甚至都不具备接近这条路线的创新。现在大概只有 Racket 这种预先强调 language-oriented programming 的做法和实现经验稍微能看一点，但 Racket 本身在技术上就有很多问题——例如从一个依赖 GC 的运行时剥离出来一个不依赖 GC 而具有显式所有权的核心语言，这基本除了回炉重造没有办法，而且 tooling 还是太弱了。
对应地，过于依赖传统的 AOT-central 的方案不可能是通用的实现方案——反省下 LLVM 这类的既有实现为什么连 libjit 都统一不了就能闻出点味道了。以 explicit SSA 作为核心 IR 的转换方案，使过程内和过程间优化的实现更加困难且难以自动化，迟早导致规模增加以后工程资源消耗的现实不可行（现在很多写编译器的赶鸭子上架已经超常发挥了，工作量规模一旦失控，加倍 996 也没用）。对应的前端实现也普遍比较粗放，很多都直接把什么 declaration 撸到框架内部，连翻译单元都没法做出和目标语言解耦的抽象，稍微跟 C-like 相差大点的就没法复用得整个重来，LLVM 撸成“库的集合”的好处很大程度被抵消了。
历史上比较能接近这里的长期目的的，大概只有 REFAL 这样的 metacompiling system，但这方面的研究几十年来一直相当初级，工业界接近这个目标的最先进的也就是 Graal/PyPy 这种类非典型的只能优化小部分类型开销的 partial evaluator ……所以可能得再等几十年业界才会认识到现在这条路走不通——不过这些都是超出主题的身后事了。

[ZiLong]

@FrankHB (￣▽￣)~*

[reus]

@ipixeloldc
https://ziutek.github.io/2018/03/30/go_on_very_small_hardware.html

[dddbbb]

我们在招 rust，希望各位了解一下：
https://v2ex.com/t/628803