周回遅れでerlang

GoogleのGo言語がちっとばかし話題になっている。

そこでさっそく試してみようと思ったところで、やっぱりやめてerlangに興味がわいたので、こちらを勉強してみる。

なんかもう2年ほど前に日本ではブームがあったみたいだけど全然知らんかった。
すっかり周回遅れだけどいい事もある。
バージョンR13BからはUnicodeサポートが入ったそうで、日本語も問題なく扱える。
いや、問題なくはないが少なくとも日本語一文字を一文字(の数値w)として認識できるレベルではある。
ほんのちょっと前までは8ビット文字しか扱えずひどかったみたいで。
いや、まてC言語もそうだよな。普段使ってるCコンパイラは日本語なんか認識しないぞ。

Goもそうだけど、スレッドとロックプリミティブによる共有メモリ型の並列プログラミングの限界、とそれへの新たな解の提案を言語コアに組込む、というのが今の時代なのかな、時代が要請しつつあるのかな、と思った。
つまりマルチコアCPUの台頭で、プログラムの速度を出そうとするならば日常的に並列プログラミングが必須になってきてるから、それをエラーなく楽に書ける言語を作ろうという動きだ。

マルチコアは今のところクアッドは普通に手に入るレベルになったけど、この先8、16、64、と1CPU内のコア数は増えていくのかな。128コアCPUとか見てみたいもんだな。
2年で倍に増えると楽観的に予測すれば、2012年には16コアがノートPCにも普通になっている、かもしれない。2014年には32コアか。あれ、意外とコア増加スピードが遅いような。

まあでも、コア数に比例したスピードが出るように書けるプログラミング技術があったならば、16コアであっても約10倍のスピードはいけるわけで、プログラムを10倍スピードアップさせるのがいかに大変かを考えれば、やはりそう並列機能を言語に組込んでコアをがんがん活用しようというアプローチは見逃せない選択肢だろうな。

しかし、物事がすべて同時進行するというのはハードウェア屋さんならあたりまえなのかもしれんが、ソフトウェアしかやってきてない身には厳しいなあ。
並列プログラミング。ていうか並行プログラミング、どっち？