最近、Go1.20 が 2 月初旬に正式リリースされました。非常に早くリリースされました。以前は月末まで延期されました。いくつかの記事を読んだところ、機能的なトレードオフにより、いくつかの新機能 (アリーナなど) を手放すことを余儀なくされました。
Go チームは 2 月に何かすることがあるのだろうか、それとも休暇をとる予定なのでしょうか?それとも、一時解雇が仕事の引き継ぎに影響を与えるのではないかと心配ですか?
今日は、私たちにとってより関連性の高い新機能を簡単に確認し、1.20 にアップグレードできるかどうかを確認します。
Go1.18 がジェネリックを正式にリリースするまでは、喜びと不安がありました。これはジェネリックスをサポートしていますが、Go1.18 のコンパイル速度は Go1.17 よりも遅く、約 15 ~ 18% 遅くなり、大幅に遅くなります。
汎用機能により、Go が誇るビルド速度が低下しました。後から建てたらコーヒーが作れるのではないかと心配ですか?
当初は Go1.19 で修正されると言われていましたが、その後修正されました。最終的に、現在のバージョンは修正されました。
次のテスト レポート:
│ 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%
最新の Go1.20 ベンチマーク テストでは、現在のバージョンと Go1.17 のビルド速度は一貫しています。
さらに、コンパイラーとガベージ コレクターが最適化され、メモリのオーバーヘッドが削減され、全体的な CPU パフォーマンスが 2% 向上しました。
Go1.20 のアップデートの発表では、macOS と Windows を含むメジャー アップデートの終了通知も発表されました。オペレーティング·システム。
それらは次のとおりです:
Go1.20 は、macOS 10.13 High Sierra での実行をサポートする最後のバージョンです。または 10.14 Mojave バージョン。 Go 1.21 には macOS 10.15 Catalina 以降が必要です。
Go1.20 は、Windows 7、8、Server 2008、および Server 2012 の任意のバージョンでの実行をサポートする最後のバージョンです。 Go 1.21 には、少なくとも Windows 10 または Server 2016 が必要です。
#皆さん、オペレーティング システムのバージョンを更新する必要があるようです。そうしないと、Go は次のバージョンでのコード作成を歓迎してくれません。
有需要的同学在下个版本前尽早做好升级。
新版本起,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,发现这个日期时间点,使用的次数非常高频:
ランキング | 頻度 | 形式 |
---|---|---|
1 | 75616 | time.RFC3339 |
2 | 23954 | time.RFC3339Nano |
3 | 13312 | "2006-01-02 15:04:05" |
4 | 12332 | "2006-01-02" |
11940 | time.RFC1123 |