爲什麼使用 Golang 而非 Rust 開發桌面應用？

MoonGuard 團隊選擇 Golang 而不是 Rust 作爲他們的 Krater 桌面應用程序，因爲 Golang 中更容易進行內存管理、類型安全和 ORM 支持。

使用 Rust 和 Tauri 時面臨的一些挑戰包括：

• 難以理解 Rust 的所有權和借用規則、

• 其嚴格的類型安全有時會限制開發速度、

• 難以爲 SQLite 找到合適的 ORM，

• 以及測試非常複雜。

項目進行到大約 65% 時，團隊仍在努力完成需要 Rust 代碼的剩餘功能。但是使用 Wails 遷移到 Golang 使他們能夠在一個週末內移植幾乎所有的進展。

Golang 的垃圾收集、用於併發的 Goroutines、更簡單的靜態類型、GORM ORM 的可用性以及由於其年齡而更大的生態系統比 Rust 更適合該項目。

這個桌面應用 Krater 是一個跨平臺應用程序，用於在本地調試 Laravel 應用程序。Krater 的誕生是因爲我們作爲開發人員需要一個定製工具，爲 Laravel 應用程序或 PHP 項目提供更好的（本地）調試體驗。

Krater 的目標是：

• 數據持久性：我們希望數據在編程會話之間持久存在，甚至存儲來自多個項目的數據。

• 性能：我們希望 Krater 非常快，並在處理數據時避免內存崩潰。

• 磁盤使用：Krater 應該是輕量級的並且佔用很少的磁盤空間。目前，它的大小約爲 18 MB。

• 內存使用情況：我們不希望 Krater 在從 Laravel 接收到大量數據後或在窗口上顯示多條記錄時掛起。

在團隊中，我們有使用 Electron 的經驗，但我們事先知道它不會爲我們提供開發 Krater 時所尋求的便利。我們認識到，使用 Electron，我們將無法實現 Krater 的性能、磁盤使用和內存目標。因此，Electron 從一開始就被排除在外。

從可用的選項中，我們選擇了 Wails 和 Tauri，原因如下：

• 基於網絡技術。

• 與前端無關（允許我們使用 React、Vue、Svelte 等）。

• 它們滿足 Krater 的性能、持久性和效率目標。

在嘗試了這兩項測試後，我們認爲這兩種技術都是有效的，最終決定由 Tauri 做出，因爲它有更好的支持、維護和在 Github 上的貢獻。

我們都沒有使用過 Rust 的經驗，這也是我們第一次接觸 Tauri。作爲一個團隊，我們接受了學習 Rust 和 Tauri 來開發應用程序的挑戰。

Krater 的開發在前幾個月進展緩慢，但到了第三個月，我們開始對語言實現功能有了更好的節奏和理解。隨着時間的推移，我們提高了步伐，直到到達十字路口。

使用 Rust 遭遇的問題和挑戰：

• 瞭解所有權轉移和管理可能是 Rust 最令人困惑和複雜的方面之一。考慮程序的執行流程並管理內存中的可變和不可變變量至關重要，以避免迷失在代碼中。掌握這一點以及使用線程是團隊最耗時的任務之一。

• Rust 是一種具有很強類型安全性的語言，它可以充當未知格式數據的屏障，並確保編譯器的代碼安全。在代碼中提出解決方案時，這種嚴格的功能有時會讓人感到不舒服。我們經常聽到這樣的建議：開始以簡單、扁平的方式編寫代碼，然後以更好的方式構建代碼。這方面有時會限制我們的開發並消耗時間，讓我們懷疑 Krater 作爲一個應用程序是否需要這種級別的安全限制。

• 在這個項目中，我們使用 SQLite 作爲數據庫，找到一個好的 ORM 是一項艱鉅的任務。我們嘗試了各種各樣的庫，但沒有一個讓我們滿意。當時最穩定的選擇是 Diesel；然而，它不符合我們的需求，我們也相信文檔可以做得更好。

Rust 和 Go 比較：

• Golang 和 Rust 處理內存的方式不同。Golang 使用自動垃圾收集來限制與內存泄漏相關的問題。它的管理是在運行時完成的，這可能會帶來一定的額外成本。然而，Golang 提供了 Goroutines，它允許函數作爲線程運行，從而使併發變得更容易。

• Golang 和 Rust 都提供類型安全，但 Golang 是靜態類型的，並使用垃圾收集器來管理內存（如前所述）。與 Rust 相比，Golang 的類型系統更簡單。

• Go 的 GORM 是一個非常好的 ORM 庫。我們用它來定義表、運行遷移、刪除記錄以及執行許多其他操作。它有包含許多示例的全面文檔。

• Golang 比 Rust 早了幾年，這體現在其社區的規模和成熟度，以及庫文檔和資源的廣度和深度。一路走來，我們發現 Wails 的文檔也很有幫助，還有一些書籍作爲團隊的學習材料。

• 在 Golang 中編寫單元測試更簡單、更容易。Golang 通過包提供了對單元測試的內置支持 testing 。我們還能夠爲代碼中的一些對象驗證和創建模擬行爲。

經過這幾個月的開發，我們成功開發了 Krater 100% 並達到了第一個穩定版本。我們對使用這兩個框架以及我們今年在開發該產品中獲得的經驗感到非常滿意。

網友評論：

• ORM 很有用，但也有侷限性。當語言沒有本地查詢結構時，ORM 纔會顯現出來。

• ORM 對於包含和封裝嵌套對象是值得的。對結果集中關聯的 SQL 支持還需要改進。直接 SQL 依然重要。

• 我一直認爲數據庫纔是真理的源泉，而不是 ORM 數據模型。

• 瞭解 SQL 有時是開始使用 ORM 某些高級功能的先決條件。

• Rust 有所取捨。Rust 將權衡明確化，這意味着你經常需要做出在其他語言中不必擔心的決定。我的印象是，維持這種'簡單'的表面現象是在暗地裏製造一些惡魔。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/dvZcAG1gXIbll_aQI8KYFg