並非所有內容都會用 Rust 重寫，因此 C++必須變得更安全，我們都應該關心 C++ 變得更安全。
越來越明顯的是，不僅許多程式設計師看到了記憶體安全的好處，政策制定者也看到了。“記憶體安全”的概念已經從程式語言的建立者和使用者在討論中使用的技術術語變成了消費者報告和白宮所熟知的術語。
許多現有的流行語言至少在部分上已經是記憶體安全的。事實上，美國政府於 2023 年 12 月釋出的“記憶體安全路線圖案例”將 C♯、Go、Java、Python 和 Swift 列為記憶體安全語言，所有這些垃圾收集語言都覆蓋了當今大量的裝置。
- C♯ 是具有 .NET 執行時的 Windows 機器中非常流行的語言，
- Go 用於許多 Web 伺服器和流行雲主機執行的“雲原生”軟體，
- Java 是 Android 的語言，也是大型企業使用的大量廣泛部署的軟體，
- Python 是當今許多資料科學應用程式最流行的語言，
- Swift 是當今所有 iOS 應用程式的推薦語言（儘管 Objective-C 仍然受到支援和廣泛使用）。
所有這些語言都已經提供了有意義的記憶體安全，
Rust 在垃圾收集不被普遍接受的環境中實現了記憶體安全，因此需要垃圾收集的語言通常不會被採用。在這些領域，絕大多數現有程式碼都是用 C 或 C++ 編寫的。
我們能否將程式碼從 C 或 C++ 重寫為 Rust，從而獲得以前無法實現的記憶體安全優勢？Rust 社群內外都流傳著一個笑話：對於任何專案，人們都應該用 Rust 重寫它，Rust Evangelism Strike Force隨時準備向其觀察到的任何專案提出這一建議，尤其是在出現與記憶體安全相關的漏洞時。
如果您不大量重寫程式碼，而是定期修復錯誤，那麼隨著時間的推移，程式碼中的漏洞數量就會減少。(前提是：修復的同時不能引入新bug，只有上帝和完美主義者才能做到)
C++ 必須變得更加安全
如何讓 C++ 更安全”這一類別目前有四個陣營：
- 合約contracts
- 個人資料profiles
- 後繼語言
- 借用檢查borrow checking
這是對最近的 C++ 標準委員會會議關於進一步探索 C++ 記憶體安全機會的投票的回應。
Circle是 Sean Baxter 的語言，是 C++ 的“超集的子集”。這意味著您可以將有效的現有 C++ 程式碼與使用 C++ 的安全擴充套件編寫的程式碼混合使用，後者類似於C++，但設定了限制以加強記憶體安全。
Carbon是“C++ 的實驗性繼任者”，旨在以更高的安全性與 C++ 進行互操作（儘管明確旨在提供比 Rust 更少的安全保證）。用 Carbon 編寫的程式碼不是有效的 C++ 程式碼，但用 Carbon 編寫的程式碼旨在能夠輕鬆呼叫 C++，並被 C++ 程式碼輕鬆呼叫。
cppfront由 Herb Sutter 開發，是 C++ 的一種實驗性語法，可編譯為“真正的” C++，本質上旨在讓您更輕鬆/預設地編寫更安全的 C++ 程式碼，同時減少需要記住不要開火的陷阱。