DMMのインターンで Go言語はじめてみた

Transcript

1. DMMのインターンで Go言語はじめてみた DMM.go #12
2. 自己紹介 名前 山本 瑛悟（やまもと えいご） 所属 戦略開発本部DMMTV開発部 Webアプリケーション開発グループ 昨年の11月から内定者バイトとしてお世話に なっております！！
3. はじめに 背景 • 元々ML畑の人間 → Go ましてや Webの経験すら... • 11/1 に入社 → 12/5 に初PR 約1ヵ月でPR作成 ※ 週2日なので実働で言うと 8日！ • Goって読み書きしやすい！は何が所以なんだろう？ • Goを学習する中で思ったこと
4. はじめに この発表は特定言語の優劣を 論じるものではありません！
5. 目次 • Goの言語仕様 • 便利な周辺ツール • ここが困った • まとめ
6. 目次 • Goの言語仕様 • 便利な周辺ツール • ここが困った • まとめ
7. Goの言語仕様 • 例外(try-catch)を採用してない • 三項演算子がない • デフォルト引数（省略可能引数）が無い ※代替手段有り • メソッド/演算子のオーバーロードがない あった方が便利じゃない？
8. Goの言語仕様 • 例外(try-catch)を採用してない • 三項演算子がない • デフォルト引数（省略可能引数）が無い • メソッド/演算子のオーバーロードがない あった方が便利じゃない？
9. Goの言語仕様 - 例外(try-catch) - 現状 • エラーは例外ではなく通常の値として扱う ※ 例外の機構は無い • 早期return は明示的に書く • type error として定義される エラー処理のコードが反復しやすい 提案 • check と handle を導入する提案 (Go 2 Draft) • “?” / “!” などの記号でエラーチェックを注入する系 (#32845) エラー処理の反復を減らしたい！ • 組み込み関数 try(...)を導入し失敗ならreturnを1行で書けるように(#32437)
10. Goの言語仕様 - 例外(try-catch) - • check と handle を導入する提案 (Go 2 Draft) • “?”/“!” (err?) などの記号でエラーチェックを注入する系 (#32845) • 組み込み関数 try(...)を導入し失敗ならreturnを1行で書けるように(#32437) 提案 どうなった？ すべて採用されず... • 例外を制御構造に結び付けるとコードが複雑に なりやすい • エラーチェックとハンドリングは明示的であるべき https://go.dev/blog/error-syntax
11. Goの言語仕様 - 例外(try-catch) - 「当面の間、エラーハンドリングに関する構文的な言語変更の追及を停止しま す。 また、エラーハンドリングの構文に主に関わる既存および新規の提案について は、これ以上の検討を行わずにすべてクローズします。」 問題が 「単純な構文上の冗長さ」なのか、 「優れたエラーハンドリング（情報設計）の冗長さ」なのか未確定 → この点については、さらに深く研究していきたいと考えています。 https://go.dev/blog/error-syntax おまけ
12. Goの言語仕様 - 三項演算子 - 現状 • Goのトークン定義に “?” が演算子として 存在しない • 条件分岐は文としての if/switch ※ hoge ? a:b のような構文はない コードがくどくなる(長くなる) 提案 • シンプルに三項演算子 ?: を導入したい (#33171) • 制限付き(ネストや関数呼び出しなどの制限)で三項演算子を導入する (#67959) 読みやすさ/簡潔さを改善したい！ • if/switch を式として値を返せるようにしたい (#68413)
13. Goの言語仕様 - 三項演算子 - • シンプルに三項演算子 ?: を導入したい (#33171) • 制限付き(ネストや関数呼び出しなどの制限)で三項演算子を導入する (#67959) • if/switch を式として値を返せるようにしたい (#68413) 提案 どうなった？ すべて採用されず... • 三項演算子は読めないほど複雑な式 を生む。(FAQ) • 制限付きなど例外を設けると周辺ツールにも負担 が増える とにもかくにも三項演算子は可読性を下げる要因になる らしい
14. 目次 • Goの言語仕様 • 便利な周辺ツール • ここが困った • まとめ
15. 便利な周辺ツール gofmt • 標準で提供されているフォーマッター(インデント、整列、空白など) ◦ 公式が提供しているのでコードの体裁 に関して悩むことがない ◦ 誰が書いても体裁レベルで見た目が同じになる go vet • コンパイラでは検出されないバグになりうるコードを検出 • 他にも様々な静的解析ツールが充実
16. 便利な周辺ツール go fix • 簡単に言うと、非推奨のGoコードをモダナイズ してくれるツール • Go 1.26でアップデートされて analysis framework ベースになった • -diff オプションを使用することで差分を確認した上での適用も可能 • AIくんは知識のカットオフの関係で非推奨の実装を提案してくることもある
17. 目次 • Goの言語仕様 • 便利な周辺ツール • ここが困った • まとめ
18. ここが困った - nilの型による挙動の違い - nil：型ごとの挙動が違う 型 ==nil 読み取り 書き込み/更新 pointer *T true 参照は panic 参照先への書き込み panic map map[k]V true m[k] → 0 を返す panic（m[k]=v） slice []T true len/cap → 0 要素アクセス panic append は OK interface typed nil に注意 (型, 値) -
19. ここが困った - nilの型による挙動の違い - 突然クイズ！ true false ※ エラーの比較は簡潔の為このような実装にしています。
20. ここが困った - nilの型による挙動の違い - 2025年12月26日 • ランタイム：*[]byte をインデックス/キーとするマップにおいて、マップの 値が nil でない場合でも、競合状態になると nil が返される → https://github.com/golang/go/issues/76988 2025年3月26日 • スライス: 空のイテレータの場合、Collectはnilスライスを返します。 → https://github.com/golang/go/issues/73048
21. 目次 • Goの言語仕様 • 便利な周辺ツール • ここが困った • まとめ
22. おわりに • 結局Goは初心者にとってやさしい言語？(個人的見解) • issueの議論はとても勉強になる • Gopherくんかわいい ぬいぐるみほしい... ◦ 読みという観点では YES！ ◦ 書きという観点では 五分五分！ • 可読性 > 機能としての便利さ, 表現力 ◦ AIを活用するようになって読む負荷が低いのは個人的に嬉しい
23. ご清聴ありがとうございました！