廣東
最近看Linux 6.5內核的實測報告，有點意外。Rust寫的驅動模塊，加載慢了10.7%，跑包時CPU多占9.5%，內存多用10.9KB。一堆人說“果然還是C快”，但沒人提一句：這慢的10.7%，只發生在模塊加載那1次；而C那邊，`module_init()`里一個`kmalloc()`失敗，就得手寫七八行回滾代碼，寫錯就panic——這種事，沒人記，也沒人測。
我問過兩個做車載系統的師兄，一個用C寫CAN驅動，一個用Rust寫GPIO。C那個說，查一個use-after-free平均要4個多小時，日志就打一行`general protection fault`，得翻匯編。Rust那個說，上次報錯直接標出第37行`drop()`調用時機不對，改完編譯就過。他沒說多快，就說“不用猜”。
硬實時場景確實還靠C。比如工業PLC要求中斷響應控制在100微秒以內，Rust的`Drop`調度現在沒法保證。這不是編譯器偷懶，是所有權模型本身和確定性調度有沖突。rust-for-linux官方roadmap上清清楚楚寫著：這部分2026年Q4才進草案——不是不想快，是數學上還沒解出來。
ARM64上Rust驅動跑得挺順，但RISC-V的`irqchip`綁定還在紙上。不是不支持，是物聯網設備廠商反饋太少，沒人搭環境測。另外，Linux內核維護者里只有8.3%真用Rust寫過生產模塊。不是大家排斥，是原來寫C的師傅們得先搞懂`Send`和`Sync`到底在干啥，而這個過程沒法跳過。
特斯拉車載系統的數據很實在：Rust模塊占了41%，但所有碰CAN總線的模塊，全是C。不是信不過Rust，是CAN一斷，剎車可能沒反應。安全邊界劃得特別細，不是按語言，是按數據流來的。
性能數字單獨看真沒用。一個函數每秒調10萬次，Rust多花2.3%CPU，可能就得換；但一個配置解析函數，一個月只運行一次，Rust多占幾KB內存，換來的是不用人工盯內存釋放順序——這賬，得算維護時間，不能只看perf report。
C語言沒死，它只是不再當“默認選項”了。現在新寫的USB驅動、音視頻編解碼模塊，基本都用Rust。老模塊該修還是修，但沒人再往里面塞新的高危邏輯。
3%不是快慢問題，是人力怎么花的問題。
C不會消失，Rust也沒贏。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
