『効率的な Go』読書会 2回目

指針となった原則は、安全性と繰り返しの少なさを引き換えにせず、よりシンプルなコードを可能にする言語を作ることでした。

GoogleはいまだにGoを管理する唯一の企業であり、Goに対する最後の決定的な支配権を持っています。たとえ誰もが修正、使用、貢献できるとしても、単一のベンダーによって調整されたプロジェクトは、再ライセンスや特定の機能のブロックなど、身勝手で有害な決定を下す危険性があります

「gofmt のスタイルは誰の好みでもないが、gofmt はみんなの好みである（ Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite. ）」

標準ライブラリの設計を通じて、依存関係を制御することに多大な努力が払われました。1つの機能のために大きなライブラリを引っ張ってくるよりも、少しのコードをコピーするほうが良い場合があります（システムビルドのテストでは、新しいコアの依存関係が発生すると文句を言われます）。依存関係の衛生管理は、コードの再利用に優先します。

繰り返しになりますが、効率を考慮すると、依存関係と透明性における潜在的なミニマリズムは、非常に大きな価値をもたらします。未知なものが少ないということは、主要なボトルネックをすばやく検出し、もっとも重要な価値のある最適化にまず注力できることを意味します。私たちは、依存関係に最適化の余地があることに気づいても、それを回避する必要はないのです。そのかわり、私たちは通常、その修正を直接アップストリームに貢献することが歓迎されます。これは両者にとって有益なことです！

Goは、エラーを第一級市民の言語機能として扱うことで、独自の道を歩んでいます。信頼できるソフトウェアを書きたいと仮定して、エラー処理を明示的に、簡単に、そしてライブラリやインターフェイスにわたって統一的に行うのです。

もうひとつよくある不満は、Goを書くと非常に「悲観的」になるということです。なぜなら、決して起こらないかもしれないエラーが、目に見える形で現れるからです。

1960 年、米国と欧州のプログラミング言語専門家が手を組み、Algol60 が誕生しました。1970 年、Algol のツリーはCとPascal の2 つのブランチに分かれました。約 40 年後、この2 つの枝はGoで再び合流しました。

Robert Griesemer, The Evolution of Go （https://oreil.ly/a4V1e）

効率という点では、Go にはアキレス腱があります。「5.5 Goのメモリ管理」で学ぶように、メモリ使用量はときに制御しにくいことがあります。プログラム中の割り当ては（特に新しいユーザーにとっては）驚くようなもので、ガベージコレクションの自動メモリ解放処理にはオーバーヘッドや偶発的な動作があります。特にデータ指向（data-intensive）のアプリケーションでは、メモリやCPU の効率を確保するために、メモリ容量が厳しく制限されているマシン（IoT など）と同様に努力が必要です。