2019/08/07


Google の方からお誘いを頂き、Google Developers Expert (Go) になりました。

僕のこれまでの Go に対する活動を評価頂けました。僕が Go を触り始めたのが2009年、今から10年前でした。Go はまだメジャーリリースすらされておらず、誰も仕事で使っていない言わばホビー言語でした。

一部のアーリーアダプタが「この言語、面白い」という言葉を残し飽きて来た頃、僕は職場で自前のツールを Go で書くようになりました。それまではC言語でした。

マルチプラットフォーム、速いコンパイラ、ポータビリティの高さ、簡単な記述での並行処理、色々な物に惹かれました。特に、シングルバイナリで動作し、コンパイルし直しさえすればソースコードを書き直す事なく Windows で動き、なおかつマルチバイトの問題も発生しない、こんな夢の様なプログラミング言語はそれまで見た事が無かったので、Windows ポーティングを趣味にしている僕にはとてもマッチしました。

オフィシャルにも色々とコントリビュートさせて頂きました。StackOverflow 等の Q/A サイトで Go に関する質問に回答を書いたりもしました。Go の楽しさや便利さを皆と共有したくてブログを沢山書きました。共著で本を執筆したりもしました。普段、仕事では色々なプログラミング言語を使いますが、今では仕事で一番使うプログラミング言語が Go になりました。

僕だけの話ではありません。今や業務で Go を使っておられる会社は沢山あります。Go の求人もあります。そして Go を使う人はこれからさらに増えると思います。僕が Google Developers Expert になる事で Go の何かが変えられるのならば、ぜひ後押ししたい。そんな気持ちで今回のお誘いをお受ける事にしました。

肩書きが1つ増える事になりますが、僕の Go に関する活動は今後も変わりません。

ブログを書き、パッチを書き、Go のプログラムを書く。これが僕の Go に対する活動です。もしかしたら Go のイベントにチラッと現れるかもしれません。

職種上、皆さんの前に頻繁に出てくる事はありません。ただもし何かのご縁でお会いする事があれば、その時は遠慮なくお声掛け下さい。

宜しくお願いします。

Posted at by



2019/08/06


Go の標準パッケージのコードには稀に意図的にそうなっているのか分からない、速度に寄与するのかどうか確かめたくなる物が入っている事があります。

先日も見つけました。まだマージされてないですが、os.Mkdir に NUL という文字列を渡した時にファーストパスでエラーを返す変更です。

186139: os: return an error when the argument of Mkdir on Windows is os.DevNull
https://go-review.googlesource.com/c/go/+/186139/5/src/os/file.go#563

ここで出てくる以下のコード。

func isDevNull(name string) bool 
    if len(name) != 3 {
        return false
    }
    if name[0]|0x20 != 'n' {
        return false
    }
    if name[1]|0x20 != 'u' {
        return false
    }
    if name[2]|0x20 != 'l' {
        return false
    }
    return true
}

3文字の NUL を大文字小文字無視で比較しています。ビットマスクで大文字小文字を同一視しつつ、1つでも条件にマッチしない物があれば即 false を返すという古き良きC言語的なハックが使われています。

さて、このコードは本当に速度に寄与するのでしょうか？

package lowercase

import (
    "strings"
    "testing"
)

func isDevNull1(name string) bool {
    if len(name) != 3 {
        return false
    }
    if name[0]|0x20 != 'n' {
        return false
    }
    if name[1]|0x20 != 'u' {
        return false
    }
    if name[2]|0x20 != 'l' {
        return false
    }
    return true
}

func isDevNull2(name string) bool {
    if len(name) != 3 {
        return false
    }
    if name[0] != 'n' && name[0] != 'N' {
        return false
    }
    if name[1] != 'u' && name[1] != 'U' {
        return false
    }
    if name[2] != 'l' && name[2] != 'L' {
        return false
    }
    return true
}

func isDevNull3(name string) bool {
    return strings.ToLower(name) == "nul"
}

var tests = []struct {
    in     string
    result bool
}{
    {"nul", true},
    {"Nul", true},
    {"nui", false},
    {"lun", false},
    {"nulllllllllllllll", false},
    {"nuuuuuuuul", false},
    {strings.Repeat("N", 3000), false},
}

func test(b *testing.B, f func(string) bool) {
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        for _, test := range tests {
            if got := f(test.in); got != test.result {
                b.Fatalf("want %v but got %v for %v", test.result, got, test.in)
            }
        }
    }
}

func BenchmarkS1(b *testing.B) {
    test(b, isDevNull1)
}

func BenchmarkS2(b *testing.B) {
    test(b, isDevNull2)
}

func BenchmarkS3(b *testing.B) {
    test(b, isDevNull3)
}

isDevNull1 が今回のコード、isDevNull2 が改良前のコード、isDevNull3 が入力文字を予め小文字に変換し比較するコードです。ベンチマークの実行結果は以下の通り。

goos: windows
goarch: amd64
pkg: github.com/mattn/go-sandbox/b3
BenchmarkS1-4           47997120                25.5 ns/op
BenchmarkS2-4           41377027                28.5 ns/op
BenchmarkS3-4             136354              8786 ns/op
PASS
ok      github.com/mattn/go-sandbox/b3  3.840s

Windows 64bit Core i7 16GB の結果です。今回改良されるコードが微妙ながら速度に寄与している事が分かりました。逆に言えばこの程度しか寄与していないので、可読性を優先する様なコードであれば isDevNull2 で充分かなとも思います。

Posted at by



2019/07/02


Go は Ducktype をサポートしたプログラミング言語です。interface で宣言されたメソッドを型に強制したり問い合わせたり出来ます。メソッドの実装を保証する為に以下の様に struct に interface を embedded する事も出来ます。

package main

type I interface {
    doSomething()
}

type foo struct {
    I
}

func (f *foo) doSomething() {
}

func callSomething(i I) {
    i.doSomething()
}

func main() {
    callSomething(&foo{})
}

ただしこうしてしまうと型 foo の情報にインタフェースの情報 I が含まれる事になり、struct のサイズが数バイト(アーキテクチャによります)大きくなってしまうのです。

package main

import (
    "fmt"
    "unsafe"
)

type I interface {
    doSomething()
}

type foo struct {
    I
}

func (f *foo) doSomething() {
}

type bar struct {
}

func (b *bar) doSomething() {
}

func main() {
    fmt.Printf("sizeof(%T) is: %v\n", foo{}, unsafe.Sizeof(foo{}))
    fmt.Printf("sizeof(%T) is: %v\n", bar{}, unsafe.Sizeof(bar{}))
}

https://play.golang.org/p/gpgX4teDhki

64bit の OS では16バイトです。配列になればもっと大きなサイズになってしまいますね。embedded をやめてしまってもコンパイル時に気付けるので問題ないのですが、ライブラリパッケージの場合はそれを使用するコードが無いのでテストを実施するまで気付けない事になります。なんだか時間が勿体ないですよね。そこで以下の様におまじないを入れておきます。

package zoo

var _ I = (*foo)(nil)

type I interface {
    doSomething()
}

type foo struct {
}

func (f *foo) doSomething() {
}

こうする事で、万が一 interface のメソッド宣言と struct のメソッドが不一致であっても即座に気付ける事になります。最近の Language Server を実装したテキストエディタであれば書いた瞬間にエラーになってくれるので、CI で実行するまで気付けないといった時間の無駄を削減する事が出来ます。

この方法は Go の FAQ にも書かれており、Go 本体のソースコードにも沢山書かれているテクニックです。

How can I guarantee my type satisfies an interface?

ぜひ無駄のない Go ライフを。

Posted at by