Recently Go1.20 was officially released in early February. It came very early. In the past, it was delayed until the end of the month. I read several articles and found that I still did a lot in the end. Functional trade-offs, forced to let go of some new features (for example: arena, etc.)!
I wonder if the Go team has anything to do in February, or is it planning to take a vacation? Or are you worried that layoffs will affect work handover?
Today we will quickly review the new features that are more relevant to us and see if it can be upgraded to 1.20.
Before Go1.18 officially released generics, there were both joys and worries. Although this supports generics, the compilation speed in Go1.18 is slower than that in Go1.17, about 15-18% slower, which is a significant slowdown.
The generic feature has slowed down the build speed that Go is proud of. Are you afraid that you can make coffee if you build it later?
Originally it was said to be fixed in Go1.19, but it was later fixed. Finally, the current version has been fixed.
The following test report:
│ 117.results │ 118.results │ 119.results │ tip.results │ │ sec/op │ sec/op vs base │ sec/op vs base │ sec/op vs base │ GoBuildKubelet 52.58 ± 0% 56.54 ± 1% +7.54% (p=0.000 n=10) 55.47 ± 1% +5.50% (p=0.000 n=10) 51.41 ± 1% -2.22% (p=0.000 n=10) GoBuildIstioctl 47.78 ± 1% 51.44 ± 0% +7.65% (p=0.000 n=10) 50.89 ± 5% +6.50% (p=0.000 n=10) 46.05 ± 1% -3.62% (p=0.000 n=10) GoBuildFrontend 19.03 ± 1% 20.55 ± 1% +7.99% (p=0.000 n=10) 20.04 ± 0% +5.33% (p=0.000 n=10) 18.22 ± 1% -4.27% (p=0.000 n=10) geomean 36.29 39.10 +7.72% 38.39 +5.77% 35.07 -3.37%
In the latest Go1.20 benchmark test, the build speed of the current version and Go1.17 remains consistent.
In addition, the compiler and garbage collector are optimized, reducing memory overhead and improving overall CPU performance by 2%.
The update announcement of Go1.20 also announced a major update end notification, involving macOS and windows operating system.
They are as follows:
Go1.20 is the last one to support running on macOS 10.13 High Sierra or 10.14 Mojave Version. Go 1.21 will require macOS 10.15 Catalina or later.
Go1.20 is the last version to support running on any version of Windows 7, 8, Server 2008, and Server 2012. Go 1.21 will require at least Windows 10 or Server 2016.
#Hey guys, it seems that I need to update my operating system version, otherwise Go will not welcome me to code in the next version.
有需要的同学在下个版本前尽早做好升级。
新版本起,Go 的 $GOROOT/pkg
目录将不再存储标准库的预编译包存档,Go 发行版的将迎来一轮瘦身。
大小对比如下。
Go1.20:
Go1.19:
约比老版本缩减了 1/3,还是比较明显的。
在 Go1.20 起,Go 引入了 Profile-guided optimization (PGO),翻译过来是使用配置文件引导的优化,当前为预览版本。
PGO 是一门编译器优化技术,能够在不改业务代码的情况下,给你的应用程序带来一定的性能提升。在 Go PGO 中将会依托 runtime/pprof 所生成的 profile 来完成。
结果上可以使得 Go tool(工具链)能根据运行时信息执行特定于应用程序和工作负载的优化。说明了就是想提高性能,不需要改业务代码。
具体可以详见:《PGO 是啥,咋就让 Go 更快更猛了?》
在原有 Go1.13 的 errors API 上进行新增和修改,核心是支持一个错误可以封装多个错误的特性。
新特性例子:
func main() { err1 := errors.New("err1") err2 := errors.New("err2") err := errors.Join(err1, err2) fmt.Println(err) if errors.Is(err, err1) { fmt.Println("err is err1") } if errors.Is(err, err2) { fmt.Println("err is err2") } }
输出结果:
err1 err2 err is err1 err is err2
具体可以详见:《Go1.20 继续小修小补 errors 库。。。》
Go 团队通过分析、搜索发现 reflect.SliceHeader 和 reflect.StringHeader:
type StringHeader struct { Data uintptr Len int }
在业内经常被滥用,使用不方便,很容易出现隐性问题。例如:Data 字段类型是 uintptr 不是 unsafe.Pointer。设什么都可以,灵活度过于高,非常容易搞出问题。
在 Go1.20 起,在 unsafe 标准库新增了 3 个函数来替代前面这两个类型的使用。希望能够进一步标准化,并提供额外的类型安全。
如下函数签名:
func String(ptr *byte, len IntegerType) string
:根据数据指针和字符长度构造一个新的 string。func StringData(str string) *byte
:返回指向该 string 的字节数组的数据指针。func SliceData(slice []ArbitraryType) *ArbitraryType
:返回该 slice 的数据指针。新版本的用法变成:
func StringToBytes(s string) []byte { return unsafe.Slice(unsafe.StringData(s), len(s)) } func BytesToString(b []byte) string { return unsafe.String(&b[0], len(b)) }
以往常用的 reflect.SliceHeader
和 reflect.StringHeader
将会被标注为被废弃。
具体可以详见:《别乱用了,用新的。Go SliceHeader 和 StringHeader 将会被废弃!》
有很多 Go 同学反馈老要记 2006-01-02 15:04:05,发现这个日期时间点,使用的次数非常高频:
Ranking | Frequency | Format |
---|---|---|
1 | 75616 | time.RFC3339 |
2 | 23954 | time.RFC3339Nano |
3 | 13312 | "2006-01-02 15:04:05" |
4 | 12332 | "2006-01-02" |
11940 | time.RFC1123 |