フォロー
＞Goのつらいところ
https://zenn.dev/suzuesa/articles/ec879a4b91a5ea
結局のところ Go を dis る人は「〇〇言語」のようにできないって言ってるだけで「それなら自分の使いやすい言語を使えばいいぢゃん」としか言いようがない。
Go があらゆる開発におけるあらゆるシーンにマッチするわけではないというのは明らかで，それなら Go に固執する必要もなければ，わざわざ dis る必要もない。強いて言うなら「ある開発シーンにおいて A 言語じゃなく B 言語を選択した具体的な理由」は読みたいかな。
プログラミング言語は道具・手段に過ぎない。カンナはノコギリの代わりにはならない。まぁ，ある言語で始めて「失敗した！」というのは往々にしてある話だが。それも経験だよw
Go の interface 型は使いどころが難しいよね。少なくとも Java の interface や Rust の trait とは考え方がまるで違う。 Go で Generics 導入の優先順位が低かったのはちゃんと理由がある
https://text.baldanders.info/remark/2020/04/subtyping/
Go の interface 型の実装上のポイントは「一度それを公開したら変更できない」点にある。何故なら，それがどのように使われるかは予測できないから。下手に変更するとパッケージ横断的な変更が必要になる場合がある。
だから先の記事で「Goではinterfaceに対して何か1つでも変更を加えると実装に飛べなくなります」ていうのは単に「設計が悪い」という話になる。個人的な意見だが Go では本当に必要になるギリギリまで interface 型は作らないのが正解だと思う。具象→抽象と記述していくのが Go 流だろう
https://text.baldanders.info/remark/2017/03/generics-vs-duck-typing/
そういう意味でも公称型の Java や Rust とは異なっている。