Rust能讓我寫出好的程式碼 - Reddit

banq發表於2022-10-26
Rust

Java是 "強型別 "的，但來自java這種督促並沒有讓我的程式碼結構變得更好。例如，Java能讓你使用UnsignedInteger型別，但人們通常不會使用它。相反，建立“類”的感覺是很麻煩的，有很多模板。

Rust的獨特之處在於它強迫你一次只能有一個可變的“引用”，但我懷疑僅憑這一點就能讓你構建出偉大的程式碼。反而那些透過缺少“引用”來避免這種情況的語言，並不能讓我寫出好的程式碼。

我確實注意到Rust是完全不含糊的，這有助於我思考某些最佳化問題。但是，這仍然不足以讓我寫出偉大的程式碼。

看起來，多種此類屬性的結合使Rust促使使用者寫出更好的程式碼。我已經意識到，在用其他語言編碼時，我有點像 "crack到它能用為止"。在執行時測試，沿途修復任何錯誤。Rust似乎給了我一個備選方案，以涵蓋各種邊緣情況，而不需要執行它們。

現在我已經達到了這樣的程度：當我在工作中得到一個任務時，我可以先用Rust寫出來，並確保編譯器滿意--我甚至不需要執行程式碼，只是編譯就夠了--然後把程式碼翻譯成我的目標語言。這樣一來，我就避免了 "crack它直到成功 "的環節，因為它就是成功的。

不知何故，在與 Rust 編譯器鬥爭時，“crack它直到它工作”變成了“重寫它直到它結構良好”。就像他們構建了你如何與編譯器對抗一樣，所以它不再是一個駭客。

這裡的關鍵見解是，嚴格控制記憶體所有權通常會產生更好的程式碼。目標不是強迫程式設計師編寫更好的程式碼，但更好的程式碼通常是記憶體安全的。具有相同目的的事物傾向於共享相同的生命週期、作用域等。

我發現非同步程式設計更是如此。如果您可以在函式呼叫和記憶體執行緒中保持安全，那麼您可以在併發和並行程式碼中保持安全。

我記得在 2010 年代，有多少 js 開發者抱怨“回撥地獄”之類的東西。事實是，如果您無法在非同步呼叫中推理記憶體安全性，在深度巢狀的閉包作用域內捕獲大量可變變數，那隻會是地獄般的。每個人都認為 Promises 拯救了它們，但如果舊程式碼庫讓所有東西預設不可變，它們的大部分問題可能會消失。

Rust透過使錯誤的事情變得更加困難來激勵做正確的事情。

很難確定究竟是什麼讓 Rust 在設計程式碼方面做得更好，但我想到了一個列表：
  1. 資料優先——Rust 有資料優先的方法，而其他程式語言有“類優先”或“函式優先”的方法。這可能會影響我們從一開始就進行程式碼設計的方式，併成為關注最重要的資料結構的強制因素。
  2. 缺乏繼承——起初這對我來說很難，但這是我們都需要洗的冷水澡。乾淨的結構和列舉/變體模型使事情變得更加直接和明確，簡化了未來的程式碼。有時它仍然感覺缺失，但它可能只是一個遺留的習慣。
  3. Orientation Dogma Free - 與 2 相關，但在拒絕 OOP 之後，Rust 甚至沒有嘗試跳入 FP 教條。我認為 FP 正在重複 OOP 所犯的許多錯誤。時間會證明一切，但我預測幾年（或更早）會出現 FP 疲勞。並不是說某些函式式正規化沒有前途，Rust 應該有更多，但教條式的做法適得其反。
  4. 匹配模式——整個匹配模式改變了我的程式設計風格，每個分支都是意圖驅動的，而不是一些語言強制分支的必要性。
  5. 模組系統- 模組的直觀資料夾結構，同時仍然允許完全的靈活性，並記住模組應該匯出多個結構，甚至允許重新匯出以隱藏下游佈局細節。這個模組系統有很多。
  6. 端到端工具鏈- 從單元測試（具有私有訪問許可權）、整合測試、示例、文件，甚至完全融入基準測試。這有助於我們做我們早就應該關心的事情。


Rust 並不一定會讓你寫出“更好”的程式碼。它促使您編寫更多面向編譯時的程式碼，而不是面向執行時的程式碼。這使得編寫面向執行時的程式碼變得困難，並且由於面向編譯時的程式碼更適合靜態分析，因此您可以更早地發現錯誤。
有許多軟體工程和演算法問題可能在面向編譯時的程式碼之外有最好的解決方案，但對於大多數人來說，大多數時候（在 leetcode 之外）大多數問題，他們最好編寫面向編譯時的解決方案。

相關文章