5月安卓手機好評榜：魅族20 Pro奪冠
性能榜和性價比榜之后，我們來看最后的安卓手機好評榜，數據來源安兔兔評測，收集時間2023年5月1日至5月31日，僅限國內市場。第一名：魅族20 Pro好評率：97.50%不得不感慨魅族老品牌還
作者 | Kevin Scott
策劃 | 言征
Rust是一門極具爭議性的語言。有許多創業公司的開發者甚至創始人都點名表示：Rust是巨坑！簡直浪費時間。再比如，其他語言中的“粗糙編碼”的編程方式在Rust中也很難實現；庫和文檔也不夠成熟，學習起來相當費勁，諸如此類。
但總的來說，在強調“安全性比開發生產力更重要”的今天，Rust從來沒有失去成為一種未來語言的資格。雖然正視缺點很重要，但有些草率的批評也許未必是真相，或者說是不準確的。
本文為大家呈現一篇“不偏不倚”的Rust的真實特性。
Rust 是一種系統編程語言。它提供對數據布局和代碼運行時行為的精確控制，為提供最大的性能和靈活性。與其他系統編程語言不同，它還提供內存安全性——有缺陷的程序以明確定義的方式終止，而不是表現出（潛在的安全威脅）未定義的行為。
然而，在大多數情況下，人們不需要終極性能或對硬件資源的極端控制。在這種情況下，像 Kotlin 或 Go 這樣的現代可管理語言，提供的速度也不錯，性能也令人滿意，并且由于具有垃圾收集器的動態內存管理而保證了內存安全。
程序員的時間是寶貴的，如果選擇了 Rust，預計會花一些時間學習各種使用技術。Rust 社區投入了大量時間來創建各種高質量的教程，但 Rust 語言非常龐大。
即使 Rust 可以為你提供價值，你可能也沒有太多精力投入到提高你的語言專業知識上。要知道，Rust 增強控制力是有代價的：選擇變得有講究了。
struct Foo { bar: Bar }struct Foo < 'a > { bar: & 'a Bar }struct Foo < 'a > { bar: & 'a mut Bar }struct Foo { bar: Box <Bar> }struct Foo { bar : Rc<Bar> }struct Foo { bar: Arc<Bar> }在 Kotlin 中，開始類 Foo(val bar: Bar) 并繼續解決業務問題。在 Rust 中，需要做出一些選擇，其中一些選擇非常重要，需要專門的語法。
所有這些復雜性的存在都是有原因的——我們不知道如何創建更簡單的內存安全的低級語言，盡管并不是每個任務都需要用低級語言來解決。
漫長的編譯時間往往會壓垮每一位程序員。用運行速度較慢但編譯速度較快的編程語言編寫的代碼，通常更有機會運行得更快，因為程序員有更多時間來優化代碼。
Rust 在通用性難題中故意選擇了緩慢的編譯器。這不一定是世界末日（因為由此產生的運行時性能增益是真實的），但這確實意味著在較大的項目中，開發者將不得不努力爭取合理的構建時間。
rustc 實現了生產編譯器中可能最先進的增量編譯算法，但這感覺有點像與語言編譯模型作斗爭。詳情可以移步這篇官網：
https://rustc-dev-guide.rust-lang.org/queries/incremental-compilation .html
與 C++ 不同，Rust 構建并沒有笨拙地并行化，并行度受到依賴圖中關鍵路徑長度的限制。如果有 40 個以上的內核進行編譯，則會顯示此信息。
Rust 還缺乏類似 pimpl 的功能，這意味著更改 crate 需要重新編譯（不僅僅是重新鏈接）其所有反向依賴項。
Rust 只有 8 年的歷史，相較而言，Rust還算一門年輕的語言。創建這個新語言的目的是為了解決一個頑疾：軟件的演進速度大大低于硬件的演進，軟件在語言級別上無法真正利用多核計算帶來的性能提升。
根據林迪效應，相信“C++ 將在未來十年內存在”的人要遠多于對“Rust 將在十年內存在”的人。同樣地，如果你編寫的軟件可以使用數十年，在選擇新技術之前，往往會再三考慮與之相關的風險。
但慎重考慮并不代表放棄新技術。一個過去的案例就是，在 90 年代為銀行軟件選擇 Java 而不是 Cobol 事實證明是正確的選擇）。
Rust 目前只有一種完整的實現——rustc 編譯器。另一個最佳替代實現，mrustc，有意省略了許多靜態安全檢查。rustc 目前僅支持一種生產就緒后端 - LLVM。因此，它對 CPU 架構的支持范圍比 C 語言更窄，后者具有 GCC 實現以及許多特定于供應商的專有編譯器。
最后，Rust 缺乏官方規范。參考文檔正在開發中，尚未記錄實現的所有細節。
在系統編程領域，除了 Rust 之外，還有其他一些語言，主要是 C、C++ 和 Ada。
現代 C++ 提供了提高安全性的工具和指南，甚至有人為C++提出了類似 Rust 的生命周期機制。但與 Rust 不同，使用這些工具并不能保證沒有內存安全問題。但是，如果你已經維護了大量 C++ 代碼，那么檢查以下最佳實踐和使用清理程序是否有助于解決安全問題是有意義的。這很困難，但顯然比用另一種語言重寫它要容易。
如果你使用C，你可以使用形式化方法來證明不存在未定義的行為，否則你只能詳盡地測試一切。如果不使用動態內存（切勿調用 free），Ada 是內存安全的。
Rust 偏偏是成本/安全曲線上的一個有趣的權衡點，但肯定不是唯一的不可替代的點。
Rust 工具是值得點贊叫好的?；€工具、編譯器和構建系統（cargo）通常被認為是一流的。
但是，例如，一些與運行時相關的工具（尤其是堆分析）目前還不存在——如果沒有運行時工具，就很難分析程序的運行時。此外，雖然 IDE 支持不錯，但它還遠未達到 Java 級別的可靠性。如今，在 Rust 中不可能自動復雜地重構數百萬行程序。
“使用 LLVM”并不是解決所有性能問題的通用方法。雖然我不知道 C++ 和 Rust 的大規模性能基準，但不難列出一些 Rust 不如 C++ 的性能問題。
最大的一個可能，是 Rust 的移動語義是基于值的（機器代碼級別的 memcpy）。相比之下，C++ 語義使用特殊引用（機器代碼級別的指針），可以在其中處理數據。
理論上，編譯器應該能夠看穿復制鏈，但實際上卻常常做不到。要知道， 一個相關的問題是不放置新的——Rust 有時需要從堆棧復制字節，而 C++ 可以就地構造東西對象。
有趣的是，為了使其盡可能高效而不穩定，Rust 的默認 ABI有時比 C 更糟糕。
圖片
最后，雖然理論上 Rust 代碼應該由于更豐富的別名信息而更加高效，但啟用與別名相關的優化可能會導致 LLVM 錯誤和錯誤編譯。
但是，重申一下，這些都是個例，有時的情況恰恰相反。例如，Rust 的 Box 中不存在 std::unique_ptr 的性能問題。一個潛在的更大問題是 Rust 的定義時檢查泛型不如 C++ 那樣富有表現力。因此，一些高性能的 C++ 模板技巧很難在 Rust 中用漂亮的語法來表達。
也許跟“所有權”和“借用”相比，更核心的問題是不安全（Unsafe）的邊界。通過界定Unsafe塊和函數后面的所有不安全操作，并為它們提供安全的上層接口，可以創建一個兼具以下功能的函數：
一、可解釋（非不安全（non-unsafe）的代碼不會導致未定義的行為）。二、模塊化（可以單獨檢查不同的不安全塊）。
顯然，這個承諾已經在實踐中得到了證實：有bug的 Rust 代碼不會造成緩沖區溢出。
當然，問題沒那么簡單，也不那么樂觀。
首先，Rust 的內存模型沒有定義，因此無法正式檢查給定的不安全塊是否有效。對于“rust-c 做什么或可能依賴什么”，有非正式的定義，運行時驗證器正在開發中，但實際模型正在不斷變化。因此，可能有一些unsafe的代碼，今天雖然在實踐中可用，但明天就可能會被聲明為無效，并且在明年就會被新的編譯器優化所破壞掉。
其次，據業內開發者的觀察結果是，unsafe實際上并不是模塊化的。足夠強大的不安全塊實際上可以擴展語言。兩個這樣的擴展，單獨使用時可能沒問題，但如果一起使用，可能會導致未定義的行為、觀察到的等效性和不安全的代碼。
原文鏈接：https://medium.com/@kevin_scott_/why-not-rust-1d257c6a07da
本文鏈接：http://m.rrqrq.com/showinfo-26-5141-0.htmlRust“巨坑”？真相來了！
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 從 Java 11 遷移到 Java 17 值得嗎？
下一篇： 三言兩語說透設計模式的藝術-原型模式
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號