Go Conference 2013 springに行って来ました。 #GoCon

午前中と午後はモクモクとコード書いてました。。。
XML周りの処理とかちょっとしたい感じだったので書いてみました。

「XMLの構造が分かっていたら、 Unmarshal関数を使ったほうがいいね。」

というのが感想です。
真面目にDOMを用意してみるとかなりコード書かないといけないので辛い感じ。
個人的には、XMLをDOMで操作するならRubyを使います(ぉぃ

動作速度まで測ってませんが、多分Goのほうが圧倒的速度で処理してくれるでしょう・・・。
機会があればやってみます。

以下、セッションメモ

Goでの思考方法

class = type object = value method attache any type interface はmethod(?)

# 途中から何かしてたので聞き逃した。 # 何処かにスライド上がってないだろうか？

Go言語で作るWebアプリ

Webサーバ作るときは、以下のやり方が基本

http.Serverに渡して、http.Handlerで処理する
ListenAndServerで起動する
複数のハンドラを設定できる(http.serverMux型)
ハンドラを実装するのは大変なのでhttp.HandlerFuncを使う
serverMuxを作るのがめんどいなら、DefaultServerMuxというグローバル変数を使うといい
静的なhtmlを表示する場合は、http.FileServerを指定してやればいい

Restful APIを作る

GoWebを使えば、楽にできる
リクエストの受け取りやレスポンスをxmlやjsonで返せる
ルーティング管理ができる
Controllerを作るだけでいい
インタフェースを実装すればよい感じ

テストパッケージやnginxと連携とかテンプレートエンジンとかあるので話したかった・・・

GAE/Goの話

main関数はAppEngineのRuntimeがやるので、実装しなくてもよい
構造体にデータ(kind)を作ってしまう
keyを作成する(AppEngineユーザーにはお馴染みの処理)
それからデータストアにputする
SDKはPythonが起動→Goで書いたアプリ起動の流れ
PythonとGoが連動してるのでGo単体のテストは辛い
AppEngineとGoは安心して使いづらい(単体テストが厳しいため)
Spin-Upは相当早い(Python 約386ms,Go 約48ms)
使用メモリは、Pythonに比べて少ない
Spin-Upと省メモリなので、Goは優位かも
I/O待ちがあるので、常にGoが早いと言えない
最初からAppEngineに入る場合には選択肢に入るかも
無理に既存のものを載せかる必要性はない
Pythonでメイン処理を書いて、GoをBackground処理にするという方法もアリ

# AppEngineで動かしてるオレオレのサービスの追加機能はGoで実装してみようかなぁ

GoRoutine&Channelでの並行処理

並行処理のアプローチは「メモリのシェア」、「メッセージパッシング」の２つが大体使われる
GoはCSPとパイ計算がベースになっている
slectとclosureも並行処理で使える
ユーザーランドだと関数のまえにgoをつけると、goroutineが実行できる
gotoutineの終了は、処理が最後まで行った時、return文やgo_exitでできる
channelでgoroutine同士でメッセージできる
メッセージのバッファサイズも決めれる
goroutineを複数やる場合、waitegroupを使えばいい
Worker
Selectは読み出しがブロックするのを待っている
channelにはバッファ機能があり、バッファサイズ以上を書き込もうとするとブロックする(セマフォっぽいイメージ)
Goroutineでcoroutineっぽいものもできる
複数コアを使う場合、自分で明示的にコア設定してやる必要がある
netchanが昔はあったが、今はdeprecatedになっている。(I/Fが複雑になりすぎたかららしい。ノウハウ貯まれば復活するかも)

\ # channelのcloseはレシーバ側で行うっぽい？

goroutineのスケジューラの話

スタックコントローラーやプロセスコントローラーで実行されてる
上を実現するため、Goは一部’アセンブラで書かれている
スケジューラ:G(goroutine),M(ワーカースレッド、マシン),P(プロセス。MAXPROCSに指定できる最大値はこいつ)
GOMAXPROCSは、スレッド数と同じではない(異なることもある)
スケジューラを解析していた方のメモに詳しく流れが記載されています
go buildにsオプションをつけるとどんなランタイム呼ばれてるのかわかるようになる

Goのよいところ

最初の気に入らないところ

第一印象、人形もコードもキモい！！違和感があった
似てるようで違うところが多くてキモい(C++/Java/Pythonと比較して)

良かったところ

読みやすい
シンプルな仕様(最近の言語は、便利機能多いけど複雑すぎる)

Goを書き慣れてくると・・・
印象が変わる!!

他の言語の複雑な型宣言にムカつく(複雑になってくるとGoのほうが有利)
ダックタイピングも複雑になってくると、動くことはわかるけどコードを読むときによく分からなくなる(Goだとinteeface型を作ればややこしくなくなる)
オブジェクト指向もGoのほうが便利(PythonもJavaもクラス設計をしっかりしないといけない)
スコープも調べるのが大変だし、アクセスしたいものもアクセスできないとかある(Goは大文字だとpublicそれ以外はpackage private)
未使用なコードもGoだとビルド時に検出してくれる(dependencyを残すと大規模開発になるとメンテが大変になる。どうしてものこしたければ「_」をつける)
エラー処理は、javaとかpythonはExceptionにしたがる(変なGoToしてるだけ、それは多値返せば、処理の流れは破綻しないでしょ)
panicは本当にどうしようもないときにだけ使用する。普通はエラーできっちり返してあげる設計にするべき
Goで解決したいものの多くは、サーバとかのインフラの並列処理

# 話聞いてると頷ける話で、確かに個人的にJavaはうざいと思うのは事実・・・ # 個人的にAPIのサンプルがドキュメントに載ってたらいいなぁなんて思いました。。。

goでゲームを作る

画面、音、入力のライブラリがある
なんか似たようなもので複数あるっぽい(描画だけでもGoGLとかglとか)
GoGL,go-flwでできる

大まかな流れ

1 初期化で、キー入力とウィンドウ処理をしてやる(main関数ではこれだけにする) 2 初期化のタイミングでウィンドウの設定をしてやる 3 初期化以降はメインループを実行する 4 ゲームのランを行う(ウィンドウが開いてる間実行するように実装する) 5 フレームに対して描画を行う 6 ゲームを実装してる本体でキーボードとかの入力を受け取るようにする 7 描画メソッドではひたすら描画の実装をしてやる

A Case Study

Rubyにはいいところもあるが良くないところもある
CloudFundryでEventMachineをRubyでやっていた
Rubyは特に好きだ

設立したベンチャー企業では + 複数のOSサポート + システムのスケールもさせたい + そのためGo vs Node.jsになった

Node.js

v8ランタイム
イベント駆動
JSベース
ランタイム依存
JSベースなので(コールバック地獄)
実験的な機能が・・・

設計メンバーが良かった
同期モデル
プラットフォームのサポートがよかった
新しい言語
標準ライブラリはどう使えば？
GCやスケジューラが隠れている

いいところが多いので15分でGoを採用することになった(チームで決めた)

学習が簡単だった
標準でライブラリが揃っている
なぜGoなのか(聞き取れなかった)
GoのGCはスタックベースなので良かった。
暗号化通信はOpenSSLのラッパーを用意した(パフォーマンスの問題？)
文字列とバイト配列の変換
SQLは低レベルすぎて辛いのでORMとドライバーは自前で用意した
mapも遅い。多分1.1で治るはず・・・
いけてない面もまだまだあるけど、Goを選択したのはよかった
GoはIaaSやPaaSで主役になれる!!

まとめ

GoはGoogleが採用しているだけあってシステム書くには向いている
Goは標準ライブラリが揃っている
テストやドキュメントもビルトインである
学習も楽にできる
GCもStackベースなので遅延が起きることは少ない
いくつかの問題は1.1で解決されることに期待!!

# 最後のセッションのこいつはうろ覚え(聞き取りながらで辛かった)

感想

Goに関してのいいところや悪いところを吸収できたかなーと思う。
密度が濃い一日だったと思いました。　　なによりGoでモクモクできたのが良かったなーとおもいます。(まともに書いたのはアーリーアダプター以来だった思う。。。) コンパイルと実行が下のコマンドでできることには驚いた。(昔は8g,8lとかしてたコンパイルしてた記憶)

$go run <プログラムファイル>

仕事でシステム周りの実装するならGo言語をぜひとも採用させたいですね。。。