Locked History Actions

Diff for "scala/ruby"

Differences between revisions 11 and 12
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
しかし、私は気が付いてしまいました。Ruby の動的型付けは多くのエラーを引きおこすことに。そして、安心してデプロイするためには 95% ものテストカバレッジを達成しなければいけないことに。95% のテストカバレッジを得ることの代償として、私の書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふくれあがってしまいました。その上、Rails(Ruby On Rails) では動的なコードの変更が可能なため、開発・テスト・デプロイ中にトラブルが続出するようになりました。高いテストカバレッジを確保しているにも関わらずです。これらの問題にくわえて、MRI(Matz Ruby Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も安定していません。それなのに開発コミュニティはそのことに見向きもしません。私は他の言語も見てみようと思うようになりました。そんな時に Scala と出会いました。Scala を使ってみて、これこそが私が求めていた言語だと思いました。 私は気が付いてしまいました。Ruby の動的型付けは多くのエラーを引きおこすことに。そして、安心してデプロイするためには 95% ものテストカバレッジを達成しなければいけないことに。95% のテストカバレッジを得ることの代償として、私の書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふくれあがってしまいました。その上、Rails(Ruby On Rails) では動的なコードの変更が可能なため、開発・テスト・デプロイ中にトラブルが続出するようになりました。高いテストカバレッジを確保しているにも関わらずです。これらの問題にくわえて、MRI(Matz Ruby Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も安定していません。それなのに開発コミュニティはそのことに見向きもしません。私は他の言語も見てみようと思うようになりました。そんな時に Scala と出会いました。Scala を使ってみて、これこそが私が求めていた言語だと思いました。

Ruby対Scala

Javaの欠陥、Rubyの欠陥を埋めるものとしてScalaが選択されつつある。 ここでは特に、なぜRubyではだめなのか、他の方の言を参照している。

私は気が付いてしまいました。Ruby の動的型付けは多くのエラーを引きおこすことに。そして、安心してデプロイするためには 95% ものテストカバレッジを達成しなければいけないことに。95% のテストカバレッジを得ることの代償として、私の書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふくれあがってしまいました。その上、Rails(Ruby On Rails) では動的なコードの変更が可能なため、開発・テスト・デプロイ中にトラブルが続出するようになりました。高いテストカバレッジを確保しているにも関わらずです。これらの問題にくわえて、MRI(Matz Ruby Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も安定していません。それなのに開発コミュニティはそのことに見向きもしません。私は他の言語も見てみようと思うようになりました。そんな時に Scala と出会いました。Scala を使ってみて、これこそが私が求めていた言語だと思いました。

「Scalaプログラミング入門」を読みはじめて、いきなり大きく頷いてしまった。

  • * "コーディング時間の半分をテスト作成に費やさなければならなかった"(p.3)
  • * "Rails(Ruby On Rails)によって得られた生産性の向上は、テスト作成の作業に失われてしまいました"(p.3)

まさにここ数年私が抱いてた漠然としたストレスの正体が、的確に文章となっていたからだ。そしてほどなく、「あ、この機能がRubyに欲しかった!」という驚きと共に Scala が本物であることに気付いた。さらに読み続けていくと、その驚きの回数は減るどころか、最後にはため息へと変わっていった。

動的型付の言語は、多めの人数で開発することに向かない面があります。

言語が「動的」なので、実行するまでコードに問題がないか分かりません。多めの人数で開発するときは、優秀ではない人も混じっていると思いますが、その人が他の人のコードに影響を与えるおかしなコードを書いたとしても、あくまで「実行時」にしか見つけることができないことになります。これはたくさん人数で開発するときに問題となってきます。

この点が、JavaやC#といった「静的型付け」の言語が持っている「メリット」です。

(Twitter開発者のインタビュー)

It began its life as a Ruby on Rails application, and still uses Ruby on Rails to deliver most user-facing web pages. But about a year ago they started replacing some of the back-end Ruby services with applications running on the JVM and written in Scala.

twitterはRuby on Railsアプリとして開始され、現在も(少なくとも2009年時点)ウェブページの生成に使われているが、一年前に彼らはいくつかのrubyによるバックエンドサービスのScalaへの置き換えを開始した。

Alex Payne(Twitter技術者):

Over time we found that although Rails works great for doing front-end web development, for doing heavy weight back-end processing, Rails had some performance limitations at runtime. And I think that—and this is more my personal opinion—the Ruby language lacks some things that contribute to reliable, high performance code, which is something we’re very interested in as we’re growing as a business. We want the code we write to be correct and maintainable. We want to keep our costs down—all the things most businesses want out of their stack. So that’s why we started looking at Scala.

Rails(Ruby On Rails)はウェブのフロントエンド開発や重いバックエンド処理に適切であったが、Railsはパフォーマンス制限のあることが徐々に分かってきた。僕は(僕だけの意見じゃないけど)Ruby言語は信頼性に欠けるし、高パフォーマンスコードの記述ができないと思う。それらはビジネスを成長させるのに必要なものだった。正しくてメンテナンス可能なコードが必要だったのだ。僕らはコストを下げる必要があった。Scalaを始めたのはそういう理由だ。

現在Rubyを始めとして生産性が高く,開発が楽しい言語がメジャーになりつつあります。しかし,それらは動的型ということもあり,ある程度の人数で開発するような大きめのプロジェクトには向いていません。

そのようなプロジェクトでは,現在JavaやC#ぐらいしか選択肢がないのですが,Scalaがメジャーになれば,この領域のアプリケーション開発プラットフォームの最右翼になる可能性があります。