amazon.co.jp
11 月から『Real World HTTP』[2017-11-28-1]
と同時に読んでいたのに、
読み終わったのが今日になってしまった。意外とボリュームあったのと、
あと少しで読み終えられたのに油断して読み進めなかったせい。
本書のもとになった ASCII.jp のウェブ連載では、この書籍（※）の内容
とかぶらないように、実用性よりも低レベルの説明にフォーカスしたとい
うのが実態です。※『Real World HTTP』
P332 にこう書かれているように、『Real World HTTP』と一部内容が被る
ものの、低レイヤの話が大部分を占める。
一応私は組み込みエンジニア時代に open(3), ioctl(3), close(3) 等を
使ったデバイスドライバを書いたことがあるので（VxWorks だけど）、
ある程度想像力を働かせて読むことが出来た。
先の引用に書かれているとおり実用性は考慮されていないので、それを期
待すると期待はずれに終わると思う。あくまでエンジニアとしての知識を
深めるための技術書かと。
「第17章 Go言語とコンテナ」は面白そうだったので、あとで写経するかも。
以下、個人的なメモ。
P98
最近では、RESTful の究極形態（第４形態）として位置づけられる
HATEOAS という考え方も広まりつつあります。
（中略）
HATEOAS の原則に従った API を採用しているウェブサービスとしては
GitHub があります。
『Web API： The Good Parts』[2015-04-09-2]
に書いてあったようだけ
ど頭に入ってなかった。Go言語は関係ない。
P285
Go言語の場合、ヒープに置くかスタックに置くかは、コンパイラが自動的
に判断します。new で作っても、その関数内でしか利用されなければスタッ
クに確保されます。ローカル変数として宣言しても、そのポインタを他の
関数に渡したり、関数の返り値として返すような場合にはヒープに置かれ
ます。そのためGo言語では、「ローカル変数のポインタを関数の返り値と
して返すと、呼んだ側からアクセスしに行ったときにはもうスタックのフ
レームが巻き戻されて無効なメモリになっており、実行時エラーで落ちる」
（中略）という C/C++ で起きるような問題は置きません。
Go言語で、メモリがスタックとヒープのどちらに確保されているかを知り
たい場合は、ビルド時に -gcflags -m を渡します。
C言語覚えたての頃、何度もハマったなあ…。
Go言語はコンパイラがだいぶ賢いね。その代償としてC言語よりはコンパ
イル時間が長いのだと思う。でも遅くないよね。
『スターティングGo言語』[2017-10-30-1]
にも書いてあったかもしれな
いけど、ここまではっきり書かれていなかったかも？