Rust が最強のプログラミング言語である証明
2017 年現在、Rust が最強のプログラミング言語である証明を以下に示します。
ICFP プログラミングコンテスト
ICFP プログラミングコンテストの説明については以下をご覧ください。
ICFP Programming Contest は「なんでもあり」が特徴の，他とは一線を画す特徴的な プログラミングコンテストです．ACM の関数型プログラミング言語の学会 ICFP (International Conference on Functional Programming) に伴って毎年開催されてい まして (1) プログラミング言語自由 (2) 計算資源自由 (2) チーム人数制限なし (3) 72 時間勝負 (4) 問題の形式も毎年大きく変化，等の特徴があります．優勝者は「その 年のプログラミング言語」を決めることとなっており「その年はその言語の文句は言え ない」とか．
引用元: http://iwiwi.hatenablog.com/entry/20130927/1380255924
コンテスト優勝チームが使用した言語は「優秀なハッカーに選ばれたプログラミング言語」として正式に認定されます。さらに優勝チームには「使用したプログラミング言語を一年間無制限に自慢してよい」という名誉ある権利が与えられます。
そのため ICFP プログラミングコンテストは「最強のプログラミング言語を決める大会」という側面があります1。
最近は以下のような風潮もあるようなのですが:
実は最近のICFPContestに対する参加者の態度にやや疑問を持っているんだ…
— Noriyuki OHKAWA (@notogawa) August 4, 2017
最強言語認定を自分の好きな言語に与えるために勝利を目指すんだと思ってたんだけど、まず勝つこと先行でそのためには混成言語編成チームでもかまわないみたいなのは風情に欠けるんじゃないかって
それでも「自分の好きな言語に優勝させてやる！」という熱い思いをもった参加者が今年も大勢参加しました。
2017 年、今年のコンテストを主催したのはオックスフォード大学です。
Rust で参加
私は昨年に引き続き Rust で参加しました。8 月 4 日から 8 月 7 日にかけての 72 時間です。
今年の問題
今年の問題を簡単にいうと「鉱山（λ）に道をつなげてより多くの都市（λ から遠ければ遠いほど高得点）に到達しましょう。」という問題でした。実際のルールはもっと複雑です。興味がある方は、実際の問題仕様を見てください。
「百聞は一見にしかず」、以下の実際に行われた戦いの様子をご覧ください。私はチーム hayatox です。
(Link, その他の大きなマップでの戦い: Map: junction, Map: nara)
結果
参加者から提出されたプログラムをもとにした、コンテストの1st ラウンドの結果が今週発表されました。それによると参加チームは 146 チーム。そのうち 26 チームは提出したプログラムが仕様を満たしていないことが判明し参加不可能。残りの 120 チームの間で戦いが行われました。
果たしてどの言語が今年は最強の名を手にするのでしょうか？
各チームの使用した言語は現在のところコンテストのサイトでは明らかになっていません。そのため以下の条件で各言語を代表するチームを適当に選びました。
- GitHub を"icfp 2017"で検索
- メインで使用した言語がほぼひとつであることをチェック(そうでなければスキップ）
- チーム名が README 等に記載されている
- 1st ラウンドの結果にチーム名が載っている -> 採用
各プログラミング言語とそれを使用したチーム 2 とその人数 3 、そしてチームの獲得ポイント 4 です 。
| 使用言語 | チーム名 | 人数 | 獲得ポイント |
|---|---|---|---|
| Rust | hayatox | 1 | 109 |
| C++ | GennAI | 8 | 106 |
| Haskell | Sampou | 7 | 108 |
| Common Lisp | cvnm | 1 | 69 |
| Clojure | drop table teams; | 2 | 38 |
| Java | A Storm Of Minds | 2 | 109 |
| Kotlin | Lambada Calculus | 9 | 86 |
| Scala | codingteam | 4 | 48 |
| C# | kontur.ru | 16 | 70 |
| F# | lambda-llama | 5 | 0 |
| Elixir | The Mikinators | 8 | 42 |
| Python | Lambding Snakes vs Coding Monkeys | 4 | 94 |
| Go | MIPT Lambda | 3 | 64 |
- Rust 十分強い。しかし最強という感じはまだ受けません。
- ほとんどのチームは複数人で参加していることがわかりました。ひとりで参加している「ぼっちチーム」は Rust 以外は Common Lisp だけです。さすが Lisp。孤高の存在。
- 特に C++を用いたチーム GennAI は 8 人中 7(?)人が Google のソフトウェアエンジニアです。
- さらに特筆すべきは C#を用いたチーム kontur.ru。なんと 16 人チーム！もはや数の暴力です。
正規化
数の暴力にはこちらも理不尽な理論で対抗するしかありません。「獲得ポイント」を「チームの人数」で割ってやりましょう 5。正規化した結果は以下のようになります。
| 使用言語 | 正規化 |
|---|---|
| Rust | 109.0 |
| C++ | 13.2 |
| Haskell | 15.4 |
| Common Lisp | 69.0 |
| Clojure | 19.0 |
| Java | 54.5 |
| Kotlin | 9.6 |
| Scala | 12.0 |
| C# | 4.4 |
| F# | 0.0 |
| Elixir | 5.2 |
| Python | 23.5 |
| Go | 21.3 |
以上により Rust が最強であることが示されました 6。証明終わり。
おまけ
RustでICFPCに参加した同僚「コンパイラがチームメイトみたいなもんでしたよ」
— いもす (@imos) August 8, 2017
そういえばコンテストの翌日にオフィスで会った時そんなこといった気がします。:)
実際、私は大したことはしていません。今回は合計で 12 時間くらいしか参加しておらず、仕様もすべては実装していません 7 。それにもかかわらず最低限動くプログラムを完成・提出できたのは、すべては Rust という素晴らしい言語を作成したコアチームと、crates.io という素晴らしいパッケージ ・エコシステムのおかげです。今回のコンテストではじめて使用したライブラリがいくつかありますが、すべて苦労することなく使用することができました。私は巨人の肩に乗っ かっただけです。
来年に向けて
- 「私の愛する JavaScript が Rust ごときに負けるはずがない。」
- 「はっはっはっ。自称最強 Ruby 使いであるこの私が出場していない大会で良い成績をとることに何の意味があるというのか？かわいいやつらめ。」
- 「その証明には致命的な誤りがあります。どこが間違っているかというと....」
もっともなご意見でございます。しかしながら、参加しない人に反論する権利はまったく与えられないのがこの ICFP プログラミングコンテストです。
唯一の正しい反論の方法は「机上の空論を展開」することではなく、実際に「愛する XXX 言語を勝たせてやる」ことです 8。ぜひ来年の ICFP プログラミングコ ンテスト 2018 に参加してみてください。
興味をもった方は雰囲気をつかむため過去の問題に挑戦してみるとよいかもしれません。特に 2006 年カーネギーメロン大学が主催した「古代文明が作ったコンピュータの仕様とその上で動くプログラムを記した古文書」を巡るコンテストは「神回」として伝説になっています 9。ぜひ挑戦してみてくださいね。
footnotes:
ICFP 学会としては、コンテストを通じて「関数型プログラミングの優位性」を示したいという思いがあったはずなのですが、コンテストでは 必ずしもHaskell のような「いわゆる関数型プログラミング言語」が優勝するとは限りません。主催者かわいそう。
チーム名をここに記載すべきかどうか迷ったのですが、各言語のコードを見ることは読者にとっても有益だと思い、リンクと共に載せていま す。特に C# チームと F# チームの README は非常によく書けていて勉強になります。
各チームの人数は、レポジトリの README にメンバーが記載されている場合はそこから、記載されていない場合は実際にレポジトリに貢献した人数で判断しています。
獲得ポイントは 1st Round の結果のみを使用しています。最終結果は ICFP（学会の方）当日、現地オックスフォードで発表されます。最終結果が発表される前のタイミングでないとこのような方向性の記事は書けません。:)
参考にした理論: ウォーズマン理論
Common Lisp が 2 位ですが、Lisp は神が作った神言語なので妥当な結果といえるでしょう。
option という使用すれば絶対有利になる仕様を利用し ていません。Timeout 対策も実装していません。想定以上の大きさの Graph では Timeout するはずです。
もちろんチーム内で複数言語を用いるというのもありです。人数の制限がないのも含めて「なんでもあり」なところがこのコンテストの魅力 です。
2006 年の ICFP コンテストはその内容があまりに濃かったため、参加者の間で「これ、もう主催者側が優勝でいいんじゃね？」と言われていたそうです。