Go言語のポジションが分からないので、現在の理解を整理する随想
仕事でGo言語を触るようになって、考える機会が多くなったのだけど、私は未だにこの言語のポジションが分からない。皆、どのような用途でGoを使っているのだろうか？
Goは、システム開発言語ではないと聞いたことがある。システム開発言語に不適格な仕様を持っているとは思えないのだけど、Rustがその位置にいるので、GoはWebの、サーバーサイドに収まっているのだろう。
Goを設計したのはロブ・パイクとかケン・トンプソンとか、その名をコンピュータ史に刻むことになるのは確実であろう、元AT&Tベル研究所の“UNIX GODs”だ。C言語やUNIX OSといった’70年代から現在まで使われているコンピューターのスタンダードと呼ぶべき環境を作った、その当時の震源地にいた人間たちだ。間違いないだろう…というのが、触る前の私の期待だった。一方、私個人としてはCやUNIXといったものに対しては、その暗号めいた使い心地がどうにも好きにはなれず（“UNIXはpleaseとは決して言わない” — — ロブ・パイク）かといってWindowsなんぞクソ喰らえと思っている。
その後の彼らの活躍は“UNIX40年目の回答”であるOS・Plan9 from Bell labsに結実するのだけど、私はよく知らない。これがベル研の外に出て、Inferno（地獄）だとか、その開発言語がLimbo（煉獄）だとか、どうにもネーミングがよろしくない商用OSになった。いつだったか、UNIX magazineだったかSuper ASCIIだったか、要はPCではないワークステーション以上のコンピューター雑誌にInfernoが紹介されていたときにそれを読み「そんな地獄っぽい名前じゃ受けないだろう」と思ったものだった。
彼らの理想に反するのが市場だった。「UNIXはそのユーザに、銃に弾を込めて安全装置を外して足に銃口を向けて発砲することを許可する」と誰かが言っていたが、そのような危ない操作を許可させない仕組みがあったのだろうか？いや、たとえば su rm -fr / の禁止のような。macOSは基本 sudo で一度ずつのコマンド操作にして「漫然とスーパーユーザ」にはさせなかったし、後年になって別の仕組みが導入されたかもしれないが、私は情報をキャッチアップしていないので知らない。
それでは開発言語はどのような進化を遂げたのだろうか？私はInfernoの詳細を知らないので自然とGoに目が向く。GoはGoogleからリリースされた。’70年代、アメリカの頭の良い人はテレコム業界の研究所にいたが、その後、皆揃ってGoogleへ行ったようだ。Googleいいよねー、フリーランチで。
Goの仕様を少し見て驚いた。メモリ確保の new/delete が無い。C風の malloc/free もない（ガベージコレクションがあるので）。C++にあった class 構文がない。継承もない。カプセル化は？ポリモーフィズムは？
あれ？もしかしてベル研の連中はC++をCの正統後継者として認めていなかったのでは？と感じた。あんなものは、デンマークかどこかのヒゲのオッサンが勝手にCを改造しやがったもので、Cの良さを台無しにしていると感じているのでは？（C++設計者のビャーネ・ストロヴストルップもベル研にいたようだけど）
私は凡人だから、C++はCのver.2だと思っていた。いつだったか、Linuxカーネルのメーリングリストで「なぜLinuxはC++で書かないのだ」と投稿した奴に対してリーナス御大が「C++を採用しないメリットは、お前みたいなバカが寄り付かないことだ」と言い放ったことがあった。
つまりUNIXハードコア設計者たちはC++の設計上の問題をとっくに承知の上で、この’70年代の言語をいまだに使っているということだ。笑ってはいけない。私達も、UNIXなる’70年代のOSを使っているじゃないか。iOSは？Androidは？ぜんぶUNIXベースのOSだ。Windows？そんなのあったっけ？
先月からGo言語を使ってみての、私の今の所の感想は「Cの現代版であるな」という、退屈極まりないものだ。しかしC++を完全に無視したことには驚かされる。C++とその精神的後継？であるJavaやら、C#やらその他あまたのオブジェクト指向プログラミング言語をスキップして、ガベージコレクションや、正規表現その他、コードの行数を減らすための仕組みがあるのは現代では当然として、新しい仕組みというのがGoには備わっているのだろうか？本を1冊読んだだけではよく理解できなかった。とくにInterfaceの考え方がC++/Javaなどと違うので、いまだに自分の中で咀嚼できていない。
だからこれは、設計者が書いた本を読むしかない。さっそく注文した。
共著者の中に、ブライアン・カーニハンがいる！カーニハン＆リッチーの共著「プログラミング言語C」といえばC言語のバイブルであり、私は軟弱者なので読んだこと無いけど、その例題として書かれたコードの hello, world ぐらい知っている。
スクリプト言語と比べて
私が知っているスクリプト言語といえば宝石キラキラ系、すなわちperlとかrubyとか、pythonはヘビだから知らないとして、あと末席の電話番の鞄持ちとしてPHPも知っている。こいつらは殆どが’90年前後の設計なので、オブジェクト指向プログラミングの要素を取り入れている。
Goはスクリプト言語と比べて実行速度が速いそうだ。そりゃそうだ。コンパイル言語なのだから、ネイティブコードで実行できるGoは有利だ。しかしそのメリットというのが、「重い処理を実行させたとき」に、どうやら限るらしいということも聞いた（典拠なし）。Webアプリで重い処理というか、ボトルネックは何だろうか？もしかしてDBでは？ネットワークでは？と考えると、Webアプリでコンパイル言語のメリットというのは、そう無いのではないか、と感じる（個人の印象です。証拠なし）。
私が一番重要視するのが、効率だ。これも個人の印象だけど、同じ処理をスクリプト言語で書くのと、Goで書くのでは、Goの方が全般的に行数が多くなる傾向があるような気がする。それに例外処理が入っていないので、以下のようなコードをひたすら書く必要がある：
err := anyFunction(arg)
if err != nil {
// ここにエラー処理
}
err = otherFunction(arg)
if err != nil {
// ここにエラー処理
}この、一歩進んでエラー処理、というのが読みにくいから例外処理が導入されたのでは？CだとC99規格になるまでbool型が導入されなかったので、戻り値はint型の0か1かであり、どちらが真でどちらが偽か？というのでよく間違えていた。
エラーハンドリングについては、Cから何も進歩していないように見えるけど、設計者に問いただしてみるしかないだろう。
比較的新しいGo言語であるが、「Goを採用したら開発効率が上がりました！」とはならないだろう。コード量が増えるので、効率は下るのではないか。しかしそこまでして実行効率を求めるなら、このトレードオフを受け入れる必要がある。となれば、Goを採用すべき箇所は畢竟、「Webアプリのサーバ側全般」ではなく「特に重い処理をコンピュータにさせる箇所」ではないのか？単なるRESTサーバにGoを採用するのは、もう一度考え直したほうが良いかもしれない。
Goのもう一つの特徴は、それが静的型付け言語であるという所だ。型は静的が良いのか、動的が良いのか、これは何十年前から論争があり、未だに決着していない。当たり前だ。答えは「時と場合による」だからだ。
私個人の、何の根拠もない単なる感想を言えば、Webアプリに型なぞ関係ないかな、と感じている。Webアプリの型というのは要するにHTTPでPOSTされてくるJSONなりの形式、返すJSONの形式、のことのように思える。これをどのように設計・管理するのか？「Webアプリにおける型」とは、その程度のものなのでは？
私はスクリプト言語で、少ない行数で書きたいけどなあ。みなさんはどうですか？これ以上は「プログラミング言語Go」を読まないと書けない。
