| CSDN（ID：CSDNnews）
我從事專業(yè)的 C++ 編程工作已經(jīng)四年多了，然而，三個(gè)月前我找到了一份新工作需要使用 Rust。我想通過本文，分享一下我個(gè)人關(guān)于在兩種語言之間切換的經(jīng)驗(yàn)和想法。
聲明：本文不打算比較 C++ 和 Rust，文中的觀點(diǎn)源自個(gè)人的經(jīng)歷。
1 C++ 和 Rust 的工作介紹
我認(rèn)為，個(gè)人從事的工作會(huì)極大地影響對(duì)語言的體驗(yàn)，下面我來簡(jiǎn)單介紹一下背景。
我使用 C++ 大多從事的是編寫數(shù)據(jù)庫的工作。數(shù)據(jù)庫不是常見的應(yīng)用程序，通常它們獨(dú)占服務(wù)器，可以使用大量的系統(tǒng)調(diào)用，而且在有些情況下甚至可以完全繞過內(nèi)核。另一方面，這意味著數(shù)據(jù)庫是研究特定語言的一個(gè)有趣的樣本，因?yàn)槟阈枰P(guān)注性能，為客戶提供良好的用戶體驗(yàn)，同時(shí)還需要保證正確。
鑒于公司的保密協(xié)議，所以我不能分享工作細(xì)節(jié)。我運(yùn)行 Rust 的環(huán)境是具有高負(fù)載和高標(biāo)準(zhǔn)性能要求的數(shù)字運(yùn)算異步服務(wù)器。它有點(diǎn)類似于數(shù)據(jù)庫，但用戶體驗(yàn)可能并不那么重要。
就本文而言，我認(rèn)為這兩者非常相似。
2反復(fù)談及的方面
Rust 具有良好的內(nèi)存安全保證。這個(gè)話題已被反復(fù)討論，所以不在此贅述。雖然我已經(jīng)使用 C++ 四年多了，但即便是已經(jīng)過審查和合并的代碼，偶爾也會(huì)遇到內(nèi)存問題引發(fā)的服務(wù)器崩潰。很難說有多少這樣的代碼進(jìn)入了生產(chǎn)環(huán)境，因?yàn)槿藗冎皇窃诎l(fā)生段錯(cuò)誤時(shí)重新啟動(dòng)服務(wù)器。模糊測(cè)試確實(shí)可以確保覆蓋一些奇怪的案例，但終究不是靈丹妙藥。總的來說，我認(rèn)為交付 Rust 代碼比 C++ 代碼更安心。
3構(gòu)建系統(tǒng)
在日常工作中，最令我厭煩的工作莫過于構(gòu)建 C++ 代碼。作為一名開發(fā)人員，我希望能夠編寫一個(gè)簡(jiǎn)短的命令來構(gòu)建整個(gè)項(xiàng)目。“在構(gòu)建服務(wù)器之前，你只需要運(yùn)行這兩個(gè)命令……”，這句話簡(jiǎn)直太可怕了，因?yàn)檫@表明構(gòu)建過程是多步驟的。每次都需要運(yùn)行這兩個(gè)命令？只有當(dāng)這兩個(gè)文件發(fā)生變化時(shí)，需要運(yùn)行這兩個(gè)命令，這句話什么意思？如果我使用 sanitizers 構(gòu)建項(xiàng)目，這些命令會(huì)如何變化？構(gòu)建過程不支持 sanitizer 是什么意思？為什么構(gòu)建腳本突然開始輸出鏈接錯(cuò)誤？
我說了這么多，其實(shí)就想表達(dá)一個(gè)觀點(diǎn)：缺乏統(tǒng)一的構(gòu)建系統(tǒng)真的很令人苦惱。Bazel 是朝著正確方向邁出的一步。CMake 至今仍是我的噩夢(mèng)。
在經(jīng)歷了這一切后，我感覺 Rust 將我從地獄拉到了天堂。你只需編寫一個(gè)簡(jiǎn)短的命令來構(gòu)建整個(gè) Rust 項(xiàng)目。更重要的是，這個(gè)世界上所有其他的 Rust 項(xiàng)目使用的都是同一個(gè)構(gòu)建系統(tǒng)，因此你無需將構(gòu)建腳本從他們的系統(tǒng)轉(zhuǎn)換到自己的系統(tǒng)。你只需要 Cargo.toml 中的一行代碼，就可以將構(gòu)建過程所有的依賴項(xiàng)都包含進(jìn)來。它甚至?xí)詣?dòng)將正確的編譯標(biāo)志傳遞進(jìn)來。
4編譯器
來自兩個(gè)編譯器的錯(cuò)誤消息真的很讓人崩潰，你需要付出大量努力才能正確理解和修復(fù)。
在 C++ 中，錯(cuò)誤消息的大小都是以千字節(jié)為單位衡量的。終端模擬器中的無限滾動(dòng)是絕對(duì)必須的，因?yàn)?C++ 編譯器太喜歡輸出文本了。幾年后，你會(huì)形成某種直覺，只要看到錯(cuò)誤多少就能判斷自己是應(yīng)該閱讀錯(cuò)誤還是看看代碼。通常錯(cuò)誤消息越大，隨便看看代碼的作用就會(huì)大于閱讀錯(cuò)誤消息。我感覺，如果 C++ 不改變模板的定義方式，這個(gè)問題永遠(yuǎn)無解。
在 Rust 中，編譯器錯(cuò)誤（在修復(fù)所有拼寫錯(cuò)誤之后）通常是非常糟糕的消息。通常，這些錯(cuò)誤消息表明你需要通過某種方式重新組織代碼，或花一些時(shí)間調(diào)整生命周期，所以你不可能錯(cuò)誤地使用內(nèi)存。雖然這個(gè)過程需要時(shí)間，而且很煩人，但正確的方法是認(rèn)真聽取編譯器的建議。說起來很慚愧，通常聽取建議有助于編寫更好的代碼。此外，錯(cuò)誤消息可以完整地顯示在一頁內(nèi)，很方便閱讀。
5類型系統(tǒng)
在 Rust 的類型系統(tǒng)中表達(dá)想法是一種享受。
首先，非常感謝沒有鴨子類型的泛型。Traits 清楚地表達(dá)了類型希望看到的合約結(jié)構(gòu)或函數(shù)。這也有助于編譯器生成有用的錯(cuò)誤消息。我們獲得的錯(cuò)誤消息不再是：“對(duì)第 Y 行的方法 clone 的無效引用”，而是“類型X沒有實(shí)現(xiàn) Clone”，清晰明了。
其次，枚舉非常強(qiáng)大。Result 和 Option 是非常強(qiáng)大的概念，每個(gè)人都在使用。這兩個(gè)枚舉是所有庫（包括標(biāo)準(zhǔn)庫）表達(dá)容易出錯(cuò)的計(jì)算和可選值的通用語言。在 C++ 中，我們有 (1) 返回錯(cuò)誤代碼；(2) 返回?zé)o效值；(3) 引發(fā)異常；(4) 進(jìn)程崩潰。所有有問題的選項(xiàng)和每個(gè)庫都使用不同的選項(xiàng)。除了 Result 和 Option 之外，我發(fā)現(xiàn)定義標(biāo)記枚舉的功能也非常方便。
總結(jié)
總的來說，切換到 Rust 后，我感覺日常工作體驗(yàn)得到了極大地提升。Rust 的工具非常友好，語言富有表現(xiàn)力且功能強(qiáng)大。我非常喜歡 Rust，而且我希望Rust 將來的發(fā)展能夠避免 C++ 的一些陷阱。
