標準愚痴出力

個人的なIT作業ログです。もしかしたら一般的に参考になることが書いているかもしれません(弱気

Gopher人類とGenerics【Golang帝国興亡史】

我々Gopher人類は「Genericsは不要」と強調しすぎたのかもしれないな。「GenericsないからGoはダメ」に対する反論だけど、実際は「7~8割のケースではGenericsは要らないけど、2~3割やはりGenerics欲しい」というところだ。そこをつかれて「おまいら矛盾してる」と言われている。

ここについては今更フォローはできないんだけど、アンチの人は思い出したかのようにGoはダメ論を展開してくる。「そんなにダメなら使わなきゃいいし、うるさいんだよ」と、なんか Perl 使ってた時と同じような気持ちになった。

それはともかくGo言語には表現しづらい暗黙の常識・合理性が多い。C言語経験者なら「appendはreallocの置き換えだな。ならば旧スライス使わんほうがいいな」(※)とか直感的に思うが、それが目立つところに書いてない。そういう事例が多い故にJavaRuby勢から落とし穴と批判されるのは謙虚に認めないといけない。

(※)本当にappend後の旧スライスが使用不能かどうかは分からん(自信ない)。もしかしたら使えるかもしれないけど、あくまで一例なので、あんまり深く突っ込まないでいただきたい。


Ruby等ではCPUの1レジスタにおさまる型と別途ヒープに領域の確保が必要な型を区別せずあつかえる。これは人間の目から見た型の直交性としては正しいんだけど、一方で実装という面では「実際は違うものを同じような表現で扱うのはやっぱり無理があるんちゃうやろか」という見方もあるのではあるまいか

多分だけど、同等に扱うのに無理が生じるなら、素直に別物にしようぜと開き直っているのがGo言語だと思う(Javaもそうだけど、あちらはどちらかというと「その発想はなかった」というだけという気がする)

たとえば文字列関連のメソッド。Python 1 では Go と同じように文字列を扱う関数/メソッドは純粋な文字列のメソッドではなく、別途 strパッケージのクラスメソッドだったと思う。その後 2 になって Ruby と同様になった。だが、Goはあえて Python 2 を真似ず、1と同じ体裁をとった。

思うに「文字列関係を操作する関数の体裁をメソッドにしたら、そりゃ確かに見やすいかもしれへんけど、そんな無茶苦茶便利で快適で『なかったら困る』ようなもんか?別に Python 1 相当の体裁でも困らんかったやろ。無理にあわてて実装するような仕様かなぁ」といったところかと

要は「品質を99%から 99.9%にするのに、10倍のコストをかけるような真似」を Go言語は行わなかったと思っていただいたいということだよ。そんな無駄なコストをかけるなら、運用を楽にする方に人的資源をかけた方がよいということだね