はい、初期は cap は覚えない方がいいです。

fmt.Println(s) の後に 1, 1 になったのは fmt.Println を呼び出した事で、スライスの中身 (ptr, len, cap) がコピーされたからですね。まぁここは意識しなくて良いです。

なんでそんなにメモリの伸長にこだわるのかというと、コンピュータでメモリの伸長ってめちゃめちゃ遅いからです。 [a][b][c] に [d] を足そうとしても、[c] の後ろに既にほかのメモリが占有しちゃってるかもしれないので、[a][b][c][d] が収まるメモリの空きを探して、見つかったら元の位置から全メモリを転送する、みたいな事をしてるんですよね。なので遅い。

例えば、append していくけど、必ず100個以内で収まると分かってるならスライスを s := make([]string, 0, 100) と作っておくと s = append(s, "foo") を何回やってもメモリの伸長が行われないんです。(最初から作っちゃってるので)

var s []string fmt.Printf("len=%d cap=%d\n", len(s), cap(s)) // len=0 cap=0 s = append(s, "hello") fmt.Printf("len=%d cap=%d\n", len(s), cap(s)) // len=1 cap=2 こうです。cap が出てうるのは append か make を使う時だけです。

オートマトンの嘔吐の部分

cap は capacity。そのままです。 s = append(s, "foo") でスライスを毎回、伸長してたらコンピュータに負荷が掛かるんですよね。 なので 12 個の配列と言いながら実際には 15 個分、メモリが確保されてたりする訳です。でも 12 個以上はアクセスさせたくない。 この時の 12 が len で 15 が cap です。

新しい言語を学ぶ時に僕は * JSON パーサ * Lisp 処理系 * Todo ウェブアプリ とかを書いてみてるんだけど、どうやらその1つに Nostr リレーが増えた様だ。Nostr リレーが書けるくらいなら仕事でも使えるはず。そういう点では Lua はプラグインは書けるけどシステムは書けない。

僕も依然、gleam ちょっとやったんだけど、まだ標準ライブラリが安定してなくて、世の中に出回ってる情報が追い付いてなくて、ネットの情報のまま実装するとエラーになってる。

趣味言語は趣味言語で気がすむまで触ったらよろし。ただし趣味言語は一生仕事で使わないかもしれん。たぶん僕の業界であれば moonbit も nim も crystal も仕事で使う事は一生ないだろう。 もしかしたら Rust でさえもないかもしれん。Go は仕事で使ったし、というか僕が今の職場に持ち込んだし、今も使ってるし今後も使うだろう。 僕の中ではもう Go は js/html/css と同じなのだ。