Scribble at 2022-05-26 15:27:31 Last modified: 2022-05-26 22:39:13

少し前から何度か話題にしているので気付いている方もいるとは思うが、急に思い立って Go の本を読んで処理系を使っている。ただ、自宅では Raspberry Pi Zero W にも Go をインストールしてみたのだが、はっきり言って "Hello, worrld!" をコンパイルするのですら５秒くらいかかる。なので、暫くは Windows というか VSCode の中で表示するコンソール画面で実行するのがよさそうだ。

で、手初めに "Introducing Go: Build Reliable, Scalable Programs" (Caleb Doxsey, O'Reilly Media, 2016) を読んだという話は既に書いたし、他にも物色しているところなのだが、やはり "Learning Go: An Idiomatic Approach to Real-World Go Programming" (Jon Bodner, O'Reilly Media, 2021) や、既にご紹介した "Pro Go: The Complete Guide to Programming Reliable and Efficient Software Using Golang" (Adam Freeman, Apress, 2022) は、さすがに定評のある出版社から出ているだけあって、読む価値はあろうと思う（Apress は、いまや Springer Nature の傘下にある）。そこで、少し読んでみた "Pro Go" についてだけ言っておくと、僕は以前も書いたように冒頭で実装例を並べて capability を訴えるような書き方は、逆効果だと思う。なので、"Pro Go" も最初に説明もなしに実装例をずらっと並べていて読み辛いから、僕と同じ好みの人は、この本は第３章の "Using the Go Tools" から読み始めるのがいい。なんだかんだ言っても1,000ページを超える本なので、解説そのものは詳しくて楽しい。

Manning は良い本が多いけれど、"Go in Action" は2015年だから今年や去年の本よりも先に読むほど優れた内容でもなければ、参考程度にとどめるのがいいだろう（何日か前に古くても読めるとは書いたが、僕らのようにシンタクスだけに拘泥せずに読み取れる才能があればの話である。素人や無能は、黙って日本人が書いた通俗書を買って20回くらい読むべきだ。僕も、Perl はヤモリ本を最低でも20回くらい読み返したし、ラクダ本ですら5回くらいは読み返している）。

あと、Packt の本はアマゾンの「試し読み」すら利用していない。ここの本は、ちょっと編集者や査読者の力量が安定しておらず、レビューすら付かないほど酷いタイトルもたくさんあって、買うどころか読むのですら時間の無駄という可能性が高くなっているからだ。たまに特殊な話題を扱っていて興味深いタイトルもあるのだが、とにかく毀誉褒貶が激しすぎて出版社として信用し辛い。

それから書籍についてアマゾンに言いたいのは、オンデマンド出版だと日本国内で印刷・製本して配送してくるから、安くて速いのはいいんだけど、表紙はともかく本文をむやみに分厚い紙に印刷するのは止めてほしい。もうそろそろ技術書は電子版だけに移行してもいいような気はするから、どうでもいいと言えばいいのだけれど、大してページ数がないのに、アマゾンのオンデマンド出版で送ってきた本はやたら重い。

Go を勉強しようと思ったきっかけは、もちろん 5/15 に書いたとおり Prometheus の開発言語だったからだ。というか、それまでにも勉強するチャンスはあった筈なのだけれど、Google が主導しているという胡散臭さに加えて、あまり Go の仕様を知らなかったせいで、Node.js のようなサーバ側で動かす JavaScript みたいな言語だと思い込んでいたという理由もある（そして、僕はそういう言語が大嫌いだった）。でも、既に書いたように Caleb Doxsey の "Introducing Go" を読んで処理系を入れてみたら、学ぶ価値のある言語だと分かった次第だ。皮肉なことに、いま現在は Prometheus についての関心はなくなってきたのだが、逆に Go については今月から来月にかけて真面目に取り組んでみようという気になった。

ということで、VSCode にも Go をサポートするプラグインを入れていたりするわけだが、これのコード・フォーマットがきついので、抑制しようかと思う。いちばん困るのは、僕は頻繁に Ctrl + s する習慣があるのだけれど、import した直後にモジュールの関数を全く使わずにファイルを保存すると、import 宣言が自動で消えてしまうのだ（そして「問題」タブに ""fmt" imported but not used" などと出る）。いや、こんなのコンパイルするときに警告するか、リアルタイムで「問題」のタブに表示するだけでいいよ。何もコードを消すことはないじゃないか。

Go のモジュールについては、エディタ設定の "Format on save" を無効にしてもフォーマットされてしまう。"goimports," "goreturns," "gofumports" のどれかが使われているとフォーマットされるため、どうもフォーマット関連のツールを直に抑制しないといけないらしい。実際には、settings.json を設定画面から直に開いて、そこへ次のコードを追加すればいい。

"[go]": {

"editor.formatOnSave": false,

"editor.codeActionsOnSave": {

"source.organizeImports": false

}

}

設定ファイルを直に編集する場合は、JSON ファイルの書き方として trailing comma は許容されないというくらいの常識は調べておこう。こうした後でも LINT は動くので、ちゃんと「問題」タブには警告が表示されるし、ファイルを切り替えるタブとか、使われていないモジュールの import 宣言も色が変わったままなので安心だ。もちろん、こうまでしてフォーマットを抑制しておきながら、import したモジュールを使わずにコンパイルするような奴は、どのみちエラーにはなるものの、最初から黙ってコードの自動フォーマットを受け入れろという話である。カスタマイズというものは、原則としてそのリスクを自分で引き受けるものだ。社内のマシンで壁紙を metabolic pathway map (http://biochemical-pathways.com/#/map/1) に替えたら、誰かに「キモい」と思われるリスクを負わなくてはいけないのと同じことである。