Linux 内核爆发 C / Rust 大战，核心开发者愤然离职

我是蓝石头

samfs 发表于 2025-2-12 17:47
非计算机专业，图一乐的话，rust 值得学吗，和 C 比呢

建议python，一个上午就可以用pytorch零到一写一个简单的有监督机器学习训练加推理，感受朴素的机器学习乐趣。
再花一个下午可以用fastapi零到一部署一个带前端，带后端，带数据库，甚至还有api看板的全栈应用。
再花一个上午，把自带的文件上传接口后面接上刚训练的那个模型的推理，好了，你有了一个图片分类站点

非教徒

我是蓝石头 发表于 2025-2-12 18:10
建议python，一个上午就可以用pytorch零到一写一个简单的有监督机器学习训练加推理，感受朴素的机器学习 ...

来个教程的链接啊...

iamawaistcoat

bcxzzz 发表于 2025-2-12 18:02
从技术上来说，可能给一种语言留后门么？ 比如考虑下：1、语言的解释器、编译器是公开代码的么？ 2，即使 ...

和npm一样，在cargo拉进来的那一堆依赖里面？

Xerxes_2

看这个帖子就高潮的人是不是根本对前情没有一点了解就来输出的？
首先 Rust 进 Linux 是 Linus 本人首肯的，C++都没进
其次前几个月在 Rust4Linux 会议上有 C 的支持者当众指着鼻子骂，这才是这些纷争的导火索

samfs

ryanz 发表于 2025-2-12 17:50
图一乐现在学 python 玩最火的 ai 吧。

有一说一确实可以试试

samfs

我是蓝石头 发表于 2025-2-12 18:10
建议python，一个上午就可以用pytorch零到一写一个简单的有监督机器学习训练加推理，感受朴素的机器学习 ...

看描述确实很有乐趣

Steel.Haze

d2loader 发表于 2025-2-12 17:42
根本不是你说的能阻止或者禁止的，现在是个人按照教程就能用rust写内核驱动

实际上我说这些的主要感觉就是rust进内核就是有推手搞起来的一阵风，各个社区都有抵制情绪，再结合上面的提到的情况，最终无疾而终。能写当然是肯定能写。不过其最终不会占据一偶。

abcxiawei

samfs 发表于 2025-2-12 17:47
非计算机专业，图一乐的话，rust 值得学吗，和 C 比呢

不值，非计算机专业请一切围绕你要实现的东西走，哪个语言能最快的实现出你想要的东西，你就用哪个，没必要一定用rust，甚至没必要一定用C

abcxiawei

非教徒 发表于 2025-2-12 18:57
来个教程的链接啊...

教程？随便打开个AI，问它：

1.我想要个什么，应该用什么实现
巴拉巴拉巴拉巴拉巴拉巴拉巴拉巴拉巴拉巴拉

2.这个东西需要什么样的环境，怎么搭
巴拉巴拉巴拉巴拉巴拉巴拉巴拉巴拉巴拉巴拉


3.环境搭好了，请给我写一个范例程序
巴拉巴拉巴拉巴拉巴拉巴拉巴拉巴拉巴拉巴拉

Wiksy

samfs 发表于 2025-2-12 17:47
非计算机专业，图一乐的话，rust 值得学吗，和 C 比呢

非专业的就用各种脚本语言平时做工具就挺好的了，不需要C或者rust这种

darklinden

Xerxes_2 发表于 2025-2-12 19:03
看这个帖子就高潮的人是不是根本对前情没有一点了解就来输出的？
首先 Rust 进 Linux 是 Linus 本人首肯的 ...

他们只是想骂 rust 而已

这事儿吧…
Linus 允许 rust 进 驱动

某个讲座上说的是“只是想了解或者精细化每个变量的生命周期以使其更加安全”然后被嘘

rust 如果不进 DMA 无法“舒舒坦坦”地使用api（如果你觉得拷贝源码而不是调用库算是正常使用方法那你牛逼）

M佬向原内核维护人员申请包装一层使用被拒，申请自己实现并维护一套rust的等同C的实现被骂“绝不会允许其他语言进入内核，那就是癌症”

Linus扯皮了两周未对此事发表任何意见，然后M佬怒把此事丢进舆论，他出来对M佬说，现在的问题不是对错而是你，之前已经在跑的东西能跑就是能跑，你说的对与错无所谓，你把这事儿丢舆论漩涡就是你的锅。

M佬怒辞…


—— 来自 S1Fun

HariSeldon

abcxiawei 发表于 2025-2-12 11:16
又是这套“我头脑比你强”逻辑。

我自己也是程序员出身的。我已经不止一次看到你们这种逻辑了，越年轻的 ...

俺寻思这个错误理解很早就被说过了。Rust语言特性多并不能推导出心智负担比C/C++重

反直觉的是，C/C++才是对程序员门槛要求高，心智负担重的那个。学习C++门槛低，靠C++吃饭门槛可高了。即使是精英程序员，精力不济时照样可能犯低级错误。而Rust的编译器检查则极大减少了业务逻辑外犯错的可能性。

一个需要用到非GC语言的非嵌入式项目，几个资深带一群普通程序员用Rust是可以干的：定好规矩or脚本检查普通程序员不可提交unsafe代码就行了，剩下自有编译器教。同样配置的团队用c++的话，不会以为编译器放行是降低心智负担吧？

至于市面上九成以上不需要非gc语言的工作…也不用关心rust，哪有那么多写rust的

— from S1 Next Goose v3.3.96

coyove

可以去看看hellwig的回复，“不是说我不喜欢rust”，叠甲叠满，rust不愧是编程界原神

YoumuChan

Steel.Haze 发表于 2025-2-12 16:27
你这个说法太理中客。且不说换内核的整体工程代价。这种集中化模式其实增加易于被几种攻击的点而已。你只 ...

“由于把会出问题的地方集中起来导致容易被集中攻击”这个说法，有一种“练了金钟罩铁布衫只剩两三个罩门导致容易被集中攻击所以不如不练”的美感。

操作系统方面的落地了的应用案例有https://github.com/cloud-hypervisor/cloud-hypervisor，还有就是Asahi Linux上的GPU驱动吧。

123485k

bcxzzz 发表于 2025-2-12 13:03
对于这种后出来的语言，美国的棱镜计划之类的，会不会直接在编译器里埋后门？

—— 来自 HUAWEI LIO-AL0 ...

还是有可能的，可以参考这篇博客

bcxzzz

123485k 发表于 2025-2-13 01:12
还是有可能的，可以参考这篇博客

看了这个博客，我感觉美国一直在往种操作系统里塞后门。即使用R，也要看到这个语言的源码才行。

—— 来自 HUAWEI LIO-AL00, Android 12上的 S1Next-鹅版 v2.5.4

御坂MKII

woodey 发表于 2025-2-12 15:58
我知道rust很好，那为啥不用rust新做一个系统或者其他大型应用？而是一直依托于C/C++社区的东西 ...

那不是还因为之前没有更合适的，所以有丰富的历史厚重
https://github.com/tikv/tikv  tidb 当时分开选了 golang，现在天天在和 gc 和 golang 的大道至简打仗 到了今天我无比的希望 tidb 是构建在一个 immutable as default 的语言之上的，构建在一个不要天天有事没事就逃逸到堆上然后给 gc 上强度的语言之上的。某种程度上来说，现在 golang 本身也已经变成这个年轻项目的历史厚重了
类似的也有 https://github.com/databendlabs/databend
数据库因为有单机转 raft/paxos based 以及未来更激进的 cloud infra 的需要，所以活跃的新项目是很多的，golang 和 rust 还真是一前一后俩被人喜欢用的

gawain

这事锅就在Linus自己身上，要又不全要。 事实上今天哪怕不是rust，换任何语言都会造成社区的分裂。 本来大家都是用C。不管是维护自己的模块，还是处理其他模块的调用产生的问题。都不存在语言层面知识的障碍。现在内核引入了另一种语言的模块。那我遇到这些模块的问题，是不是还要先学会这种语言？我本来写C写的好好的。 凭啥让我学一个新语言，而且还得比较深入的研究。

论坛助手,iPhone

星空天神

没有写过rust，不过rust既然用所有权的问题解决内存安全问题那么多线程下的内存安全是怎么在编译时期解决的？

Xerxes_2

星空天神 发表于 2025-2-13 08:00
没有写过rust，不过rust既然用所有权的问题解决内存安全问题那么多线程下的内存安全是怎么在编译时期解决的 ...

看 Sync 和 Send 两个 trait，简单说严格限制了对象在线程之间发送/共享的要求
就我体验来说 Rust 写多线程是比 C 要方便且安全的多的（没用过 C++）

星空天神

Xerxes_2 发表于 2025-2-13 12:42
看 Sync 和 Send 两个 trait，简单说严格限制了对象在线程之间发送/共享的要求
就我体验来说 Rust 写多线 ...

看了一下c++大概是这么写

1. std::string a;
   
2.     std::mutex m;
   
3.     std::thread t1([&]
   
4.                 {
   
5.                     std::lock_guard<std::mutex> lock(m);
   
6.                     a += "hello";
   
7.                 });
   
8.     std::thread t2([&]
   
9.                 {
   
10.                     std::lock_guard<std::mutex> lock(m);
    
11.                     a += "world";
    
12.                 });
    
13.     t1.join();
    
14.     t2.join();
    
15.     std::cout << a << std::endl;

复制代码

rust要arc包裹mutex包裹string。有个疑问就是假如一个被共享的只读对象也要用arc来访问，在跨numa的情况下原子操作的代价非常昂贵，rust是如何去解决这个问题的？

YoumuChan

星空天神 发表于 2025-2-13 13:46
看了一下c++大概是这么写
rust要arc包裹mutex包裹string。有个疑问就是假如一个被共享的只读对象也要用ar ...

假如你在线程运行期间对共享对象不会进行更改的话，可以开scoped thread，然后直接共享只读引用就行了。编译器在发现这段生命周期里共享对象只会派生只读引用的话，就会允许你在线程间传递只读引用，所以可以不用arc，甚至不用加锁。

假如需要更改但是你可以保证线程不会后台一直运行，也即你共享的对象最终由主线程释放（持有所有权），而不会由子线程一直持有引用的话，你也可以scoped thread然后直接传递互斥锁mutex的引用，不用arc。

如果什么都不能保证，那你必然需要一个线程安全的类似shared_ptr的东西，那这个东西在rust就叫做arc。

— from S1 Next Goose v3.3.96

燕山雪

新来者要融入高活跃度的社区，肯定要先适应已有的习惯和文化，而不是要求老屁股改变自己去讨你开心。如果需要包一层c接口，由rust人自己写好了直接请求合入，对其他人无感，可能冲突会少一些？

d2loader

燕山雪 发表于 2025-2-13 14:23
新来者要融入高活跃度的社区，肯定要先适应已有的习惯和文化，而不是要求老屁股改变自己去讨你开心。如果需 ...

你说的对，的确就是rust的人自己写了dma相关绑定

但是dma的老大说他要一个人审查所有dma相关的代码，rust这边自己写的绑定他看不懂，然后说这种引入第二语言的行为是癌症

之后楼主说到那位选择发到社交网络上施压

Linus对这种想要网暴的行为严厉批评

时间线是这样的



—— 来自 鹅球 v3.3.96

优秀

darklinden 发表于 2025-2-12 20:19
他们只是想骂 rust 而已

这事儿吧…

由你描述的过程看来，早前linus让rust进内核说明他也不反感rust，但下面吵了两周他没表态说明他也不知道这个问题上支持哪边好，然后rust那边把这个问题放到社交媒体上这个行为激怒了他（他觉着这种吵架就该在技术社区吵？），这时候他出来说的不是谁对而是谁错了。
好像linus这么处理也没错，当然人跑了从大局上来看是自己损失了。

FeteFete

我是蓝石头 发表于 2025-2-12 18:10
建议python，一个上午就可以用pytorch零到一写一个简单的有监督机器学习训练加推理，感受朴素的机器学习 ...

写python 和写c++真的不是一个难度，哪怕写一个玩具都不一样

darklinden

优秀 发表于 2025-2-13 16:04
由你描述的过程看来，早前linus让rust进内核说明他也不反感rust，但下面吵了两周他没表态说明他也不知道 ...

换位思考，想象一下：

你是team leader，有一只鲶鱼进入了你的队伍，能力出众，然后有一个看起来不错的想法，进队就开始砸天花板开天窗，甚至所有工作都已经做好了（就差合并了

但是你组里的老人开始发难，说，既然老项目在跑就不要去动它，新的东西可能很好也可能引起更多的问题，甚至可能把家炸了

虽然你的直觉告诉你鲶鱼们的主张是对的，但是你一怕真炸了，二怕老人撂挑子，只好看他们打嘴仗

这时老人开始嘴臭，鲶鱼找自己要说法...

也不能开了啊，开了没人干活儿了，先晾晾？

鲶鱼被晾久了直接把嘴臭挂微博，老人开始被网暴...

烦死了，怎么还有微博挂人的家伙...先骂一顿...

艹，微博挂人那个怎么跑了?...

（HackNews还是有大批人吐槽Linus已经老了的，真换位思考一下，很多情况是管理问题造成的...吧...

Jet.Black

极端反C++也是管理问题，与C兼容性最好的肯定是C++，C的高人多少也会点C++。

优秀

Jet.Black 发表于 2025-2-13 16:24
极端反C++也是管理问题，与C兼容性最好的肯定是C++，C的高人多少也会点C++。 ...

没学过rust，但c++编译出来的东西确实比臃肿不少，内核还是要追求小、快，操作系统内核开发用c是有道理的。

gammatau

优秀 发表于 2025-2-13 16:04
由你描述的过程看来，早前linus让rust进内核说明他也不反感rust，但下面吵了两周他没表态说明他也不知道 ...

只能说一开始看错了人找了个喜欢上社交媒体闹事的，幸好他自己跑了，算止损。

Midnight.Coup

有人在 Linux 内核中提交了一个补丁，目的是让 Rust 编写的驱动程序能使用 dma_alloc_coherent() 函数，这样 Rust 驱动也能像 C 语言驱动一样，使用 Linux 内核提供的 DMA 功能，从而更高效地处理设备与内存之间的数据传输。
然而，这个提议遭到了 Linux 内核维护者 Christoph Hellwig 的强烈反对。Hellwig 明确表示，他不希望在内核的 DMA 部分看到 Rust 代码。实际上，这个补丁只是将代码添加到了一个不同的地方（rust/kernel），而不是直接改动 DMA （kernel/dma）部分。

Hellwig 的拒绝让很多 Rust 开发者们感到郁闷，对此，Rust for Linux 项目的首席开发者 Miguel Ojeda 出面请求 Hellwig 给出一个替代方案。Hellwig 回应道：“把包装器放在你们自己的代码里，而不是让别人为你们的事情受苦。”
因为是在邮件列表的回应，所有开发者都可以看到，对此，Red Hat 的软件工程师 Danilo Krummrich 直接质问 Hellwig，“你们自己的代码是什么意思？是不是在每个驱动程序中都重复了？否则，rust/kernel/dma.rs 看起来合理，对吧？”
Hellwig 接着表示：“DMA API 的接口应该保持在可读的 C 代码中，而不是用奇怪的绑定来实现，这样它才可以被 grep 搜索并且更易于维护。”

此外，Hellwig 也明确表示他根本不愿意处理 Rust 代码。他写道：“不要强迫我处理你们这门时髦的语言。维护多语言的项目很痛苦，我没有兴趣去处理。如果你们想用的不是 C 语言，像汇编语言或 Rust，你们自己写 C 接口，自己解决语言不匹配的问题，反正我不管。”
Krummrich 解释称，并没有人要求你处理或者维护这段 Rust 代码。Rust for Linux 项目正在创建 Rust 代码，它将 C API 抽象化，供所有 Rust 驱动程序使用，并由 Rust 开发者来维护。
换句话说，内核中的 C 代码保持不变，而 Rust 驱动程序通过抽象层来使用这些 C 代码，这些抽象层由 rust/kernel 中的团队集中维护，整体上比每个驱动程序自己编写 C 语言绑定要好。

但 Hellwig 似乎不愿意让 DMA 的 Rust 抽象层单独维护，甚至不应该在 Linux 源代码树 rust/kernel 中维护。他怒斥道：“如果你们想让 Linux 因为跨语言的代码库变得无法维护，那就让你们的驱动自己去做吧，而不是把这种‘癌症’传播到核心子系统中。”
Hellwig 继续论述说，让其他人单独维护 Rust 的抽象层来处理 DMA 的内存分配器，并不会改善问题，反而会妨碍内核的可维护性：“每引入一种新语言，就会大da降低内核作为一个整体项目的可维护性。Linux 之所以能生存这么久，是因为它没有内部边界，而引入另一种语言完全破坏了这一点。你可能不喜欢我这么说，但我会尽全力阻止这种做法。这不是因为我讨厌Rust。虽然它不是我最喜欢的语言，但它绝对是新兴语言中最好的之一，我鼓励人们在适合的情况下用于新项目。我只是不希望它出现在我需要维护的大型 C 语言代码库中。”

几轮辩论之后，Krummrich 认为 Hellwig 作为一名维护者，他的一些举措超出了维护者的工作范围，即：根据个人喜好，任意限制某个实体对公共内核 API 的使用。
为此，他和 Asahi Linux 项目负责人 Hector Martin 纷纷请求 Linux 之父 Linus Torvalds 出面解决这一问题。Martin 在邮件中写道：

我的看法：如果 Linus 没有在这个讨论中给出权威的答复，Miguel 和其他 Rust 的开发者应该在代码经过审查并准备好后，直接合并这部分内容，不必理会 Christoph Hellwig 明显想要破坏项目的行为。
如果 Linus 拒绝合并，那么 Christoph 说的就无关紧要了。如果 Linus 不合并，R4L 项目基本上就会死掉，除非 Linus 或 Christoph 采取行动。其他的讨论只是绕圈子。
Rust 开发者们：请不要浪费时间和精力去纠结这种戏剧性的事情，这不值得。要么 Linus 喜欢，要么他不喜欢。其他的都是少数破坏者维护者故意制造的干扰，他们想通过打击你们的士气来让你们放弃，因为他们知道自己终究会在历史中处于失败的一方。旧的固守阵地的维护者再怎么破坏，也无法阻止世界向内存安全语言的方向发展。
顺便说一句，我认为 Christoph 的“癌症”言论足以成为违反行为规范的理由，但我怀疑不会有任何相应的处理。

殊不知，Martin 的这一则邮件直接将 Linus 推到需要做出二选一决策的”边缘“。
面对 Martin 呼吁 Linus “发表权威回答”以解决设备驱动的僵局，并支持通过“社交媒体羞辱”来反击 Linux 维护者对 Rust 代码的敌视，Linus 对此方法予以否定。
Linus 极其礼貌但毫不客气地回应 Martin：

Martin：如果在社交媒体上羞辱他人没有效果，那就告诉我，还有什么方法有效，因为我已经没有其他办法了。

你能不能接受一个事实，也许问题出在你自己身上？
你以为你知道得更好，但目前的流程是有效的。
它有问题，但问题是生活的一部分。没有完美的东西。
不过，我必须说，社交媒体的“围攻”让我根本不想再和你们的做法有任何关系。
因为如果我们在内核开发模式中有问题，那么社交媒体绝对不是解决方案。就像它根本不是政治问题的解决方案一样。
技术补丁和讨论才是关键。社交媒体围攻——谢谢，但不需要。

在得到 Linus 的回复之后，Martin 愤而决定辞去 Apple Silicon 代码的上游维护者职务。
Martin 在最新的一次补丁中写道：“我已经不再对内核开发过程或社区管理方式抱有任何信心。Apple/ARM 平台的开发将继续在下游进行。如果未来我有兴趣向上游提交一些补丁，不管是针对哪个子树，我可能会，也可能不会。任何愿意自己为上游提交做出努力的人都可以去做。”
Asahi Linux 的开发者兼共同维护者 Sven Peter 听闻这一消息后出面表示：“给我几天时间来弄清楚我们该怎么做。我认为我们可以继续推动该树的前进。”

在引入 Rust 的过程中，C 和 Rust 开发者之间的摩擦也是不可避免的，Linux 的创始人 Linus Torvalds 也对此有深刻认识，他曾在 Linux 基金会的开放源代码峰会上提到过这一点。
Torvalds 说：“显然，有些人就是不喜欢 Rust，也不希望 Rust 侵犯他们的领域。有人甚至在说 Rust 的整合是失败的……我们做这个已经好几年了，现在说失败还太早，但即使它最终失败了——虽然我不认为会失败——那也是一种学习的方式。”
此外，他还指出，目前内核中的任何功能都不依赖 Rust，短期内也不会依赖。重要的是向前推进，因此开发者们应该“全速前进”，暂时不要太在意这些问题。即便现在细节还不完善，只要能让功能正常运行就足够了。一旦用户开始依赖 Rust 代码，才需要更细致地处理这些问题。但现在，如果开发者因为过于谨慎而裹足不前，反而会让项目受挫。

只是在此次争论中，Linus 的处理方式让不少开发者觉得有些不满：

Rust 问题暴露了 Torvalds 作为领导者的一次罕见失职。与其果断地说“不是，绝对不行”或者“是的，执行”，他在 Rust 的问题上一直模棱两可。
鉴于 Linux 社区中有相当一部分（且非常 vocal）的人对他的决定产生了信任危机，这种犹豫不决的态度反而起到了适得其反的效果。而且 Linus 没有明确立场，实在是有些反常（比如我们都知道他对 C++ 的立场）。
作为一个试点项目，R4L 应该早就毕业或者结束了。但经过多年积极开发，它的现状依旧不明朗。Linus 并没有采取措施让大家达成共识，而是选择一直坐视不管，看着下属们相互争斗，最后还将责任推给 Martin，实在是欠妥。
可以说，他对 Martin 的训斥明显表明了他永远不会偏袒 Rust，但他并没有明确说出来。也许他知道应该表态，但又担心会引发一场风暴。也许现在是时候撕掉创可贴了。
再说一次，所有这些本来都可以避免，如果他当初能坚定地站队，不论是赞成还是反对。想象一下，如果 Linus 直接说“不要，保持在下游”，能节省多少时间和精力，甚至是仅仅 Martin 的时间。

Xerxes_2

Midnight.Coup 发表于 2025-2-13 17:38
有人在 Linux 内核中提交了一个补丁，目的是让 Rust 编写的驱动程序能使用 dma_alloc_coherent() 函数，这 ...

Asahi Linux 的图形驱动似乎就是 Rust 的

Midnight.Coup

Xerxes_2 发表于 2025-2-13 17:46
Asahi Linux 的图形驱动似乎就是 Rust 的

Linus 本人还在 mba 上用 Asahi Linux，R4L 也是 Linus 点头进主线，就很一言难尽，这件事归根到底是 Linus 的态度不明，整双方的像后宫斗争，Linus 最后左右都不好偏，只能从态度上拿 M 佬开刀
本质是历史轮回之传统派和维新派，Linus 拉 Rust 进来也有拉拢新人进来维护主线的意思，老人不学没事，新人接手就行，但关键时刻 Linus 拍不了板，或者说还是偏老人了，emmmm

vail潇

支持rust的人再用rust重构一版不行吗？

—— 来自 vivo V2307A, Android 15上的 S1Next-鹅版 v2.1.2

Xerxes_2

vail潇 发表于 2025-2-13 17:56
支持rust的人再用rust重构一版不行吗？

—— 来自 vivo V2307A, Android 15上的 S1Next-鹅版 v2.1.2 ...

https://www.redox-os.org/
?
坛友真的有点搞笑了，一点不懂就原神原神后门后门的叫

怀疑编译器后门的看看这个项目，用 C++写的 rustc，可以继续怀疑 gcc/llvm 有没有后门
哟，这不就怀疑到坛友最喜欢的 C/C++ 头上来了嘛
https://github.com/thepowersgang/mrustc

RookieTnT

字节的rsbuild 和 rspack倒是挺好用的

Xerxes_2

RookieTnT 发表于 2025-2-13 18:02
字节的rsbuild 和 rspack倒是挺好用的

现在开发基建用 Rust 的挺多的了，数了下我电脑上的

1. $brew uses rust --installed --include-build --include-implicit --include-optional                                                                                                                 
   
2. aider                  fd                     hyperfine              librsvg                ripgrep                tectonic               typst                  uutils-coreutils       zoxide
   
3. bat                    fish                   kondo                  mise                   scriptisto             tokei                  typstyle               uv
   
4. eza                    helix                  libimagequant          rav1e                  starship               tree-sitter            usage                  yazi
   

复制代码

unlsycn

Midnight.Coup 发表于 2025-2-13 17:38
有人在 Linux 内核中提交了一个补丁，目的是让 Rust 编写的驱动程序能使用 dma_alloc_coherent() 函数，这 ...

「罕见」失职.jpg

unlsycn

不知道楼里的坛友是怎么一口一个「HaskWell」还有信心装PL大手子的问就是原神.jpg

ryanz

万恶淫猥手 发表于 2025-2-12 13:45
Rust 粉和 NodeJS 粉已经快接近之前的 PHP 了

另外人家 Kernel 也没反对你用 Rust，是说你不能乱搞也给你 ...

别瞎说，现在的 nodejs 粉大概确实消散完了，对于这些争论只能说时间证明一切吧

说到时间，最近 10 年的新生代语言我就喜欢 zig，相对其他次生代语言 比如 golang 的 cgo 以及 rust 的 bindgen 引用 c 库的方式，它干净太多。这里还是要吐槽下 rust，bindgen 出来的东西编译后 strip 不干净，导致执行文件体积**增加