Golang 的第一印象

由于并行处理的类型完全不同，这让人感到困惑，但每一种类型都有着不同且有趣的特点。虽然有些模糊，但对于我来说，与我相契的描述是“在写作时感受到谁是主角？”这一印象。我会在每一种语言的开头写下这个形象，并附上一些简短的特点描述。

golang： goのコード自身が主役な感じ。チャンネルでの待ち合わせ時に停止する可能性がある。コンテクスト切り替えは、プリエンプティブに勝手に行われる。メッセージは送信者も受信者も、合意の元でチャンネルを介して行う。

Erlang： メッセージ処理の周りにコードがくっつく感じ。メールボックスでの待ち合わせ時に停止する可能性がある。コンテクスト切り替えは、プリエンプティブに勝手に行われる。メッセージは送信者が受信者を決めてメールボックスへ送る。

Javascript (node)： IO処理の周りにコードがくっつく感じ。他のコンテクストがCPUを独占している間、停止する可能性がある。非同期関数の呼び出しによる(半)明示的なコンテクスト切り替え。メッセージは同一オブジェクトへの参照を介して授受する。（Node.js clusterにより複数プロセスにまたがる時は、メッセージイベントにより授受する）

Lua (OpenResty)： ホストプログラムの周りにコードがくっつく感じ。他のコンテクストがCPUを独占している間、停止する可能性がある。coroutineのメソッドによる明示的なコンテクスト切り替え。メッセージは同一テーブルへの参照を介して授受する。

这样写的话，感觉上Golang和Erlang、Javascript和Lua有些相似，但它们各自的语法风格还是有很大区别的。Golang写起来有点像写C系语言的脚本，而消息传递则似乎只使用了简单的消息收发库。或许可以用一个粗略的比喻来解释，就像在C++中使用了运算符重载的库一样。无论如何，感觉写消息传递的地方没有被限制。而Erlang则更注重于消息收发，有一种处理消息的脚本的感觉。至于Javascript和Lua的差异，嗯，这个话题有些偏离了，并且解释Javascript（node.js）的灵活性可能需要耗费相当多的篇幅，所以就略过不提了。

因此，我认为在golang中，由于消息传递的时机在上下文中是自由的，因此需要谨慎地构建消息系统，否则可能会出问题。此外，由于消息传递是主從模式中的「從」，所以用golang编写的代码很难转换成Erlang、Javascript或者lua。相反，与C++、Java、C#等C系语言的互相转换似乎更容易。无论如何，我认为在其他语言中，golang应该具备状态变量或者（类似EventEmitter的）事件标签的功能，但可以使用通道来描述分散在各处的控制流。虽然没有哪一个更容易编写，但这确实给库的作者带来了困难，而给应用程序的作者带来了便利，这是一种直观的第一印象。如果不了解更多的模式，就无法确保这一点。

此外，我觉得在编写网络应用时，可以尝试在每个会话中启动goroutine，并直接将页面切换和SPA内部状态转换作为控制流程进行编写。虽然这种写法可能很简单，但我感觉与某些库一样，与外观设计的分离可能会变得更加困难。可能值得设立这个目标，尽快实现它。

就先用CoffeeScript进行多语言开发吧，免得太不一样导致混乱。