Goを学び始めて - 未来世紀アラカワ

このブログの内容からは想像できないだろうが、自分はWeb系エンジニアとして働いている。その選択は正しかったのか今すごい葛藤しているけれども。

作者: すがわらまさのり,前島真一,近藤宇智朗,橋立友宏
出版社/メーカー: 技術評論社
発売日: 2014/10/31
メディア: Kindle版
この商品を含むブログ (1件) を見る

オシゴトではRubyばっか使ってきた。Railsが多いけど、SinatraとかPadrinoも使ったり。Railsを使っているとはいってもAPIサーバーの開発が主なのでGrape on ActiveRecordという感じもする。しかしまぁ、最近はプロダクションでRubyが遅くて困る場面があったりRailsのバージョンアップに結構な時間をとられていたり、なによりRubyしか仕事で触っていない飽きもあって「Rubyばっかじゃつまんない、Go使ってみましょうよ！」的なことを訴えてみた。すると、案外すんなり「じゃあ、導入前に既存のサービス一個Goで再実装してみて。そしてうまく行ったら部内でエバンジェリストとして頑張って」ということに。１日のうち２時間位はそれにあてていいという許可ももらった。

自分自身はこの時点でGo Tourを一周やったくらいだったんだけれども、Go歴そこそこある人を巻き込み検証をはじめてみた。

新しい言語を学ぶといろいろ良いことがある、とはきいていたけど、実際よい経験になっていると思う。RubyとかPythonとかしか触ってなかったときには気づかなかったことに気づいた。

継承はあまり必要ない

Goには「継承」のしくみがない。

package main

import (
    "fmt"
)

type Base struct{}

func (b *Base) BFunc() {
    fmt.Print("hello")
}

type Inherited struct {
    Base
}

func main() {
    i := new(Inherited)
    i.BFunc()
}

というふうに、InheritedがBaseを継承したかのような振る舞いをさせることができる。しかし、これは実は

i.Base.BFunc()

のシンタックスシュガーにすぎない。BfuncのレシーバーはあくまでBaseなのである。

オブジェクト指向設計原則にも「継承よりもコンポジション」というのがあるけど、実際継承が欲しいと思う局面はなかった。

昔右も左も分からなかったころ、「オブジェクト指向って何？」と人に聞いたら「車っていうものがあるけど、さらにスポーツカーとかSUVに分類されるよね…」みたいなよくある説明を受けたことがある。でも今思うとオブジェクト指向と継承って何の関係もないじゃないですか。(カプセル化とメッセージパッシングだよね？)

Goはオブジェクト指向言語ではない、といわれる。でも、コンポジションでプログラムを組み上げていくGoを学ぶことはオブジェクト指向な設計をするトレーニングになると思った。

ジェネリクスのありがたみ

自分はコンピューターサイエンスだとかプログラミング理論を学んできたバックグラウンドがなく、正直これまでジェネリクスと言われてもよくわかってなかった。でも、Goを触ってみて「ジェネリクスがない」ということの意味を思い知った。Rubyでやっていたのと同じように、 <コレクション>.map とやろうとしてふと気がつく。あれ、Goだとこれできないのか…。結果を格納する変数を用意して for ループをぐるぐる。なんかプログラミング勉強し始めたときのことを思い出した。