12

Mirah言語は、JRuby、Groovy、Scalaに対して何を提供しますか？

4

5 に答える 5

12

独自のライブラリが付属しているフル機能の言語とは異なり、MirrahはJavaライブラリとは異なる「フロントエンド」のようなものです。

Mirrahコードは、それ自体の環境に依存しません（コンパイル時のMirrahコンパイラを除く）。

これが主な利点です。Javaの構文が異なります。

于 2010-11-23T09:21:43.963 に答える
9

Mirahの作成者へのインタビューによると、 Mirah（ジャワ語で「ルビー」を意味する）のポイントは、Rubyの高性能バリアントを作成することです。快適に操作できるRubyのような構文でありながら、JavaおよびJVMのセマンティクスに十分に近いため、JVM上の大きなランタイムレイヤーのオーバーヘッドなしで実行できます。

選択の見積もり：

同様の言語に対するMirahの利点の多くは、非常に軽量であることにあります。Groovy、Scala、JRuby、Clojure、またはJythonでは、「Hello、world」と書いた瞬間に、ランタイムライブラリに縛られました。Mirahでは、「Hello、world」は、JRubyと同じように簡潔ですが、依存関係を強めないという追加の利点があります。ソースファイルが入り、クラスファイルが出て、それだけです。JVMには新しい依存関係のない言語が必要だと思います。Mirahはそれを実現するための私の試みです。

JRubyのパフォーマンスは他のRubyインタープリターに匹敵するか、それを上回っていますが、最速のJRubyコードは、純粋なJavaパフォーマンスよりも桁違いに遅れています。1.6リリースでJRubyのパフォーマンスが向上することを期待できますが、Mirahはパフォーマンスの上限を突破し、Javaコードと同等の実行速度を求めるプログラマーにオプションを提供する試みです。

于 2010-11-23T02:15:45.947 に答える
8

vs. Groovy

  • 既存のRuby/JRubyプログラマーに馴染みのある構文
  • 静的に型付けされた

vs.JRuby

  • 静的に型付けされた

vs. Scala

  • 既存のRuby/JRubyプログラマーに馴染みのある構文

主な利点は、静的型付け（JVMでのパフォーマンスが高速で、既存のJavaライブラリとの相互運用がはるかに簡単）と使い慣れた構文（Rubyの場合）です。

依存関係が考慮事項である場合（たとえば、Androidアプリの開発）、これで言語の選択をガイドすることはできません。Proguardのようなツールを使用すると、競技場が平準化されます。

Rubyから来ている場合は、Mirahが適しています。ErlangまたはHaskellから来ている場合は、Scalaが必要になります。あなたがLISPerなら、Clojureを見てみたいと思うでしょう。

あなたの唯一の以前の経験がJavaであるなら、あなたに恥をかかせてください！-そしておそらくScalaに行くべきです-それはJavaに明らかな相続人として急速に評判を得ており、ツールのサポートは現在より強力であり、同じ移行を行った他の人々の大規模なコミュニティに参加するので、たくさんのブログがあります/チュートリアルはすでに利用可能です。

とGroovy？Groovyは、今日ではほとんど正しい選択ではありません...

于 2010-11-27T15:18:07.823 に答える
5

私はGoogleAppEngineで毎日Mirahを使用しています。

Mirahを使用する理由は次のとおりです。

  • ランタイムライブラリなし
  • とても素敵な構文
  • Javaと同じくらい速い

Javaを内部に持つことも非常に役立ちます。

  • 固体型システム
  • 十分に文書化されている
  • 一般的な問題の既知の解決策

私はいくつかのGroovy、たくさんのJRubyを実行しましたが、Scalaは実行しませんでした。これらを知っているなら、ミラを試してみてください。そうでなければ、JRubyで行きます。

于 2010-12-14T11:35:14.050 に答える
-2

Mirahは、Javaのもう1つのルビーっぽい構文です。私見は全然良くない。ジェネリックについては何も知らず、ツールも貧弱です。ceylon、xtend、scala、kotlinなどを試してみてください。Mirahは
Javaクラスにコンパイルされます（ソースではなくなりました）。XtendはJavaソースにコンパイルされるため、内部で何が行われるかを簡単に見つけることができます。Ceylonとscalaには独自のstdlibがあります（それでも、javaの相互運用機能はどちらもほぼ完璧です）。kotlinについてはよくわかりません。KotlinはJetBrainsの子であるため、IDEAに関連付けられています。
JRuby私も好きではありません。Java相互運用機能のバグが多すぎます。また、再発明されたホイールが多すぎます。つまり、エンコーディング（Java文字列と正規表現を使用せず、生のバイトバッファの上にカスタム文字列を使用します）、IO、例外処理、スレッドなどを意味します。
jrubyの唯一の利点は、それがルビーであるということです。多くのルビーコードはそのまま動作します。
Groovy OTOHは車輪の再発明を行わず、十分にテストされたJavaライブラリを使用し、構文糖衣を追加するだけです。また、groovy-java相互運用機能は素晴らしいです。ジェネリックスにすることができます。スレッド、例外、文字列、コレクション-Javaの場合と同様に、単なるJavaクラスです。

于 2015-08-04T11:00:37.090 に答える