GopherCon2019聴講メモ "Our path to Go2 by Russ cox "

gophercon-our-path-to-go2.md

Our path to Go2 by Russ cox

• Go開発はExperiment・Simplifyという２つのステージからなるループで始まった
• "simplifying"の4つの"R"がこのループプロセスを導いてきた

4つのR

• 4つのR
  • Reshaping
  • Redefining
  • Removing
  • Restricting
• 4つのRの例
  • Reshaping
    • goコマンドをたくさんのバイナリから一つのバイナリにReshapeした
  • Redefining
    • 開発当初 "appendToList"が頻繁に書き直されていたのをうけ、appendという関数へRedefineした
  • Removng
    • 言語にとって有益ではない、experimentがうまくいかなかったものはRemoveしていった
  • Restricting
    • すべてのGoファイルはutf-8でなければいけない、他のエンコーディングはサポートしていない
      • たくさんのエンコーディングに対応しなくていい -> toolchainのSimplify
      • 個人refs: https://golang.org/ref/spec?source=post_page---------------------------#Source_code_representation

Experiment・Simplify・Shipへ

• 開発当初のExperiment・Simplifyはとてもシンプル
• Goコードの出荷(Ship)・ユーザーが試せるようにステップを追加
• Experiment・Simplify・Ship

https://twitter.com/matthewbrahms/status/1154425126642831360

Go2へ

• Go2もGo1と同じ考え方、Experiment, Smplify, Shipのループでやっていく
• Go2の注目は以下
  • Error Handling
  • Generics
  • Dependency Management
  • Tooling

Error Handling

Errorの歴史

• 2008年 syscall errorはint型で定義
  • errno int64
• 2008年 ↑の2時間後error typeが生まれる
  • type Error struct、Print()・String()という２つのシグネチャを持っていた
• 2009年 Error interface
  • Print()が取り除かれた
• pkg/errorsなどError experimentsが色々
  • experimentの結果が溜まってくる

Go1.13でのエラーハンドリング

Handling helper

• エラーハンドリングのヘルパー
  • Unwrap interface (optional)
  • errors.Is
  • errors.As
• Unwrap
  • Unwrap() error
  • 個人ref:
    • xerrorsでいうところのUnwrap()に近いところかな
    • https://godoc.org/golang.org/x/xerrors#Unwrap
• errors.Is
  • err == targetとしてたものはerrors.Is(err, target)とできる
  • err.(*Type)としてたものをerrors.As(err, &target)などとできる
  • 個人ref:
    • xerrorsでいうところのIs/Asに近いところかな
    • https://godoc.org/golang.org/x/xerrors#Is

Errors syntax

• エラーハンドリングのコミュニティの関心はコードの可読性、たしかに大事
• 2018年 Checkの提案へ
• 2019年にTryへ
  • しかしこの提案は破棄。GoをSimplifyするか明確ではなかった
  • 個人ref: https://github.com/golang/proposal/blob/master/design/32437-try-

Generics

• 2010年に最初の提案がありrejectされた、その後もいくつかexperimentsがあ2013年にrefected
• 2018年に contracts を新しいデザインとして検討を始めた
• あしたの発表でGenericsについて詳しく

Dependencies Management

• 2010年に goinstall、GOROOTへ依存関係をダウンロード
• 2011年にGOPATHを導入
• package authorsに後方互換性（compatibility）について同じphilosophyを採用する推奨
  • Don't make breaking API changes
    • 後方互換性を保つこと
  • New Functionality should receive new names
    • 新しい機能は新しい名前を
  • New import paths should be defined for breaking changes
    • 破壊的に変更には新しいimport pathを
    • ex. gopkg.in.yaml.v1 v2
• Dependency Managementのいろいろなexperiments
  • goven 2012
  • godep 2013
  • glide 2014
  • gb 2015
  • 個人Q: こういう実験のアイデアは誰かが突然Issueに上げて話し始めるんだろうか、Goチームの中の話が最初にあったりするのかな？実験募集中！みたいな

Go Vendoring

• 2015年 Go Vendor Specを導入、vendorディレクトリという形、しかしうまく行かず...
• 2016年 Go Dependency Working Groupが作られ、depを始める
• 2017 Dep
  • Incomatible Changes
  • ex. k8s.io/client-go code.com.yaml
  • depは複数の依存先に同じパッケージが求められておりといった際に衝突する問題

https://twitter.com/juliaferraioli/status/1154430949733498880

• 2018 Vgo to Go Modules
  • vgoが現在のgo modulesへ
  • integrated Go command
  • Go Moduleの利点の一つがModule Proxy
  • 別のトークで詳しく
  • Repacing GOPATH GOPATHに縛られなくてよくなる
  • ただしまだGOPATHをなくす準備はできてない

Tools

• Go toolchainも良くしていく
• たとえばgopls、すべてのeditor, IDE, CIなどでスムーズにintegrateできるように
• くわしくは別のトークにて

まとめ

experiment->simplify->shipの流れでGo2やっていくぞ