Programming vs Software Engineering (Rust vs Go) 编程与软件工程（Rust 与 Go）

[981377660LMT]

https://kerkour.com/programming-vs-software-engineering-rust-vs-go

[981377660LMT]

Software engineering is what happens to programming when you add time and other programmers. 软件工程是当你增加时间和其他程序员时编程所发生的事情。

[981377660LMT]

Rust is betting everything on a powerful language backed by advanced theory, while Go is betting on its simplicity, a huge standard library and powerful tooling. Rust 将一切都押在了一种由先进理论支持的强大语言上，而 Go 则押注于它的简单性、庞大的标准库和强大的工具。

[981377660LMT]

The two technical pillars of effective collaboration on software projects are using a common language and having a common infrastructure. 软件项目有效协作的两个技术支柱是使用通用语言和拥有通用基础设施。

[981377660LMT]

With Go, everybody is speaking the same language. With Rust, some people are speaking macros, some other functional programming, some are speaking sync programming, others are speaking async and other type-driven development. Everybody is able to express their singularity at the cost of a lot of friction when it comes to collaboration and interoperability. 有了 Go，每个人都在说同一种语言。对于 Rust，有些人在谈论宏，有些人在谈论其他函数式编程，有些人在谈论sync编程，其他人在谈论async和其他类型驱动开发。在协作和互操作性方面，每个人都能够表达自己的独特性，但会产生很多摩擦。

[981377660LMT]

One thing that I absolutely loath when working on Rust projects is managing dependencies. Rust's anemic standard library led to a JavaScript-style dependencies management, and now even the most basic projects have 300+ transitive dependencies. 在处理 Rust 项目时，我绝对讨厌的一件事是管理依赖项。 Rust 贫乏的标准库导致了 JavaScript 风格的依赖管理，现在即使是最基本的项目也有 300 多个传递依赖。

[981377660LMT]

On the other hand, Go designers understood that both tooling and the standard library is more important than the language. The language almost never change but the standard library and the tooling continuously improve between versions. 另一方面，Go 设计者明白工具和标准库都比语言更重要。该语言几乎从未改变，但标准库和工具在版本之间不断改进。

[981377660LMT]

I would dare to say that Go's standard library may be the 8th wonder of the world. It's far from perfect, and the internal code can sometimes be, hmmm, "not great", but the public interfaces are incredible. I believe that every languages should take note and copy it. 我敢说 Go 的标准库可能是世界第八大奇迹。它远非完美，内部代码有时可能，嗯，“不太好”，但公共接口令人难以置信。我相信每种语言都应该记录并复制它。

[981377660LMT]

On the other hand, Go projects are always incredibly stable. No commits since 2018? It simply means that the project is done and will continue to work in the foreseeable future. 另一方面，Go 项目总是非常稳定。自 2018 年以来没有提交？这仅仅意味着该项目已经完成并将在可预见的将来继续工作。

Here is a telling example: Go's most popular UUID library github.com/google/uuid was started in August 2011. Today, in 2024, it has 165 commits and 0 dependencies. Rust's most popular UUID library github.com/uuid-rs/uuid was started in February 2014. It has today, still in 2024, 1594 commits and a quantum number of dependencies, depending on which features you enable. I didn't analyze why so many commits were needed to generate UUIDs, but something is clearly wrong. Using an UUID package should be set-and-forget, not something requiring your attention every month because a new version has been released. 这是一个生动的例子：Go 最受欢迎的UUID库github.com/google/uuid于 2011 年 8 月启动。今天，2024 年，它有 165 次提交和 0 个依赖项。 Rust 最受欢迎的UUID库github.com/uuid-rs/uuid于 2014 年 2 月启动。到今天（仍然是 2024 年），它已经有 1594 次提交和大量依赖项，具体取决于您启用的功能。我没有分析为什么需要这么多次提交来生成 UUID，但显然有问题。使用 UUID 包应该是一劳永逸的，而不是因为新版本已经发布而每个月都需要你注意的事情。

[981377660LMT]

A good rant should never ends without a suggestion for improvement™, so here are my 3 advices to become a great software engineer, and not a simple programmer: 一次好的咆哮永远不会在没有改进建议的情况下结束™，所以这里是我成为一名伟大的软件工程师而不是简单的程序员的 3 个建议：

First, you need to describe the intent of your code and give an overview of how it works both at a macro level (in the README / wiki) and at the micro level, by commenting functions, structures and packages. Document, document, document. 首先，您需要描述代码的意图，并通过注释函数、结构和包来概述其在宏观层面（在 README/wiki 中）和微观层面的工作原理。文件，文件，文件。

Second, give examples on how to use your code. Snippets that users can quickly copy/paste and "feel it". Even better, add comments with the expected output to your examples. 其次，举例说明如何使用您的代码。用户可以快速复制/粘贴并“感受”的片段。更好的是，将带有预期输出的注释添加到您的示例中。

Finally, write simple code. Restrain you from showing the world how smart you are and instead think about how your dumbest colleague (yeah, this one) may do when trying to work on your code. Always remember that more effort and resources are spent on maintenance than production, so do your best to reduce the burden of the future maintainers. Go light on generics, don't use macros, and avoid external dependencies as much as you can. 最后，编写简单的代码。不要向世界展示你有多聪明，而是想想你最愚蠢的同事（是的，就是这个）在尝试编写你的代码时可能会做什么。永远记住，更多的精力和资源花在维护上而不是生产上，所以尽最大努力减轻未来维护人员的负担。尽量使用泛型，不要使用宏，并尽可能避免外部依赖。

AND DON'T USE SINGLE LETTER VARIABLE NAMES! 并且不要使用单字母变量名称！