“

本文是對(duì)今天 Reddit 熱帖：何時(shí)會(huì)考慮使用 Cpp 而非 Rust（Considering C++ over Rust）[1]中精彩討論的總結(jié)。Reddit 上面討論非常激烈，本文只是一些精彩評(píng)論的摘錄，大家可以去原帖閱讀更多討論。

背景

一位同時(shí)使用過(guò) Rust 和 Cpp 的開發(fā)者，他用 Rust 主要是實(shí)現(xiàn) Web 服務(wù)器和命令行工具，而 Cpp 則用于游戲開發(fā)（虛幻引擎）和編寫虛幻引擎插件。

最近他的一個(gè)使用 Javascript 的朋友問(wèn)他：“你為什么要用 Cpp，它很糟糕，Rust 解決了 Cpp 的所有問(wèn)題”。

這是Rust社區(qū)一直在使用的主要口號(hào)之一。

公平地說(shuō)，這并不是這位開發(fā)者開始使用Rust的原因之一，他選擇使用 Rust是因?yàn)?Rust 的包管理工具 Cargo；另外一個(gè)原因是Node的創(chuàng)始人在談?wù)揇eno（用Rust編寫的Node.js的繼任者）時(shí)說(shuō)：“我再也不會(huì)在我的生命中開始一個(gè)新的C++項(xiàng)目了”。

另一方面，他多年來(lái)一直在使用Cpp，主要是與虛幻引擎密切配合，但他從未遇到過(guò)通常由 Rust 社區(qū)列出的問(wèn)題。Cpp 有智能指針，我覺得現(xiàn)代 Cpp 解決了很多被認(rèn)為是 Cpp 弱點(diǎn)的問(wèn)題。這主要取決于你是什么樣的程序員，以及你在其中的經(jīng)驗(yàn)。

所以，他在 Reddit Rust 和 Cpp 頻道都發(fā)了同一個(gè)帖子，想了解大家何時(shí)會(huì)選擇使用 Cpp 而不是 Rust ？

Rust 頻道的評(píng)論

sird0rius：

我討厭 Cpp 變得如此復(fù)雜龐大。Cpp 是我20多年前學(xué)的第一門語(yǔ)言，我嘗試學(xué)習(xí)一些更現(xiàn)代的寫法，但由于一些只有多年經(jīng)驗(yàn)才能學(xué)到的語(yǔ)言陷阱，我仍然無(wú)法達(dá)到通過(guò)一些基本的 Cpp 面試的水平。或者通過(guò)閱讀比《戰(zhàn)爭(zhēng)與和平》還長(zhǎng)的這個(gè)龐然大物。作為一個(gè)職業(yè)選擇，對(duì)我來(lái)說(shuō)學(xué)習(xí) Rust 更有意義，因?yàn)槲以谶M(jìn)入底層編程方面比追趕 Cpp 標(biāo)準(zhǔn)更具競(jìng)爭(zhēng)力。我認(rèn)為，在學(xué)習(xí)基本的現(xiàn)代 Cpp 所需的時(shí)間里，我可以掌握 Rust 以及其他幾種編程語(yǔ)言。每當(dāng)我了解 Cpp 的新知識(shí)時(shí)，我都會(huì)想：“為什么在 Cpp 中做這個(gè)事情要比在 Rust 中復(fù)雜得多呢？（例如移動(dòng)和復(fù)制語(yǔ)義）”。即使 Rust 沒(méi)有大熱，我仍然可以依靠我在短時(shí)間內(nèi)學(xué)到的其他語(yǔ)言。

pr06lefs：

我曾經(jīng)是一名 Cpp 開發(fā)者，有15年的經(jīng)驗(yàn)。我現(xiàn)在仍然在做一些 Cpp 的工作，但是我更喜歡 Rust。Cargo是一個(gè)很重要的原因，其他函數(shù)式語(yǔ)言的便利也是，比如 match（而不是switch），沒(méi)有異常，以及一切都是表達(dá)式而不是語(yǔ)句。另外一個(gè)問(wèn)題是 Cpp 中錯(cuò)誤信息的質(zhì)量很差。我經(jīng)常不得不滾動(dòng)頁(yè)面很長(zhǎng)時(shí)間才能找到錯(cuò)誤的實(shí)際位置。錯(cuò)誤信息并不總是越多越好。使用一個(gè)不錯(cuò)的 Cpp 子集進(jìn)行編碼是可以的，但并不是每個(gè)人對(duì)于什么是這個(gè)不錯(cuò)的子集都有相同的理解。有些人總是會(huì)探索可能性的邊界，只為了提升自己的技能。當(dāng)你在20萬(wàn)行代碼中的某個(gè)地方遇到一個(gè)無(wú)法重現(xiàn)的核心轉(zhuǎn)儲(chǔ)，或者一個(gè)只在調(diào)試模式下工作而在發(fā)布模式下不工作的大型程序時(shí)，這真是令人沮喪。追蹤那個(gè)因?yàn)閿?shù)組操作錯(cuò)誤導(dǎo)致的偏移量問(wèn)題或其他問(wèn)題可能非常耗時(shí)。這是一類令人討厭的問(wèn)題，在安全的Rust代碼中根本不會(huì)出現(xiàn)。這就為我們留下了更多時(shí)間來(lái)解決有趣且有生產(chǎn)力的問(wèn)題。

TheReservedList：

與作者相同的開發(fā)背景：游戲開發(fā)，工作中使用Cpp；個(gè)人項(xiàng)目用的是Rust。

Cargo 是選擇 Rust 的一個(gè)重要的理由。

表達(dá)力是另一個(gè)問(wèn)題。Cpp 只需要更好的人機(jī)交互，但進(jìn)展不夠快。

對(duì) Cpp 又愛又恨。Cpp 是一門很棒的現(xiàn)代語(yǔ)言，但卻有一些愚蠢（至今）的遺留決策。

Cpp 模板比 Rust 的泛型更強(qiáng)大嗎？是的。我只是不夠聰明來(lái)進(jìn)行復(fù)雜的模板元編程，而且我認(rèn)為超過(guò)1%的 Cpp 程序員也不會(huì)。

游戲中的隨機(jī)平臺(tái)對(duì)現(xiàn)代 Cpp 的支持很糟糕，使用的是老掉牙的編譯器。這并不完全是 Cpp 的錯(cuò)，至少不完全是，我只是發(fā)泄一下。

Cpp 中編譯單元的心智負(fù)擔(dān)實(shí)在太大了。包含文件太愚蠢了，他們應(yīng)該廢棄那種編譯模型。我嘗試使用模塊，但支持還不夠。

phazer99:

這是百分之百正確的。當(dāng)你在團(tuán)隊(duì)中工作時(shí)，你會(huì)真正欣賞到Rust 及其工具相對(duì)于 Cpp（以及其他語(yǔ)言）所提供的優(yōu)勢(shì)。現(xiàn)在我在一個(gè)由所有Rust初學(xué)者組成的團(tuán)隊(duì)中，他們正在處理一個(gè)相當(dāng)龐大的代碼庫(kù)，但代碼仍然非常統(tǒng)一、易于理解和維護(hù)。Rust 編譯器（以及Clippy）真正強(qiáng)制/鼓勵(lì)每個(gè)人遵循良好的習(xí)慣和編碼風(fēng)格。很少有 unsafe 代碼，因?yàn)槊總€(gè)人都知道涉足這個(gè)領(lǐng)域的“危險(xiǎn)”。Cargo 還使處理內(nèi)部和外部依賴變得輕而易舉。

sayhisam1：

就是這樣。Cpp 有選擇性的安全性，我發(fā)現(xiàn)在實(shí)踐中這真的很困難。有沒(méi)有一本簡(jiǎn)短、易于記憶的“白癡安全Cpp”類型的書，我可以參考一下？即使有了這樣的書，我也要自己確保不會(huì)意外地寫出一些不安全的代碼。在Rust中，安全代碼是默認(rèn)的；你必須明確地將其包裝在 unsafe 的代碼塊中，并且必須意識(shí)到這一點(diǎn)。在不安全的區(qū)域之外，我?guī)缀蹩梢员ＷC不會(huì)出現(xiàn)使用后釋放錯(cuò)誤或類似的問(wèn)題。Rust 的風(fēng)格也更加一致，因?yàn)闃?biāo)準(zhǔn)庫(kù)更加合理，教程也非常棒。

zoomy_kitten：

模板是90年代的一個(gè)支撐，旨在滿足開發(fā)者在普通靜態(tài)多態(tài)和普通元編程方面的需求。Rust 的泛型和宏是我選擇 Rust 而不是 Cpp 的原因之一。毫無(wú)疑問(wèn)，模板是一個(gè)強(qiáng)大的工具，尤其是在當(dāng)時(shí)。別誤會(huì)，我并不是要冒犯 Cpp，它是一門了不起的語(yǔ)言，如果沒(méi)有 Rust，我可能會(huì)更經(jīng)常地使用它。但是與 Rust 提供的功能相比，如今它的特性相當(dāng)可憐。Cpp 是一門靠支撐物生存的語(yǔ)言，而 Rust 是一門擁有健康雙腿的語(yǔ)言。

Orthosz：

Cpp 已經(jīng)存在了大約 40 年。其他具有“現(xiàn)代”方式但保留了類似時(shí)間的舊東西的語(yǔ)言也有大量糟糕的教程。我敢打賭，在未來(lái)的30年里，Rust 會(huì)有糟糕的教程，教授一種混合了舊方式、新近方式和新方式的內(nèi)容，因?yàn)?Rust，就像 Cpp、Java和其他系統(tǒng)語(yǔ)言一樣，承諾向后兼容。

TheReservedList>Orthosz:

永恒的向后兼容性，就像 Cpp 那樣，從長(zhǎng)遠(yuǎn)來(lái)看永遠(yuǎn)行不通，每一種語(yǔ)言都注定會(huì)失敗。起初我以為這就是版本的意義，但似乎對(duì)于這樣一門年輕的語(yǔ)言來(lái)說(shuō)，改變已經(jīng)存在很多猶豫。

Orthosz：

這將讓每個(gè)人都感到不舒服，而且應(yīng)該如此：constexpr、模板元編程和預(yù)處理器宏讓你以一種弗蘭肯斯坦怪物的方式做出真正令人驚嘆和可怕的事情。

harmic：

另一個(gè)關(guān)鍵因素：在許多情況下，C++編譯器的錯(cuò)誤信息非常糟糕。想象一下，從你錯(cuò)誤使用的某個(gè)模板庫(kù)深處涌出一大堆無(wú)意義的內(nèi)容。Rust編譯器的錯(cuò)誤信息通常非常出色，甚至經(jīng)常提供修復(fù)問(wèn)題的建議。

dkopgerpgdolfg：

不，Rust并不能解決所有問(wèn)題。我猜寫一部分現(xiàn)代C++代碼可能會(huì)很不錯(cuò)。但這并不是我來(lái)到Rust營(yíng)地的主要原因。相反，最迫切的原因是因?yàn)?Cpp"并不等同于"現(xiàn)代Cpp的子集"。如果我能“寫”出漂亮的Cpp，但人們?nèi)匀荒軌驅(qū)懗?80頁(yè)的書來(lái)解釋變量初始化，那對(duì)我有什么幫助呢？代碼也需要被“閱讀”。包括那些不符合個(gè)人偏好的代碼。Cpp確實(shí)非常有用。但它也變得非常復(fù)雜，有時(shí)候我不明白為什么我要繼續(xù)朝這個(gè)方向發(fā)展——越來(lái)越多的時(shí)間花在查找標(biāo)準(zhǔn)、缺陷報(bào)告等符號(hào)上，而不是編寫有用的代碼。Rust 也不完全擺脫這個(gè)問(wèn)題，但兩者之間有天壤之別。

KnorrFG：

在Rust出現(xiàn)之前，C++曾經(jīng)是我首選的編程語(yǔ)言。不過(guò)現(xiàn)在我不再使用它了，除非是在嵌入式領(lǐng)域。我從來(lái)沒(méi)有在內(nèi)存管理方面遇到太多困難，但項(xiàng)目配置和依賴關(guān)系真是讓人煩惱。我使用過(guò)makefiles、scons、cmake和Visual Studio，它們各有各的煩人之處。尤其是與Cargo相比。總的來(lái)說(shuō)，使用包含方式處理多個(gè)文件是一種糟糕的方法。我仍然記得花了兩天時(shí)間搜索一個(gè)錯(cuò)誤，因?yàn)橐粋€(gè)頭文件中的定義覆蓋了一個(gè)無(wú)關(guān)依賴項(xiàng)中的函數(shù)。我真的很煩迭代器的管理。到處都是.begin()和.end()...太丑陋而啰嗦了。哦，還有模板錯(cuò)誤...然后在Rust中有一些非常吸引人的東西：代數(shù)數(shù)據(jù)類型、問(wèn)號(hào)運(yùn)算符、Cargo以及大部分自動(dòng)類型推斷。單獨(dú)來(lái)看，這些都不算什么，但是所有因素的結(jié)合使得 Rust 對(duì)我來(lái)說(shuō)顯然更具吸引力。

adwhit2：

我不明白為什么有人經(jīng)歷過(guò)帶有和類型的語(yǔ)言后，還會(huì)愿意回到?jīng)]有和類型的語(yǔ)言。這就像是用一只手綁在背后進(jìn)行編碼。

C++現(xiàn)在有std::variant了，但是在人機(jī)交互方面，它與Rust的枚舉和模式匹配相比還有很大差距。

std::visit是match的一個(gè)糟糕的替代品。最具體地說(shuō)，在一個(gè)match的情況下，我可以continue/break/return，因?yàn)檫@個(gè)match與match處于相同的函數(shù)上下文中...然而，在std::visit中的lambda函數(shù)中，我不能...因此，我需要將continue/break/return重新定義為一個(gè)結(jié)果值（或標(biāo)志），然后在std::visit之后根據(jù)它進(jìn)行分支。當(dāng)人們贊揚(yáng)某種類型時(shí)，他們實(shí)際上贊揚(yáng)的是模式匹配 :)

safdwark4729：

Rust目前缺乏特化和反向類型 trait，可以說(shuō)這是Rust與Cpp不同的一個(gè)差距，類似于和許多其他Rust特性一樣。當(dāng)然，我仍然認(rèn)為實(shí)際的泛型是比模板更好的選擇，只是恰好這些特性對(duì)于高性能代碼和甚至安全性（單位……你現(xiàn)在在Rust中很難做到這一點(diǎn)，也有其他原因）非常重要，并且在庫(kù)生態(tài)系統(tǒng)和常量泛型之后，它們是阻止我在Rust中做更多事情的最大問(wèn)題之一。

忽略自身不斷完善的庫(kù)生態(tài)系統(tǒng)，Rust 需要（或等效功能/或使其變得無(wú)關(guān)）：

Specialization 特化

Negative Type traits 反向類型 trait

Static assert靜態(tài)斷言

Placement New

用戶自定義字面量

據(jù)我所知，所有這些都正在進(jìn)行中/將來(lái)的工作計(jì)劃中，但其中一些我現(xiàn)在需要，就像現(xiàn)在這樣，并且與Rust的愿景相一致。

randompittuser:

我已經(jīng)使用C++二十年了，Rust使用了一年。我可能會(huì)因?yàn)槲业挠^點(diǎn)而遭受r/rust的憤怒，但是我還是要說(shuō)：對(duì)于有經(jīng)驗(yàn)的 Cpp 開發(fā)者來(lái)說(shuō)，Rust并沒(méi)有太多吸引力，但并非每個(gè)人都是有經(jīng)驗(yàn)的 Cpp 開發(fā)者。Rust 的最大優(yōu)勢(shì)之一是將許多運(yùn)行時(shí)/內(nèi)存錯(cuò)誤轉(zhuǎn)移到編譯時(shí)。為了實(shí)現(xiàn)這一點(diǎn)，與 Cpp 相比，它對(duì)類型及其使用的假設(shè)進(jìn)行了限制，使得 Rust 更冗長(zhǎng)（盡管可能更具表達(dá)力），尤其是在高級(jí)用例中。然而，請(qǐng)考慮到 Rust 相對(duì)于 Cpp 還處于起步階段，我相信在未來(lái)十年內(nèi)，它有潛力超越 Cpp，在新項(xiàng)目中得到更廣泛的應(yīng)用。考慮到這一切，我會(huì)說(shuō)學(xué)習(xí)兩者都是不錯(cuò)的選擇。

Cpp 頻道的評(píng)論

msqrt：

我曾經(jīng)簡(jiǎn)單嘗試過(guò) Rust。確實(shí)，知道編譯器可以在很多錯(cuò)誤發(fā)生之前就捕捉到它們，這讓人感到非常放心。但就個(gè)人而言，這并不足以讓我放棄我已經(jīng)相當(dāng)熟悉的語(yǔ)言，轉(zhuǎn)而去學(xué)習(xí)一門需要付出相當(dāng)努力的新語(yǔ)言。我覺得C++在不久的將來(lái)可能會(huì)失去很多地位，但我并不急于成為這個(gè)過(guò)程中的早期采用者。我會(huì)先看看情況如何發(fā)展。

Sudden_Job7673：

C++面臨的一個(gè)重大挑戰(zhàn)是，在互聯(lián)網(wǎng)時(shí)代之后，它的發(fā)展機(jī)制無(wú)法像其他生態(tài)系統(tǒng)那樣快速改進(jìn)。缺乏一個(gè)能夠在編譯時(shí)檢測(cè)到可能導(dǎo)致錯(cuò)誤的機(jī)制，對(duì)于什么是C++的慣用方式缺乏共識(shí)（是否包括異常處理？），缺乏一個(gè)被廣泛采用的不穩(wěn)定C++版本來(lái)嘗試新的理念，以及二進(jìn)制穩(wěn)定性使得一旦某個(gè)特性進(jìn)入標(biāo)準(zhǔn)后很難進(jìn)行修正。

jgaa_from_north：

變化的速度和范圍是我現(xiàn)在更加關(guān)注 Rust 的原因之一。這是我暑假的“項(xiàng)目”。當(dāng)C++發(fā)生變化時(shí)，你被認(rèn)為應(yīng)該理解新的方式和舊的方式。你需要了解的內(nèi)容總量在這個(gè)已經(jīng)相當(dāng)復(fù)雜的語(yǔ)言中以很高的速度增加。我并不羨慕那些今天學(xué)習(xí)C++的人。

此外，這些變化并未解決C++中一些最緊迫的問(wèn)題，比如缺乏標(biāo)準(zhǔn)的構(gòu)建系統(tǒng)、標(biāo)準(zhǔn)的軟件包管理器或倉(cāng)庫(kù)基礎(chǔ)設(shè)施。當(dāng)一個(gè)項(xiàng)目不斷發(fā)展時(shí)，管理常常沖突的遞歸依賴關(guān)系是一種痛苦。自1996年以來(lái)，我一直將C++作為我的主要編程語(yǔ)言。我可能已經(jīng)寫了超過(guò)一百萬(wàn)行的C++代碼。我仍然比我使用過(guò)的任何其他編程語(yǔ)言更喜歡C++。我的觀點(diǎn)是，標(biāo)準(zhǔn)中的變化/創(chuàng)新是一把雙刃劍。

guyinnoho：

Rust 是較新的。再給它十年，然后再比較。

dzordan33：

在 Rust 生態(tài)系統(tǒng)中，低門檻是一個(gè)巨大的優(yōu)勢(shì)。在我看來(lái)，雇傭那些能夠并愿意學(xué)習(xí) Rust 的聰明程序員要比經(jīng)驗(yàn)豐富的 C++ 開發(fā)者更容易。根據(jù)我的經(jīng)驗(yàn)，你不必是一個(gè) Rust 專家才能高效工作。

darth_chewbacca:

你好，我來(lái)自這個(gè)討論主題的 Rust 版塊。請(qǐng)不要惡意攻擊。我曾經(jīng)是一名 C++ 開發(fā)者，最后接觸的版本是 C++17。我最喜歡的語(yǔ)言是 Rust，但我仍然喜歡 C++。

對(duì)于一個(gè)熟悉“現(xiàn)代C++”并且是資深C++開發(fā)人員來(lái)說(shuō)，學(xué)習(xí)Rust并不太困難。在之前的雇主那里，我?guī)椭嘤?xùn)了幾位C++開發(fā)人員（還有一位經(jīng)驗(yàn)豐富的Java開發(fā)人員），他們學(xué)習(xí)起來(lái)并不困難。但是C開發(fā)人員、C#開發(fā)人員以及Python/JavaScript開發(fā)人員確實(shí)遇到了一些困難。

C++和Rust比大多數(shù)其他廣泛使用的編程語(yǔ)言更相似。現(xiàn)代C++在用法上可能比原始的C更接近Rust。對(duì)你來(lái)說(shuō)，學(xué)習(xí)曲線可能沒(méi)有其他嘗試Rust的人那么陡峭。

當(dāng)你聽到關(guān)于Rust學(xué)習(xí)曲線的抱怨時(shí)，這些抱怨通常不是來(lái)自以前的C++開發(fā)者。

nihilistic_ant：

很長(zhǎng)一段時(shí)間里，Java一度被認(rèn)為會(huì)取代C++。Sun公司用Java編寫了一個(gè)操作系統(tǒng)，而Netscape則將他們的瀏覽器移植到了Java上。后來(lái)，我記得有一段時(shí)間Go語(yǔ)言被認(rèn)為會(huì)取代C++，但回想起來(lái)，這種說(shuō)法并沒(méi)有多大意義，盡管當(dāng)時(shí)看起來(lái)似乎很有道理。除了這些大型語(yǔ)言之外，還有很多其他流行的語(yǔ)言，人們常常問(wèn)為什么項(xiàng)目選擇使用C++而不是它們，盡管它們當(dāng)時(shí)很熱門，比如D語(yǔ)言或者Scala，雖然現(xiàn)在它們已經(jīng)被人們遺忘，但在一段時(shí)間內(nèi)它們占據(jù)了很多人的關(guān)注。

也許Rust會(huì)真的做到。也許Zig會(huì)。也許幾年后會(huì)有一些東西開始。很難說(shuō)。

總的來(lái)說(shuō)，我不羨慕那些總是追逐最新編程語(yǔ)言和框架的程序員。（幾年前對(duì)他們來(lái)說(shuō)尤其艱難，因?yàn)樗麄儾坏貌辉诙潭處啄陜?nèi)學(xué)習(xí)了大約6個(gè)JavaScript框架，以跟上潮流。）他們的代碼最終變得難以維護(hù)，因?yàn)闀?huì)有各種用不再流行的語(yǔ)言或框架編寫的系統(tǒng)存在。

無(wú)論如何，如果Rust或Zig真的能夠主宰世界，我會(huì)很高興轉(zhuǎn)向它們。但對(duì)我個(gè)人來(lái)說(shuō)，等待幾年看看是否真的如此是有道理的。

像Rust這樣的新語(yǔ)言的一個(gè)問(wèn)題是，它們的用戶都是決定使用最新、最酷的語(yǔ)言的程序員。這意味著，如果有什么新東西出現(xiàn)，他們的用戶很可能會(huì)轉(zhuǎn)投他。而那些仍然使用C++進(jìn)行編程的人在很多次之前都選擇了不轉(zhuǎn)投其他語(yǔ)言，所以我相信這門語(yǔ)言至少會(huì)在相當(dāng)長(zhǎng)的時(shí)間內(nèi)相當(dāng)受歡迎。

laralex：

我對(duì)C++的三大痛點(diǎn)是：

每個(gè)角落都潛伏著大量無(wú)聲的UB（未定義行為），即使對(duì)于經(jīng)驗(yàn)豐富的程序員來(lái)說(shuō)，也很難記住它們

庫(kù)管理不足

混亂的標(biāo)準(zhǔn)庫(kù)以非常丑陋的方式包裝了舊錯(cuò)誤（但仍保持向后兼容）然而，我覺得僅僅淘汰C++還不夠，因?yàn)樵诖笮?a target="_blank">科技公司中，選擇C++是一個(gè)顯而易見的選擇，這也是在職業(yè)生涯中提升的難題，沒(méi)有掌握C++是很難有進(jìn)展的。Rust仍然被視為一只昂貴的獨(dú)角獸，轉(zhuǎn)向它可能代價(jià)過(guò)高。

monsoon_winds：

哥們兒，現(xiàn)代C++可以避免老版本C++的問(wèn)題，但只要向后兼容性存在，老版本C++仍然存在。在編寫C++代碼時(shí)，你需要一直積極地避免這些問(wèn)題，直到你的生命結(jié)束。而Rust則默認(rèn)提供了你所需要的，你需要主動(dòng)選擇進(jìn)入不安全模式，才會(huì)出現(xiàn)問(wèn)題。

把自己（或任何有經(jīng)驗(yàn)的程序員）看作是一個(gè)無(wú)法寫出任何錯(cuò)誤的編程之神，這種想法實(shí)在是愚蠢的。我會(huì)在這里鏈接到cpp2的演講[2]，Herb在其中用簡(jiǎn)單的話解釋了這個(gè)問(wèn)題。

正如你所提到的，shared_ptr和一些現(xiàn)代特性確實(shí)有所幫助，但它仍然只是對(duì)這個(gè)巨大的UB潛在問(wèn)題的臨時(shí)解決辦法。即使是像Cherno（著名的YouTuber）這樣經(jīng)驗(yàn)豐富的游戲引擎開發(fā)者，也不得不花費(fèi)數(shù)小時(shí)進(jìn)行調(diào)試，最終才發(fā)現(xiàn)在一個(gè)for-each循環(huán)中，他們無(wú)效化了迭代器 :D

你對(duì)“有經(jīng)驗(yàn)的程序員”的定義也不具體可行。如果谷歌/微軟這樣擁有龐大預(yù)算的公司都無(wú)法保持軟件質(zhì)量，那么其他隨機(jī)公司又有什么機(jī)會(huì)呢？

tiajuanat:

請(qǐng)記住，我是一個(gè)有7年最近活躍的C++編程經(jīng)驗(yàn)的新手，但我?guī)缀跻簧荚谝阅撤N方式進(jìn)行編程。

我有些猶豫，但不得不說(shuō)Rust自帶了許多很棒的功能，而C++在這方面還遠(yuǎn)遠(yuǎn)無(wú)法媲美。Conan、CMake、Doxygen、Catch/Doctest/GTest，Rust都有自己的系統(tǒng)來(lái)處理這些，而且還有更多其他功能。

有一些地方是痛苦的。所有權(quán)并不總是一帆風(fēng)順的，在與其他C++開發(fā)人員合作編寫Rust代碼時(shí)，會(huì)出現(xiàn)“正確方式”和“Rust方式”的爭(zhēng)論。上個(gè)月，我與人合作開發(fā)串行協(xié)議時(shí)，弄清楚哪個(gè)系統(tǒng)“擁有”串行端口并不容易，最后使用了一個(gè)奇怪的弱指針。

Rust有一些不完美的地方嗎？絕對(duì)有。事實(shí)上，我認(rèn)為沒(méi)有這些不完美的地方，你就無(wú)法擁有一種適用于工業(yè)系統(tǒng)的編程語(yǔ)言。然而，我很少感覺到與Rust 的斗爭(zhēng)，而且我已經(jīng)積極地使用 Rust 幾個(gè)月了；而在C++中，我花了七年的時(shí)間才達(dá)到這個(gè)水平。

本文結(jié)語(yǔ)

你不能只是把一本 Rust書放在開發(fā)人員手上，希望通過(guò)知識(shí)滲透讓他們學(xué)習(xí)到 Rust 所有權(quán)。