这是一个创建于 1455 天前的主题，其中的信息可能已经有所发展或是发生改变。
Rust China Conf 大会会后，有嘉宾和我谈到“为什么说 tokio 不是最好的 io 框架”的话题。我谈起了 7 年前我在开源项目中实现的一种新的 top performance io 运行时调度设计。嘉宾“杰哥”很有兴趣，问什么时候能在 Rust 中实现，我表示这块暂非核心关注，估计要等一段时间。
大会回来的这几天，我在想，其实如果有更多的小伙伴进来一起做，也不一定要等多长时间。与其大家都独自开发各种学习性轮子，不如一起做些工业级的思考，完成些更有意义的社区级项目。我们中国公司很厉害已经可以雇佣 Rust core team 成员，而我更期待咱们中国工程师们能更多地在整个 Rust 社区展现我们的思考和前进力。
我设想了 2 个计划或称提议：
plan#1: 本计划也许算有点“私心”，想看看在中国有没有和我类似在数据工程领域有思考想实践的小伙伴，我虚“键盘”以待，结对带撸 TensorBase 代码[1]，这可能对时间略有要求。
plan#2: 这个计划更加一般和容易进入，适合对于数据工程无兴趣或者无概念，但对一般性高性能工程有兴趣的小伙伴，我们从小而美的原初开始，对时间和技能无实质性要求，大家按兴趣前进（但我提供老司机般稳的视角，并适时强力介入）。我抽出了一些 project ideas[2]，这些 ideas 对我来说其实是“过去时”，但放在 Rust 甚至整个开源性能工程社区，我还没发现很好的实现。同时，也欢迎大家提自己的 ideas 。但一点建议，我们不做功能驱动开发。因为功能性的实现何其多，大家出于学习目的是好的，但正因为太多，放之于整个社区来看意义不大。
本版有点冷啊，我上次发文三个月了，还排在第一页，希望后续能够活跃一下版面：）
 |
1
felixin 2021-01-02 12:09:08 +08:00 via Android  2
rust 心智负担太大了
|
 |
2
victor 2021-01-02 12:17:53 +08:00
一直没搞明白，在编程的世界中怎么套用：民用级、商业级、工业级、军用级、医疗级这些概念。
听起来就像是用这些词来装 X 的。 |
 |
3
matrix67 2021-01-02 12:28:21 +08:00
@victor 我来随便聊一下对这些词的第一映像
民用级： 脚本程序，普通人写写的。一般是易语言 autohotkey 商业级： 一般就是 java cpp 。很少见过有人说我这个 python node 是商业级代码（只是这么说，没说一定不是，比如 trello 后端也是 node ） 工业级：c 或者 cpp，dotnet 。 响应快？ 我对工业级的概念 军用级： 汇编 、c 。什么波音公司，洛克希德·马丁公司写的。 没见过开源的军用级项目。（阿波罗貌似开源了，算吧） 医疗级： 有个看门狗，喂狗 （同样没见过开源的医疗级代码） |
 |
4
jinmingjian OP @felixin 有点吧：）我从本次大会上看，对语言的反映是两极，有人是你这么说的，有人觉得特别好，因为不让你乱搞，他们说特别适合工程。绝对的自由带来绝对的混乱，通常还是有点控制比较好，哈哈。
|
|
5
jinmingjian OP @victor 同意，单从用词来说，是有点装的：）我用在这里，主要是想说，我们做一些项目如果能帮助广泛的开发者或者人群，那么它的价值就会凸显，就比如是各种工业改变了普通人的生活。但再比如一个 http 库搞个 10 个、100 个，我觉得有点浪费。
|
 |
6
jinsongzhao 2021-01-02 21:50:19 +08:00
还在评估 rust 的效益. 因为目前公司主打是 C/C++和 Java,Python. 如果能合并 C/C++和 Java,效益就厉害了.可惜 rust 的 orm 并不是 jdbc 那样跨平台的,而且貌似它还没打算朝这个方向发展
|
|
7
jinmingjian OP @jinsongzhao 乐见好的评估结果：） orm 如果是指 object-relational mapping，这个是和 jdbc 不同的层次，更偏应用。但 orm 是两面性比较强的，我个人建议是不要用（在那个 Eclipse 时代，我用过太多 EMF/JPA 组合，不知道现在 Java 的 ORM 是谁家天下）。Rust 至少能做到 ODBC 所做的，跨平台的考量应该不是太大问题，当然数据库驱动问题我没有特别了解。
|
|
8
jinmingjian OP @jinmingjian 忘了一点，“听说很难写的”的小伙伴都是来自其他领域来大会看看（比如 C++），上船了的小伙伴都说香，哈哈
|
|
9
jinsongzhao 2021-01-03 10:13:43 +08:00
走专深方向, 对跨平台要求不会高, 但是根据客户要求选平台, 和现有系统对接来说很重要. rust 目前的跨平台数据库支持, 是分别调用 odbc 和 unixodbc, 开源社区还无人搞 jdbc 这种一次编译就能跨平台的,当然了 rust 目标不是一次编译, 多一个发布环节倒也无所谓, 可惜 unixodbc 没考虑过 windows 下运行. 这个时代搞一个语言,追求完美的程度已经非常高了. rust 对能写出稳定系统的 C++老手来说, 优缺点还处于 55 开,是否变成主打,完全取决于新人, 有新人才会产生老人, java 的壮大是有道理的, 新人友好,又能深入,又能复杂; 性能还可以通过 jni 嵌入动态库, jna 接口对 jni 的简化程度, 和 rust 的动态库调用一样方便. go 同样是新人友好为入口. 所以希望 rust 在新手的吸引力上多努力,增加更多内置的语法糖, 又可以扩展为安全语法, 这样写示范代码也可以省心些.
|
|
10
jinmingjian OP 分析的挺对的。说到语言必然会引战，就像今天的 HN 某热帖[1]。
我认为 Rust 的定位决定了其确实难以取悦所有人。大会时我正巧和一位 hw 的工程师谈到这个问题，我说我其实还挺喜欢 Java 的，内核很简单，但稍加学习你也能写出较快的系统（如你说所），如果快速开发上层业务系统，我还是建议 Java 。但和 C/C++/Rust 这类系统语言比，Java 语言的性能上界是明显的，jni 和 jna 都是 work around，如果大量采用和直接基于 native 语言构建系统并无太多区别，这个在大系统中看就能有比较明显的展示（小系统不否认有可能只在关键路径上解决速度问题即可），这也是 Spark 为什么在这么多年高性能改进后，还要内部用 C++搞一个引擎的原因。 其他的不敢多谈，一定会引战：） [1] [Rust is now overall faster than C in benchmarks]( https://news.ycombinator.com/item?id=25623634) |
 |
11
contractswif 2021-01-04 21:27:06 +08:00
@jinmingjian 很棒的思考！虽然现在还不能加入社区开发，但本人一直非常支持 rust 。能带动语言潮流的，在新人之外，我认为往往就是一个实际的“工业级的项目“，类似于 ror 之于 ruby，flask, jupyter 等之于 python, 有了能实际应用的项目，自然就有新人加入，然后就有各种问题会被解决，带动发展。我在做高性能计算方向，非常期待看到 /未来投入 rust 相关的开发上。
|
|
12
jinmingjian OP @contractswif 太欢迎，这么多年、这么多语言用下来，其实 Rust 最棒的还是社区
|
 |
13
Jirajine 2021-01-24 15:26:41 +08:00
想知道 tokio 的实现哪些地方有问题，以及你所说的“新的运行时调度设计”是什么样子，没找到相关文章，能给个链接看一下吗？
|
 |
14
UN2758 2021-10-11 21:47:35 +08:00
plan 2 怎么联系呢
|
Select Language