對Rust的不好看法 - chrisdone

好的看法
Rust 的宏非常好。它們的作用類似於 Lisp 的宏，與 Haskell 的不同。
Rust 具有型別類（“traits”）和和型別（“enums”）和模式匹配這一事實非常有吸引力。使例項在包範圍孤立而不是模組範圍是一個非常好的決定。
我也喜歡它對記錄的處理。
它的標準庫在一些方面做得很好，比如將字串處理為 UTF-8。
區分可變性有其優點，很容易看出一個函式是“道德上”純的——如果不是實際上純的——這有利於閱讀。
 

糖好嗎？
Rust 使用了神奇的糖結構，編譯器會自動為你插入解引用、複製、克隆和刪除，它具有最初吸引人的“底層很簡單”的品質，但在實踐中這會導致錯誤的編譯錯誤：編譯錯誤是編譯器一種它為你生成的東西的抱怨，而不是直接抱怨寫的東西。
這可以與 Haskell 使用提供語法糖的 monad 進行比較。你引入的魔法越多，新手就越難學習和談論。
  

對高效記憶體表示的迷戀
人們試圖理解為什麼他們完全合理的程式碼不適合 Rust 嚴格的記憶體限制？
不是技術不好用，而是你用錯了。
在實踐中，人們只是希望能夠編寫一個樹狀型別，而不必與編譯器下棋。我預測垃圾收集器最終會在 Rust 中流行起來。
這既是 Rust 的主要目標——像 C 一樣，但安全——也是它的主要缺點。人們將時間浪費在永遠不會產生效果的瑣事上。
  

unsafe
unsafe 的使用有點令人不安，因為每個庫都有它。但這與使用 FFI 沒有太大區別。我不認為這是一個很大的缺點。
 

重寫謬誤
重寫謬誤
我看到很多“我們用 Rust 重寫 X 並且它變得更快”的帖子。我認為，如果您在考慮效能的情況下從頭開始重寫任何內容，您將看到顯著的效能改進。我懷疑 Rust 本身的需要程度，與具有某些效能潔癖的開發人員相比，哪個更主要？
 
“友好”社群
所有新的語言社群都很好。當事情無關緊要時，人們沒有理由生氣。
一旦人們對某事持有利害關係，那就是事情升溫和發脾氣的時候。您可以透過在其中編寫大量程式碼或在其上建立業務來獲得程式語言的股份。當您對一門語言的工作方式感興趣時，您對可能使您做的工作超出需要或限制您的目標的變化非常敏感。
我已經看到了 Haskell 的情況。2007 年左右，當我開始使用 Haskell 時，社群對任何事物都很友好，福音派的，開放的。人們為此稱讚它。每個人都感到很幸運能夠使用這種令人興奮的語言。今天，它更像任何其他社群。發生了什麼？人們開始真正使用 Haskell，僅此而已。
Rust 正在經歷同樣的事情，而且速度要快得多。這是避免 Rust 的理由嗎？不會。但是“友好”的社群也不是加入即將到來的語言的理由。
 

非同步問題很大
非同步引入了長時間的、激烈的討論。
Rust 的問題是它的使用者想要一個執行時，但想要一個沒有執行時的選項。結果一團糟。
總的來說，我認為 Go、Erlang 和 Haskell 在這裡做出了更好的選擇。垃圾收集器和綠色執行緒使程式設計師的工作效率更高。
 

作為通用語言
我覺得 Rust 被定義為一種“系統”語言，但它被用來編寫 Web 應用程式和命令列工具以及各種東西。
這有點令人失望，但也是可以預見的：你的語言越成功，就會有越多的人將你的語言用於它不適合的事情。