Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

社内イベント(CA.go#14)にて登壇した資料です。
これまでGoを使う中で生まれた疑問をベースに、過去のディスカッションやブログ記事などを調査→Goの思想やベストプラクティスを探求してみるという内容です。

【今回取り上げた疑問】
1. なぜ便利メソッドが提供されていないのか?
2. GoってOOP言語なの?
3. フルスタックフレームワークが主流でない理由は?

Takuma Kurosawa

May 23, 2024
Tweet

More Decks by Takuma Kurosawa

Other Decks in Programming

Transcript

  1. 僕がGoの設計に対して 不思議に思うこと 黒澤 拓磨 僕 が Go の 設 計

    に 対 し て 不 思 議 に 思 う こ と Hanoi Devcenter 2024年5月21日
  2. 背景 僕 が Go の 設 計 に 対 し

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

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

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

    て 不 思 議 に 思 う こ と Hanoi Devcenter なぜ便利メソッドが提供されていないのか? TypeScript: includes
  6. 過去のディスカッション 僕 が Go の 設 計 に 対 し

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

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

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

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

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

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

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

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

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

    て 不 思 議 に 思 う こ と Hanoi Devcenter フルスタックフレームワークが主流でない理由は?
  16. 過去のディスカッション 僕 が 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のコミュニティでは“シンプルさ”が 求められている。 フレームワークとライブラリの違いに ついても触れられている。 ライブラリ=デートに誘うくらいの“軽 い”ものだが、フレームワーク=結婚す るくらいの“重い”ものという例え話が 面白い。
  17. 過去のディスカッション 僕 が Go の 設 計 に 対 し

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

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

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

    て 不 思 議 に 思 う こ と Hanoi Devcenter