Go を2年くらい書いた感想: 意図をエンコードしきれない感じは消えず - blog.8-p.info

ここ2年くらい、仕事では大体 Go を書いている。jmuk さんが Go言語は、なんというか「ちょうどいい」言語だな、と思っている。異論は認める。 と書いていたけれど、私はやっぱり Scala や Kotlin あたりが好きで、これは変わらなそう。 例えばコレクションを map しているのをみると、私は「なるほど、ここではコレクションの要素数は変わらないんですね」と思う。filter だったら「コレクションの要素数は変わるけど、個々の要素は変わらないのか」ということを、あるいは Result を map していたら「ここではエラーのほうは触らないのね」ということを読みとっている。 こういう意図が、素朴な for ループと、if err != nil だと読みきれなくて、いや真面目に字面を追っていけばわかるんだけど、私が「map するか」と思いながら for ループを書いて、その for ル

[j5ik2o]

わかるofわかる。ドメインモデルはWhat偏重で、インフラストラクチャ層はHow偏重なコード表現が一番バランスがいい。Scala, Rustは前者に、Goは後者に向いていると思う。

[mattn]

C言語だと関数にくくって関数名で表現するのが一般的ですかね。

[boomerangj]

気持ちはわかる。が、選択肢が増えてしまうんだよな。大量にある中から最適なものを選び出すのはメンバーに求める能力も学習コストも大きく、練度が低いチームで書かれると無駄にアクロバチックなだけのクソコードが

[turanukimaru]

「Scalaz が提供する色々とか（略）存在を知っているけど使い道がわかっていないもの」がまさにGoの忌避するもので頑張って理解しても使う場面があると限らないし無理して使っても他の人が読めない。Kotlinくらいが丁度良

[knjname]

同意　あとKotlinやScalaが丁度いいのと自分の認識する語彙自体成長が見えないところの不安感も同意

[cocoasynn]

自分はどちらかと言うとGo好き側だけど、内容にはなるほどと思ったしこういう主張もあっていいと思うんだよな。

[mushus]

Go好きはだけどたしかに自分もそのへん不満に思ってた。たとえ関数名っていう形が表せても、その中身の処理自体はmapとかconstとかの語彙で表したい。

[aike]

当たり前だけど目的に合わせて言語を選ぶのが良い。Goは原始的でシンプルなツールをさくっと書きときに便利。IoTで動かす小さなプログラムとか。

[rgfx]

エスキモーの（特定方面に豊富な）語彙が性にあう、みたいな話に見える。または、道具が多ければ多いほど良い、みたいな。

[strawberryhunter]

その結果、否定派にとって受け入れがたいレベルでコード量が増えるというのが最も説得力のある意見だと思う。／GoはGenericsが導入されたら再評価しようと思ってる。

[yuzu441]

派生してる議論等追っててforeach相当をmapで書いてるアーキテクトクラスの人を思い出した

[zu2]

GOTOだけでloopを書いてた時代を思い出す

[hdkINO33]

“一方で、私の知っているプログラミング言語の語彙は、過去の経験からくるバラバラな機能のセットでしかなくて、それが Scala や Kotlin のところで止まっていることには一抹の不安もある。”

[mas-higa]

for ループから意図を読みとるのはいやだなぁ

[arx0balest]

他人のGoコード読んでて「これ本気で読みやすいと思って書いてるンか？」とはよく思う。

[xorphitus]

関数化して命名で表現するのは割とどの言語でもやると思うので、それでもこう言う話が出てくるのは、その内側の実装に対してか、あるいは命名だけに依存したくないとか、そういうのなのでは

[zyzy]

結局コンパイラ言語だし言語的な見た目は大分違うけども、コンセプトというか根っこの哲学はPythonに近いのかな、と思う。シンプルの方向性をスクリプト言語としてつきつめたらPythonというか。

[nilab]

「私はやっぱり Scala や Kotlin あたりが好きで、これは変わらなそう」

[a235]

大変よくわかるのでRustを使ってる。関数名やコメントで表現するだけで間に合うならC言語で十分。

[hate_nao]

Scala触ってみたい

[yarumato]

“mapは「要素数は変わらない」。filterだったら「要素数は変わる。個々の要素は変わらない」と「意図」を読みとっている。意図をプログラミング言語の語彙で表現したい。Goはできない。ScalaやKotlinはできる”

[blueboy]

　Go　＋　map, filter　ならば完璧？

[yo_waka]

なんか分かる

[onesplat]

同意だけど他にもっとあるだろ

[chinpokomon_master]

Idrisとか大好きだしScalazも使ってたけど、とにかくコンパイル遅いのと型エラーが人知を超えてるのに辟易してたので、GoにはGoのよさがあるって感じ。実用ならGoはほんとちょうどよいよね。

[katzchang]

コレクションライブラリは使いやすいんだよね、Scala。

[PEEE]

わかる。Kotlin好き。

[pascal256]

これには強く同意だし、語彙も同じ当たりで止まってるのでどうするかだよなー

[miragestlike]

for文とイテレータの論争、やっとしっくりくる表現がきた

[ichiken7]

抽象化を生産性に結び付けられない焦りのような感じ？

[daimatz]

Go の好きなところ：ツールチェイン、スケジューラ、静的コード生成文化 / Go の嫌いなところ：構文、型システム、コレクションライブラリ

[flont]

シンプルさを優先してるのでそこはサポート範囲外なんだろうけど、じゃあ他の言語でいいやとなって結局使わなくなったな

[unhappychoice_e]

モナドですっと副作用分離できない限り、一定以上の複雑さに対応できなくて設計も可読性も何もかも終わる未来しか見えないので Go は採用できない。 そこ諦めるならRust か C があるし。

[kkobayashi]

今の時代には素朴すぎるのかもね

[buhoho]

語彙が少ないことの功罪

[macj_jp]

読んだ