Goでツールを作る

Goをツールを書いた。

解いた問題

リモートホストにあるログをsftpで落としてくる手続きを、バッチ処理にしただけのもの。

諸事情によりリモートもローカルも環境をいじれない場合などに、パスワードとセットでSSH接続しつつファイルを落としてくる。

いちおう自作プログラムを使わない解もあるようなので、別にこんなツールを作らなくてもいいのかもしれないけれど。

確かにGoの学習曲線の低さは感じた。

おおむね1日くらいで書いたけれど、構文的に詰まることはほとんどなかった。

標準でついている gofmt などのツールとVimのプラグインの相性がとてもよい。書いたコードが片っ端から整形されるのに慣れると、自分の粗雑さをGoのツールチェインが一歩後ろから尻拭いしてくれているような気分になる。怠惰な人間を支えてくれるいい仕組みだなと思った。

やはり型検査があることがコードの変更の敷居を下げていると実感。インタフェースの変更を行って整合の取れなくなった部分はコンパイラが指摘してくれる。

エラーの出たところを直していけばいつの間にかプログラムが安定している。これまた短期記憶の少ない人間を支えてくれるいい仕組みだなと思った。

APIの事前条件を満たしていなくて、 nilを受け取って実行時エラーになった箇所があった。

しっかりエラーハンドリングしていればもっとマシなメッセージを出力できたのだが、それにしばらく気付かず表面的なnil地雷の切り分けにはまってしまった。

Haskellと違ってnilに苦しめられることがあり得る以上、そこに注意するようなプログラミングスタイルからは逃げられない。

多くのAPIでエラーが返却される。今回は逐一ハンドリングする愚かな実装となってしまった。

よりよいハンドリング方法を事前に設計できていないと、いつまでたってもエラーハンドリングがコードの半分を占める、みたいなことになりかねない。

これはGoの上達をする上での大きな壁になりそう。

とにかく有用なAPIさえ覚えていればガーッと書き下せるのは、確かに生産性高いと言ってもいいのかもしれない。

ただし、ポインタやエラーハンドリングなど、安全なプログラムを書くためにはいくつか超えなければいけない壁もあると解った。

Haskellと比べて、プログラムを書く時に考えている時間よりもコードを書いている時間の方が長い感覚があった。バリバリ書く、を地で行くプログラマにはなるほど気持ちがいい。

Pythonで軽めのツールを書いていた状況を置き換えるには確かによいかもしれない。 (Clojureでもいいのだけれどメンテを考えると...)