『每周译Go』Go 2.0 展望

Go是我最喜欢的编程语言之一，但它离完美还很远。在过去的10年里，我使用Go来构建小项目和大规模应用程序。虽然从2009年的最初版本开始，Go已经有了很大的发展，但本文仍然要强调一些我认为Go语言可以改进的地方。

在我们开始之前，我想明确一点:我不是在批评一些人或他们的贡献。我唯一的目的就是让Go成为最好的编程语言。

01

一个现代模板引擎

Go标准库有两个模板包: text/template 和 html/template. 他们几乎用着同样的语法, 但是 html/template 处理实体转义和一些其他的web特定构造. 不幸的是，如果不进行大量的开发人员投入，这两个包对于高级用例来说都不够合适和强大。

• 编译时错误。不像Go本身，Go模板包会很乐意让你以字符串形式传递一个整数，只是在运行时呈现一个错误。这意味着开发人员需要严格地测试模板中所有可能的输入，而不是依赖于类型系统。Go的模板包应该支持编译时类型检查。

• 匹配Go的range子句。10年过去了，我仍然把Go模板中range子句的顺序搞得一团糟，因为它有时是向后的。使用两个参数，模板引擎匹配标准库:

{{ range $a, $b := .Items }} // [$a = 0, $b = "foo"]
  for a, b := range items { // [a = 0, b = "foo"]

然而，只有一个参数时，模板引擎会生成值，而Go呈现时会生成索引:

{{ range $a := .Items }} // [$a = "foo"]
  for a := range items { // [a = 0]

Go的模板包应该与标准库的工作方式相匹配。

• 功能齐备，反射可选。作为一个普遍的规则，我认为大多数开发者不应该需要与反射交互。然而，如果你想做一些基本的加法和减法之外的事情，Go的模板包将迫使你使用反射。内置函数非常小，只满足用例的一小部分。

在我编写了Consul Template之后，很明显，标准的Go模板功能不足以满足用户的需求。超过一半的问题是关于尝试使用Go的模板语言。今天，Consul Template拥有超过50个“助手”函数，其中绝大多数应该使用标准模板语言。

Consul Template并不是唯一一个这样做的。Hugo也有一个非常广泛的助手函数列表，同样，其中绝大多数应该是在标准的模板语言中。甚至在我最近的项目Exposure Notifications中，我们无法逃避反射。

Go的模板语言确实需要更大的函数表。

• 短路评估。编辑:正如许多人指出的那样，这个特性将会在Go 1.18中出现(https://tip.golang.org/doc/go1.18#text/template)。

Go的模板语言总是在子句中计算整个条件，这导致了一些非常有趣的bug(同样，这些bug在运行时才会显示出来)。考虑下面的例子，其中$foo可以是nil:

{{if (and $foo $foo. bar)}}

这看起来似乎很好，但是和条件都将被求值——表达式中没有短路逻辑。这意味着如果$foo为nil，这将抛出一个运行时异常。

为了解决这个问题，你必须将条件句分开:

{{if $foo}}
  {{如果$ foo。酒吧}}
  {{结束}}

Go的模板语言应该像标准库一样，在第一个值为真时停止执行条件。

• 往网络专用库投入精力。我是一名经验丰富的Ruby on Rails开发人员，我非常喜欢它能够轻松地构建漂亮的web应用程序。使用Go的模板语言，即使是最简单的任务——比如将条目列表打印成一个句子——对于初学者来说也是无法实现的，尤其是与Rails的Enumerable#to_sentence相比

02

改进 range ,以便不用复制值

虽然有很好的文档，但是range子句中的值总是会被复制。例如，考虑以下代码:

type Foo struct {
  bar string
}

func main() {
  list := []Foo{{"A"}, {"B"}, {"C"}}

  cp := make([]*Foo, len(list))
  for i, value := range list {
    cp[i] = &value
  }

  fmt.Printf("list: %q\n", list)
  fmt.Printf("cp: %q\n", cp)
}

cp的值是什么？如果你认为是[A B C],不好意思你错了，正确的值是[C C C]

[C C C]

这是因为go在range子句里使用了复制品而不是元素本身。在Go2.0中，range子句应该采取引用传值. 在这方面已经有了些许提案, 包括 improve for-loop ergonomics 和 redefine range loop variables in each iteration, 所以我非常希望能有这样的改动.

03

决定性的 select

在一个select语句的多个条件为真的情况下，胜出的情况是通过一致的伪随机选择来选择的。这是一个非常微妙的错误来源，而且类似的switch语句会加重这种错误，switch语句按照写入的顺序求值。

考虑下面的代码，我们希望其表现是“如果系统停止了，什么也不做；否则等待5秒，然后提示超时”:

for {
  select {
  case <-doneCh: // or <-ctx.Done():
    return
  case thing := <-thingCh:
    // ... long-running operation
  case <-time.After(5*time.Second):
    return fmt.Errorf("timeout")
  }
}

如果在进入select语句时多个条件为真(例如doneCh是关闭的，已经超过5秒)，则该路径将执行的行为是未知的。这使得编写正确的取消代码非常繁琐:

for {
  // Check here in case we've been CPU throttled for an extended time, we need to
  // check graceful stop or risk returning a timeout error.
  select {
  case <-doneCh:
    return
  default:
  }

  select {
  case <-doneCh:
    return
  case thing := <-thingCh:
    // Even though this case won, we still might ALSO be stopped.
    select {
    case <-doneCh:
      return
    default:
    }
    // ...
  default <-time.After(5*time.Second):
    // Even though this case won, we still might ALSO be stopped.
    select {
    case <-doneCh:
      return
    default:
    }
    return fmt.Errorf("timeout")
  }
}

如果select被更新为确定性的，那么原始代码(在我看来更简单、更容易获得)就会像预期的那样工作。然而，由于选择的非确定性，我们必须不断地检查优势条件。

与此相关的是，我希望看到“如果这个通道包含任何消息，则从它读取，否则继续”的简写语法,而当前的语法是冗余的:

select {
case <-doneCh:
  return
default:
}
我希望看到这个检查的更简洁的版本，可能是这样的语法:
select <-?doneCh: // not valid Go

04

结构化日志接口

Go的标准库包含了日志包，这对于基本的使用是很好的。然而，大多数生产系统都需要结构化日志记录，并且Go语言不缺少结构化的日志库:

• apex/log（https://github.com/apex/log）

• go-kit/log（https://github.com/go-kit/kit/tree/master/log）

• golang/glog（https://github.com/golang/glog）

• hashicorp/go-hclog（https://github.com/hashicorp/go-hclog）

• inconshreveable/log15（https://github.com/inconshreveable/log15）

• rs/zerolog（https://github.com/rs/zerolog）

• sirupsen/logrus（https://github.com/sirupsen/logrus）

• uber/zap （https://github.com/uber-go/zap）

Go在这方面的意见缺乏导致了这些包的泛滥，其中大多数具有不功能和标识符都不兼容。因此，库作者不可能作出结构化的日志。例如,我希望能够实现结构化登录go-retry, go-envconfig,或go-githubactions,但这样做需要与其中一个库紧密耦合。理想情况下，我希望我的库用户能够选择他们的结构日志记录解决方案，但是缺乏用于结构日志记录的通用接口使这变得非常困难。

Go标准库需要定义一个结构化的日志接口，所有这些现有的上游包可以选择实现这个接口。然后，作为一个库作者，我可以选择接受log.StructuredLogger接口并且实现者可以做出自己的选择:

func WithLogger(l log.StructuredLogger) Option {
  return func(f *Foo) *Foo {
    f.logger = l
    return f
  }
}

我做出了这种interface的草稿

// StructuredLogger is an interface for structured logging.
type StructuredLogger interface {
  // Log logs a message.
  Log(message string, fields ...LogField)

  // LogAt logs a message at the provided level. Perhaps we could also have
  // Debugf, Infof, etc, but I think that might be too limiting for the standard
  // library.
  LogAt(level LogLevel, message string, fields ...LogField)

  // LogEntry logs a complete log entry. See LogEntry for the default values if
  // any fields are missing.
  LogEntry(entry *LogEntry)
}

// LogLevel is the underlying log level.
type LogLevel uint8

// LogEntry represents a single log entry.
type LogEntry struct {
  // Level is the log level. If no level is provided, the default level of
  // LevelError is used.
  Level LogLevel

  // Message is the actual log message.
  Message string

  // Fields is the list of structured logging fields. If two fields have the same
  // Name, the later one takes precedence.
  Fields []*LogField
}

// LogField is a tuple of the named field (a string) and its underlying value.
type LogField struct {
  Name  string
  Value interface{}
}

关于实际的接口可能是什么样子、如何最小化分配以及如何最大化兼容性有很多讨论，但我们的目标是定义一个其他日志库可以轻松实现的接口。

在我的Ruby时代，Ruby版本管理器的数量激增，每个版本管理器都有自己的dotfile名称和语法。Fletcher Nichol仅仅通过写一个gist就成功地说服了所有Ruby版本管理器的维护者对.ruby-version进行标准化。我希望我们可以在Go社区做一些类似的结构化日志记录。

05

多错误处理

在很多情况下，特别是在后台任务或周期性任务中，系统可能并行处理一些事情或在错误时继续处理。在这些情况下，返回一个多重错误是有帮助的。标准库中没有处理错误集合的内置支持。

围绕多错误处理拥有清晰而简明的标准库定义可以统一社区，并减少错误处理不当的风险，就像我们在error wrapping和unwrapping时看到的那样。

06

JSON 序列化error

说到error，您知道将error类型嵌入到结构字段中，然后将该结构序列化为JSON时候会将error字段序列化为{}吗?

// https://play.golang.org/p/gl7BPJOgmjr
package main

import (
  "encoding/json"
  "fmt"
)

type Response1 struct {
  Err error `json:"error"`
}

func main() {
  v1 := &Response1{Err: fmt.Errorf("oops")}
  b1, err := json.Marshal(v1)
  if err != nil {
    panic(err)
  }

  // got: {"error":{}}
  // want: {"error": "oops"}
  fmt.Println(string(b1))
}

至少对于内置的errorString类型，Go应该作为.Error()的结果进行序列化。另外，对于Go2.0，当试图序列化一个error类型而没有实现自定义序列化逻辑时，JSON序列化可能会返回一个error。

07

标准库中不再有公共变量

这只是一个例子，两者都是http.DefaultClient和http.DefaultTransport具有共享状态的全局变量。http.DefaultClient没有配置超时，这使得创建自己的服务很简单，并容易产生瓶颈。许多包会改变http.DefaultClient和http.DefaultTransport，这可能会浪费开发人员数天的成本来追踪错误。

Go 2.0应该将这些变量设为私有的，并通过一个函数调用来公开它们，该函数调用将返回有问题的变量的唯一分配。或者，Go 2.0可以实现“冻结”全局变量，这样它们就不会被其他包改变。

从软件供应链的角度来看，我也担心这类问题。如果我能开发一个有用的包，秘密修改http.DefaultTransport使用自定义的RoundTripper，通过我的服务器过滤您的所有流量，这将是一个非常糟糕的时刻。

08

缓冲渲染的原生支持

这更像是一件“不为人知或没有记录在案的事情”。大多数例子，包括Go文档中的例子，都鼓励通过web请求来序列化JSON或渲染HTML:

func toJSON(w http.ResponseWriter, i interface{}) {
  if err := json.NewEncoder(w).Encode(i); err != nil {
    http.Error(w, "oops", http.StatusInternalServerError)
  }
}

func toHTML(w http.ResponseWriter, tmpl string, i interface{}) {
  if err := templates.ExecuteTemplate(w, tmpl, i); err != nil {
    http.Error(w, "oops", http.StatusInternalServerError)
  }
}

但是，对于这两种情况，如果i足够大，那么在第一个字节(和200状态码)被发送之后，encoding/execution就可能失败。此时，请求是不可恢复的，因为您不能更改响应代码。

为了缓解这个问题，被广泛接受的解决方案是先渲染，然后复制到w。这仍然为错误留下一个小空间(写入w会由于连接问题失败)，但它确保在发送第一个字节之前encoding/execution是成功的。然而，为每个请求分配一个byte slice的代价可能很高，所以通常使用缓冲池。

这种方法非常冗长，给实现者带来了很多不必要的复杂性。相反，如果Go能够自动管理这个缓冲池将会很棒，可能可以使用EncodePooled这样的函数。

09

结束语

Go仍然是我最喜欢的编程语言之一，这也是我乐于强调这些批评的原因。与任何编程语言一样，Go也在不断发展。你认为这些是好主意吗?或者它们是糟糕的建议?请在Twitter上告诉我!

Copyright © 2022 Seth Vargo • Licensed under the CC BY-NC 4.0 license.

原文地址：https://www.sethvargo.com/what-id-like-to-see-in-go-2

原文作者：Seth Vargo

本文永久链接：https://github.com/gocn/translator/blob/master/2022/w03_What_id_like_to_see_in_go2

译者：1-st

校对：cuua

想要了解关于 Go 的更多资讯，还可以通过扫描的方式，进群一起探讨哦～

群内如果满员了，还可加小编微信：gocnio，共同乘坐下一趟通向 Go语言的快车哦~