僕がGoの設計に対して 不思議に思うこと 黒澤 拓磨 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter 2024年5月21日

背景 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter Gopherの多くがGoの言語仕様やコミュニティが作りだす文化に共感している [IMO] [TRY] 言語仕様を深堀ることで、Goの強みやより良い接し方に気がつけるのでは？

発表の構成 他の言語での事例 他の言語ではどうなのか調べてみる 過去のディスカッション 過去に同じような議論がなかったか調べてみる Goにおける思想 調査する中で得られた学びをまとめてみる どう接すると良いか？ 上記を受けて、自分だったらどうするか？をまとめる 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter 自分がGoと触れ合う中で抱いた疑問をベースに下記を深堀り

Goの設計に対して不思議に思うこと その1 なぜ便利メソッドが提供されていないのか？ 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter

他の言語での事例 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜ便利メソッドが提供されていないのか？ TypeScript： map

他の言語での事例 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜ便利メソッドが提供されていないのか？ TypeScript： find

他の言語での事例 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜ便利メソッドが提供されていないのか？ TypeScript： includes

過去のディスカッション 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜ便利メソッドが提供されていないのか？ https://github.com/golang/go/issues/45955 slicesパッケージの提案 Go1.18から導入された Genericsに付随する形で提案さ れた、Sliceをより便利に扱える ようにするためのライブラリ。 最終的にAcceptされ、Go1.21 で標準ライブラリとしてリリー スされた。

Goにおける思想 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜ便利メソッドが提供されていないのか？ Simple is better 言語のシンプルさ シンプルさ&明瞭さ重視 多くの便利メソッドを追 加すること＝哲学違反の 可能性あり Minimalism 汎用性と カスタマイズ性 標準ライブラリは必要最 低限の機能を提供 標準で多くのメソッドを 追加するより、開発者独 自で実装することを推奨 Performance tuning パフォーマンスと 効率 高度に抽象化されたメソ ッド=パフォーマンスに影 響を与える可能性あり Goはシステムレベルのプ ログラミングを重視

After Before どう接するのが良いか？ 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜ便利メソッドが提供されていないのか？ Go1.18 generics ProposalをWatchしておくのは大変そうだと感じた・・・ golang.org/x/exp 内に存在するパッケージで気になるものがあれば、 そのProposalを見に行くくらいはしてみると面白い発見があるかも Proposalを見に行く

Goの設計に対して不思議に思うこと その2 GoってOOP言語なの？ 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter

他の言語での事例 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜOOP言語ではないのか？ OOP言語の代表例 OOPの特徴 カプセル化: 内部のデータを外部から直接アクセスできないようにする。 継承: 既存のクラスから新しいクラスを作成する。 ポリモーフィズム: 別オブジェクト同士インターフェースを共有できる。 抽象化: 内部の詳細実装を隠蔽し、外部に必要な情報のみ公開できる。

過去のディスカッション 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜOOP言語ではないのか？ https://go.dev/doc/faq#Is_Go_an_object-oriented_language FAQ: Is Go an object- oriented language? 公式の見解としては、Yesとも言 えるし、Noとも言えるらしい。 名前や概念が多少他の言語と異な る部分はあるが、オブジェクト指 向パラダイムでプログラミングを するためのツールは揃っている。 継承は“あえて”実装していない。

過去のディスカッション 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜOOP言語ではないのか？ FAQ: Why is there no type inheritance? 型継承は便利である一方、実装者が 予め型同士の関係を設計する必要が あったり、将来加わる変更に対して 考慮事項が増えたりする。 Goでは、これらの型継承が持つ複雑 性を排除するために、“あえて”継承 を実装していない。 https://go.dev/doc/faq#inheritance

過去のディスカッション 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜOOP言語ではないのか？ Composition not inheritance 2012年に開催されたSPLASHカンフ ァレンスでRob Pike氏の基調講演を 元に作成された記事。 「継承ではなく、コンポジションを」 というGoの設計思想について書かれて いる。 ioパッケージの例を元に、コンポジシ ョンが継承よりも優れている理由につ いて説明されている。 https://go.dev/talks/2012/splash.article#TOC_15.

Goにおける思想 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜOOP言語ではないのか？ Composition not inheritance 継承ではなくコンポジションを 継承の問題点 実装前に予め厳格な型階層設計が必要 継承階層が複雑化→上位クラスへの変更が困難に メモリとパフォーマンスのオーバーヘッド 使う側が使う時に必要なだけ組み合わせられる 👍

どう接するのが良いか？ 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter なぜOOP言語ではないのか？ Go=OOP言語ですか？ Q. 大きくYes！と言いたい [IMO] 「継承がない」という理由だけでOOP言語ではないというのは暴論すぎる 継承ではなく、コンポジションを！ OOPで問題視されていた継承の抱える課題に対する解決策を提案 他のOOP言語とは異なったアプローチ⚠️ OOPの概念を要素分解→Goの何がどの要素に当たるか考える GoらしいOOPを目指そう！！

Goの設計に対して不思議に思うこと その3 フルスタックフレームワークが主流でない理由は？ 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter

他の言語での事例 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter フルスタックフレームワークが主流でない理由は？

過去のディスカッション 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter フルスタックフレームワークが主流でない理由は？ https://www.reddit.com/r/golang/comments/15r8mk4/why_arent_go_frameworks_as_comprehensive_as_others/ Why Aren't Go Frameworks as "Comprehensive" as Others? Goのコミュニティでは“シンプルさ”が 求められている。 フレームワークとライブラリの違いに ついても触れられている。 ライブラリ＝デートに誘うくらいの“軽 い”ものだが、フレームワーク＝結婚す るくらいの“重い”ものという例え話が 面白い。

過去のディスカッション 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter フルスタックフレームワークが主流でない理由は？ The Best Go framework: no framework? Q. Goにおけるベストなフレーム ワークは何か？ A. フレームワークを利用しないこ とでは？ といった内容。 フレームワークを採用するかどう かはもっと慎重に検討されるべき 課題という主張。 https://threedots.tech/post/best-go-framework/

Goにおける思想 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter フルスタックフレームワークが主流でない理由は？ Unix哲学を元にしたGoの設計思想 Small is beautiful. - 小さいものは美しい Go=シンプルと言われる所以 ❌ 1つのもので全てのユースケースを満たす ⭕️ ユースケースに特化→組み合わせで大きなソフトウェア

どう接するのが良いか？ 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter フルスタックフレームワークが主流でない理由は？ もしも自分が、こう聞かれたら・・・ Goにおける主流なWebフレームワークはなんですか？ Q. A. Goには強力なライブラリが多数 Ref: awesome-go 個別のユースケース＝ライブラリの組み合わせで満たすことが好まれる Purpose build的な思考が重要！ 達成したい目的やユースケースを明確化 a. 必要なものはライブラリとしてimportして組み合わせる b.

まとめ 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter

僕がGoの設計に対して不思議に思うこと 疑問→言語仕様深堀り 自分がGoを使う中で疑問に感じていたこと を起点に、過去のディスカッションや公式 ドキュメントを調査。 調査する中で分かった「Goの思想やベスト プラクティス」についてまとめ、自分なり の意見を形成した。 便利メソッド なし OOP言語？ 主流な フルスタック フレームワーク なし 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter Why?

今回の調査で分かったGoの思想 “Go＝シンプル”とよく言われている理由が分かった 💡 Simple is better Composition not inheritance Unix philosophy 僕 が Go の 設 計 に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter