Go 1.14 リリース候補版
Go 1.14 のリリース候補版が出た。 これに伴ってリリースノートのドラフト版も更新されたようだ。
- Go 1.14 Release Candidate 1 is released - Google group
- Go 1.14 Release Notes - The Go Programming Language
更にブログでは以下の記事で 1.15 についても言及されている。
詳しくはそれぞれの記事を読んでもらうとして，この記事では個人的に気になった点をかいつまんで紹介する。
Try 終了のお知らせ
「Go 1.13 と 1.14」で紹介した try() 組み込み関数の導入は見送られたらしい。
Our attempt seven months ago at providing a better error handling mechanism, the try proposal, met good support but also strong opposition and we decided to abandon it. In its aftermath there were many follow-up proposals, but none of them seemed convincing enough, clearly superior to the try proposal, or less likely to cause similar controversy.
というわけで，エラー・ハンドリング周りはこれ以上の仕様追加・変更は（1.x の間は）なさそうである。
埋め込み Interface の改善
Go 1.14 では埋め込み interface の仕様が一部変更になる。
Per the overlapping interfaces proposal, Go 1.14 now permits embedding of interfaces with overlapping method sets: methods from an embedded interface may have the same names and identical signatures as methods already present in the (embedding) interface. This solves problems that typically (but not exclusively) occur with diamond-shaped embedding graphs. Explicitly declared methods in an interface must remain unique, as before.
Go では interface は振る舞いのみを定義する型だが，入れ子にすることができる。 こんな感じ。
type Person interface {
Name() string
Age() int
}
type Employee interface {
Person
Level() int
String() string
}
この例では Employee interface 型に Person interface 型が埋め込まれている。
つまり Employee 型では Name(), Age(), Level(), String() 各メソッドを要求しているわけだ。
ここで Person 型に String() メソッドを付けることを考える。
type Person interface {
Name() string
Age() int
String() string
}
修正された Person 型を使って Employee 型を定義しようとしても
とコンパイルエラーになる。
Interface 型の間で定義するメソッドを調整すればいいのだが，他パッケージの interface 型を埋め込む場合は，そのパッケージの仕様変更の影響をモロに受けることになる。duplicate method String
更に
のようなひし形構造になっている場合はより複雑になる。
Go 1.14 では（関数型の同一性も含めて）同じメソッドについては重複を許容する。 上述のコード例でもコンパイル・エラーにならないわけだ。
ただし
type E1 interface{ M(x int) bool }
type E2 interface{ M(x float32) bool }
type I interface {
E1
E2
}
では（メソッド M() の型が同一ではないので）相変わらずコンパイル・エラーになるようだ。
Preemptive なスケジューリング
これは Shimane.go の Slack で教えてもらったのだが， Go 1.14 では preemptive (非協調的) なスケジューリング実装になるようだ。
Goroutines are now asynchronously preemptible. As a result, loops without function calls no longer potentially deadlock the scheduler or significantly delay garbage collection.
もともと Go 言語には，ランタイムによって並列処理の実装詳細を隠蔽することにより，コード記述としての平行処理に注力できるというメリットがあるが preemptive なスケジューリングによって強化されることになる。
ただし全てのプラットフォームで有効になるのではなく
windows/armdarwin/armjs/wasmplan9/*
は例外となるらしい。 WebAssembly や Plan 9 が non-preemptive になるのは分かるが， ARM アーキテクチャって実装が難しいのか？
モジュール対応モード
モジュール対応モード（module-aware mode）も色々と機能追加されるようだ。
特に vendor ディレクトリとの組み合わせは色々とできそうだ。
When the main module contains a top-level.vendordirectory and itsgo.modfile specifies go 1.14 or higher, the go command now defaults to-mod=vendorfor operations that accept that flag. A new value for that flag,-mod=mod, causes the go command to instead load modules from the module cache (as when no vendor directory is present)
この辺は Go 1.14 正式版がリリースされてから試してみよう。
Launched pkg.go.dev
pkg.go.dev は従来の godoc.org から置き換えることができる。
Like godoc.org, pkg.go.dev serves Go documentation. However, it also understands modules and has information about past versions of a package!
実際に2020年後半には godoc.org へのリクエストを pkg.go.dev にリダイレクトする計画があるらしい。
To minimize confusion about which site to use, later this year we are planning to redirect traffic from godoc.org to the corresponding page on pkg.go.dev.
標準パッケージもサードパーティのパッケージも同等に扱えるので，今後は pkg.go.dev を参照するのがいいかもしれない。
参考図書
- プログラミング言語Go
- アラン・ドノバン (著), ブライアン・カーニハン (著), 柴田芳樹 (著)
- 丸善出版 2016-06-20 (Release 2021-07-13)
- Kindle版
- B099928SJD (ASIN)
- 評価
Kindle 版出た！ 一部内容が古びてしまったが，この本は Go 言語の教科書と言ってもいいだろう。感想はこちら。
- Go言語による並行処理
- Katherine Cox-Buday (著), 山口 能迪 (翻訳)
- オライリージャパン 2018-10-26
- 単行本（ソフトカバー）
- 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN)
- 評価
- Goならわかるシステムプログラミング
- 渋川 よしき (著), ごっちん (イラスト)
- ラムダノート 2017-10-23
- 単行本（ソフトカバー）
- 4908686033 (ASIN), 9784908686030 (EAN), 4908686033 (ISBN)
- 評価
PDF 版あり。ファイルやソケットなどに代表される順次アクセスの汎化である io.Reader / io.Writer およびその派生・特化クラス，またプロセスやスレッドに関する解説が秀逸だと思う。さらに Docker コアの libcontainer についても解説がある。