Go 的婴儿学步

我决定在学习一门对我的职业和兴趣有用的新语言的旅程中尝试一下 go。这次我尝试了go。我认为第一印象非常好。

这不是一个导游，可以说，不是为我以外的任何人写的，作为一些个人提醒。

我给了自己一个小项目，名为 os-release-q 。我的目的是能够在我管理的任何系统上都有一个二进制文件，这样我就可以准确地打印出我需要的信息，而无需对其进行解析或eye-grep。

第一个障碍：进口

网上搜索很多关于导入别人的包的内容，但是很少谈到组织自己的代码。甚至文档也关注 go get 而不是关注点分离。

我在每种语言中都会遇到这个障碍，因为每种语言都有自己独特的哲学，关于如何实现它，以及每种语言有或强加什么限制。

在我学习基础知识的所有活动中，由于主要是python背景，将我的代码分成多个文件是我花了最长的时间才得到答案的。总而言之，我发现了以下内容：

• 顶层需要一个 go.mod 声明模块 module-name
• 然后我可以在顶层设置一个 src/ 目录，并在其中放置我的 main 函数，并在顶部设置一个包 main 声明
• 将代码放入其他文件中非常简单，只需创建一个带有包主声明的文件，如 src/others.go 。
• 所有函数和变量都可以直接在包 main 的任何其他文件中使用，但需要在 go build files 调用中明确声明这些文件

对于本地子模块，子模块必须驻留在文件夹中。它可以声明一个包 submodule-name .

假设它在 src/submod/ 中，主要实现者在 src/submod/submod.go 中。在 main.go 中，我们导入“module-name/src/submod”（模块名称是从 go.mod 中提取的）。然后我们就可以调用 submod.somefunction().

我们注意到，子模块函数仅适用于名称以大写字母开头的导入者。所以不要做 submod.myfunction() - 它必须是 submod.myfunction().

关于子模块和导入肯定还有其他考虑因素，但就保持代码组织和隔离而言，这是必不可少的。

为了保持理智，我试图只使用一个文件来声明 package main，并将其余部分隔离到子模块中 - 这些会自动导入，无需在 go build files 文件列表中声明。

执行基本任务

在解决了 go 的特殊性之后，剩下的就很容易了。对于每个基本任务，当然都有一个 stackoverflow 条目或一个 gobyexample.com 页面，更基本的是 go 语言参考。

• 字符串处理是通过 strings 包完成的
• 数组处理有许多本机函数，其中 base_array =append(base_array, item1, item2) 模式 - 它也适用于通过append(base, other_array...) 用另一个数组的值扩展一个数组
• 错误处理通常是通过传递错误对象来完成的，但不一定。
• 存在一个“log”库，用于方便的预配置无干扰日志。它包括一个 log.fatal(message) 调用，该调用会记录错误，并立即退出。
• 使用 exec.command(base, args...) 模式，通过“os/exec”库调用子进程很容易

两个特别常见的任务值得拥有自己的段落。

错误处理

基本错误处理经常被认为很麻烦，实际上需要在控制流中处理错误。对于来自 try/catch 工作流程的程序员来说，这可能是令人厌恶的，但在可能发生的情况下处理问题并不是那么糟糕。

// explicit return item `err` forces us to be aware of it
// but having the ability to check it in the same breath is not so bad
if result, err := somecall(); err != nil {
    log.fatal("sorry.")
}

// equally valid is
/*
result, err := somecall()
if err != nil {
    log.fatal("sorry")
}
*/

fmt.println(result)

比较try/catch方式

try:
    result = someCall()
    print(result)
except:
    print("Sorry") # a little divorced from potential origin of error
    sys.exit(1)

参数解析

我不禁觉得flags库的实现有点半生不熟。显然，考虑到它以目前的形式生存下来，人们已经习惯了它并且对此感到满意。

调用 program -flag arg1 arg2 为我们提供了 flag 设置为执行的切换，而positionals := flags.args() 返回 ["arg1", "arg2"] 数组

然而，调用程序 arg1 arg2 -flag 并不会切换 -flags 应该执行的任何操作，而是给出位置为 ["arg1", "arg2", "-flag"]，其中标志未被解析。

这对于传递像程序 colorize ls -l 这样的子调用可能很有用，其中 ls -l 是逐字传递的 - 所以我可以看到一个用例。只是大多数程序都允许在位置项周围的任何地方使用标志参数。 ls dir1/ -l dir2/ 与 ls -l dir1/ dir2/ 相同，这是一个适用于绝大多数 unix 和 linux 命令的约定。这可能只是需要习惯的事情 - 并且值得呼吁。 go 的目的和用例 除了文件导入范例之外，我发现实现我的基本应用程序非常容易。我做错的任何事情都感觉相当明显，而且这些错误是有意义的。确实感觉我可以专注于“把事情做好”。从我迄今为止微薄的使用量，并考虑到我的具体需求，我可以看到

容易上手
• 编译的二进制文件，无运行时依赖
• 带有类型的简单语言是 shell 脚本的一个进步
• 据称简单的多处理支持

我认为使用稀疏类型而不是对象和继承会是一个障碍，但到目前为止还不错。我在其他语言中不需要它们，所以我想当我开始定义接口和类型时，感觉就像是 lua 和 bash 的一个进步。我希望.我想探索编译为本机语言的原因之一是能够生成可以轻松分流的二进制文件，而不需要依赖于存在的特定版本的运行时。一位同事最近沮丧地走到我的办公桌前，试图解决将 java 17 移植到基于 debian 10 的旧 node 基础镜像上的问题。他要么必须升级 node 版本以获得更新的基础镜像，使用新的 debian 基础镜像并手动安装和配置 node，要么在互联网上搜索由“好人知道”托管的自定义存储库以获得“好人知道” -if-hacked java 17 将在 debian 10 上运行。如果部署的软件没有这种冲突的运行时依赖关系，事情会变得多么容易......从运维的角度来看，我觉得我能感受到的一大收获是：我可以轻松编写代码，并构建一个 elf 二进制文件，然后部署在“任意系统 x”上，而不必与确保给定运行时的正确版本已就位，并管理冲突的依赖项。我确信还有其他好处，而且我听过很多关于 go 中多线程和多处理的易用性的说法，我确实打算制作一个小型项目来探索这一点，作为下一步 - 可能是一些东西它可能会侦听多个通道上的输入，并执行一些基本任务作为响应。我在之前的一些测试自动化任务中已经有过这样的用例，所以此时它对我来说并不陌生。