为什么使用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 将权衡明确化，这意味着你经常需要做出在其他语言中不必担心的决定。我的印象是，维持这种'简单'的表面现象是在暗地里制造一些恶魔。

https://www.jdon.com/69652.html