Rust是不是就相当于新时代的C语言？ 第1页

这个问题，让我想起来之前CTO跟我们闲聊的一个话题，如果有足够的钱，你想（用公司的产品）做什么？

当时各种头脑风暴里就有一条：用Rust或者Go语言把我们的操作系统（VxWorks）重写一遍。

理论上说，任何语言都可以拿来写操作系统。几年前我回答：

有很多人尝试过用非C语言的方式去写一个简单的操作系统，所以本质上说，操作系统并没有特别严格的语言限制。编写操作系统的语言选择更多的是一种工程上的选择：

1. 方便操作硬件；
2. 方便跨平台；
3. 性能要好一些；
4. 不依赖操作系统的运行库

工程上最困难的其实是最后一条：不依赖操作系统的运行库。在Linux内核里，各种最基础的运行库都是不依赖操作系统的，比如memcpy, strcmp, printf, malloc这些C语言里最最基础的东西。因为没有比操作系统更底层的东西，所以操作系统自身要实现所有最基础的工作。

其它语言往往都是用现成的glibc/msvc库，然后走系统调用完成实际的操作。但是操作系统就是系统调用的提供者，自然就只能自己搞定这些工作。C++的异常处理，Java的资源回收等等，这些东西如果放到内核里，都需要重新实现一套。

经过了这么多年的发展，C语言已经有在内核中完整的一套运行库，其它语言么要想重写操作系统，就要自己重写一遍（重复造轮子），这种工程上的开销非常巨大，并非技术上做不到。

完全使用另外一种语言重写内核这件事，我个人是不太赞同的，因为C语言本身特别贴硬件，任何太高级的语言都多少有一些限制。

比如，访问空指针（NULL），在很多语言里是非法的，但在内核中，不一定是非法的：x86实模式下，0地址上放的是中断向量表，是一个合法且有效的地址。类似的例子还有很多，比如调度器的调度函数实际上是永远不会返回的；中断处理程序里很多高级语言的保护动作都会失灵；创建进程的过程中，某些资源可能是父进程申请、子进程释放；内核最初的内存不是申请来的，有些是拿来直接用的等等。

如果其它语言要写一个完整的操作系统，那么就需要对一些特殊的场景提供特殊的特性支持。C语言限制少，所以C语言在这方面比较灵活。

一种合理的假设是在内核中支持Rust（也可以是别的语言）开发的驱动程序，这种可能性是存在的，对于新写的模块，使用Rust来开发，可以兼顾安全性和兼容性。这种情况是也就是现实情况，比如Windows驱动可以用C++开发，Linux内核里貌似也有用Rust开发的驱动。

回到题主的问题：

Rust是不是就相当于新时代的C语言？

我觉得不算，语言之间没有类比性。最多就是特性相似，但跟C最相似的应该算是C++吧。

话说用Rust重写一个Linux内核会不会是一个挺有意义的工程？

意义说不上来，但很烧钱是真的。