rust 前景

2019-12-05 09:56:10 +08:00
Mivon  Mivon

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

12531 次点击
所在节点   程序员  程序员
78 条回复
nowgoo
nowgoo
2019-12-06 10:51:26 +08:00
Rust 易学易用?

“明天就是五一小长假了,大家又有三天时间学习所有权系统了 ​​​​”
Mivon
Mivon
2019-12-06 10:53:19 +08:00
@nowgoo 想想就很快乐
Mivon
Mivon
2019-12-06 10:54:01 +08:00
@jjx 他的定位感觉就是系统编程语言,所以业务可能不太合适
hehheh
hehheh
2019-12-06 14:44:26 +08:00
@FrankHB 我的意思是 10 年到现在的变化比 00 年到 10 年要好
dodo2012
dodo2012
2019-12-06 15:07:44 +08:00
@nowgoo 三天不够,再加一周,现在我还被'a 'b 这玩意搞的分不清
anytk
anytk
2019-12-06 15:21:30 +08:00
所有权,生命周期以及泛型枚举的设计很好,但在实际使用的时候真被语法折腾坏了,太多的 ' 太多的 <和 >,刷题倒是不错。门槛高,心智负担大
FrankHB
FrankHB
2019-12-06 16:33:08 +08:00
@hehheh 00 到 10 年是参与的人少,所以看起来没进展,但整体提案质量比较高,实际有效的工作量比较大(当然,还是跳票了好几次,大多数进展都堆在 09~10 年了)。如果你跟进及时,那之后的体验相比起来是一点都不好,因为之前吹的最响亮的一些东西都没有及时交付,吊胃口出反效果了。而且看现在的提案,一些基础方向并没比十年前更清楚,瞎加的没验证过设计的乱七八糟的特性一坨(还有跟 C 密谋一起干翻现有 C++ 异常的……),以后可能更混乱,建议不要抱太大希望。
FrankHB
FrankHB
2019-12-06 16:47:31 +08:00
@MeteorCat 这里有个重要的本质差别:决定语言设计的所谓官方不对等。就社区支持而言,跟 Rust 官方相对的其实是 isocpp.org 而不是决定语言设计的 WG14,这里会有一定的脱节,需求不容易同步,所以 C++就有更容易跳票的成分,导致容易不靠谱更明显。反过来,Rust 的官方明显在一致性上是占便宜的。Rust 没有出 spec,核心团队文档和实现一窝端,所以面对需求变化的反应迅速,不过意味着大厂商支持就比较随缘;相对地,基本上 C++标准确定的东西都是有一定厂商支持的(只不过一直有很多阳奉阴违的矛盾),所以一出乱子就很难挽回了。这决定提供和系统支持相关的库会面临不同的阻力,所以 C++网络库难产的现象很正常。
但是,要让语言面向的业务范围更广,那就不可能通过单独的官方提供大而全的解决方案,因为资源有限不可能做到所有领域的最优化而一定会有人不满——特别是网络这块至少在所谓系统编程的领域中算是很高层而且需求不稳定的东西。更根本地,无论是面对碎片化的选型还是甩掉历史包袱都是业界的正常义务,一直都是“不爽不要玩”;用钦定唯一的方案暗示用户接口的(不见得靠谱的)稳定设计,而不是方便不同需求的用户进行不同的选择,随着用户规模的扩大会越来越难以妥协,根本上不是办法。
另外一个不同是我看 C++不爽的话可以 fork 个 C++自己用,但 Rust 没 spec 所以要连同实现一起 fork (虽然 C++已经麻烦到 fork 了起来也不大有意义就是了)。
FrankHB
FrankHB
2019-12-06 16:48:01 +08:00
艹,WG14→WG21。
ZiLong
ZiLong
2019-12-06 17:07:04 +08:00
@FrankHB 听大佬的一番论述,就像上网遇到大佬的头像一样绝望.....系统编程已经凉了,只有找 Julia 感受 Hot 了
ipixeloldc
ipixeloldc
2019-12-06 17:10:20 +08:00
@Hanggi
@blless 噗,用 llvm 重写 go 编译器嘛....强...我学的那时 go 只能做上位机,现在都发展到这步了吗.....厉害
reus
reus
2019-12-06 18:22:18 +08:00
@ipixeloldc 不算
MeteorCat
MeteorCat
2019-12-06 18:22:22 +08:00
@FrankHB 受教了
FrankHB
FrankHB
2019-12-06 18:49:07 +08:00
@ZiLong 倒也不是说凉……这方面一直有刚需,混不上饭吃是不可能的。不过除了政策市,和互联网的待遇差距不大可能填平,更像搞传统硬件的。
老实说,这个领域中的理论比较封闭所以习惯吃历史包袱的红利,并据这类和其它领域不通用的经验来成为护城河,所以外人觉得门槛高(确实高,但也就那么回事)。而 PL 这种底层的技术在这方面的演进和实践相对于 app 甚至 Web 前端都非常落后——理论 PL 界基本无关心,也没能力去设计整套解决方案,包括我上面提到的不够表达正交的 object identity 的问题(题外话,除去资源管理问题,所谓“面向对象语言”这里经常设计得比理论界整的更对路,但基本就没靠谱的经验,像 Singularity OS 什么的稍微有点气候的实验性项目也都停摆了)。这决定了 C/C++ 在排除历史包袱这个最大的特色(不论算是优势还是缺陷)之后,仍然有一定的底气赖在系统编程这个领域中,我也不得不承认再辣鸡确实也没法替代。
在有兴趣的情况下,选择 Julia 这类大概是比纠结系统编程更靠谱的(市场容量也未必就小)。因为 DSL 更注重业务领域的匹配,所以就算语言设计得烂,不良后果也没那么严重。这方面,最烂的不是个别语言自己的设计问题,而是不适合解决领域问题被强行用于业务领域导致的适配问题——所以退一步讲,这些语言的设计者只要有自知之明别觉得自己什么都能干而干成半吊子,光是挖 Python 之类的墙角就都不大容易饿死了,大有可为(
FrankHB
FrankHB
2019-12-06 18:54:20 +08:00
回到主题,不限于 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
ZiLong
2019-12-06 21:16:33 +08:00
@FrankHB ( ̄▽ ̄)~*
reus
2019-12-09 14:17:38 +08:00
dddbbb
2019-12-13 17:39:59 +08:00
我们在招 rust,希望各位了解一下:
https://v2ex.com/t/628803

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/626109

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX