開発言語にRubyを採用することについて
解決済
回答 2
投稿
- 評価
- クリップ 1
- VIEW 1,761
前提・実現したいこと
サービス、パッケージの開発言語にRubyを採用する際、Gemを使う事についての意見を聞きたいと思い質問してみます。
直接プログラミングには関係ない話題ですのでteratailとしては非推奨ではありますが、意見がきければ幸いです。
発生している問題・エラーメッセージ
Rubyは広く使われている言語の一つで、ライブラリが豊富、技術者が多い、との理由から開発速度はそれなりに速いと思います。
よって、導入までは低コストであると思っています。
一方、運用を考えると以下の理由から他のポピュラーな言語と比較すると高コストではないか、と感じています。
- Ruby言語そのもののライフサイクルが短い
4, 5年以上運用する場合、RubyのEOLへの対応にコストがかかる。大体4, 5年利用する上でのシステム導入が多いが、その前に言語がEOLを迎え、利用しているフレームワークによっては大幅に変更が必要になる事がある。 - Gemインストールにインターネット環境が必要
インターネットに接続できない環境へのインストールが非常に手間。Nativeコンパイルされるものもあるのでバイナリでのパッケージングでの動作が不安。商用と全く同じOS環境を構築し、そこでビルドしたものをアーカイブして持ち込んでいる。私が知らないだけで他に方法があるのか？ - Gemの入手元が度々変更される
過去インストールできていたものが、インストールできなくなる。パッケージングできれば解消できそうだが、それでどの環境に持っていっても動くものなのか疑問。
他にも細かいものはまだまだありますが、大きく感じているのは上記3点です。
Rubyを使って開発・運用している方の問題や解決法、他にもご意見等ありましたらおきかせいただければと思います。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+10
私は逆にその3点にあたらないメジャーな言語を知りません。どの言語でも言えることではないでしょうか？
1. Ruby言語そのもののライフサイクルが短い
Rubyの3年という期間は一般的かと思われます。Python3が5年であるぐらいで、JavaもPHPも3年です。JavaScriptは実装によりますが、例えばNode.jsのLTS対象バージョンが3年です。.NET Frameworkのサポート期間はやや複雑ですが、むしろ、4系のようにOSによっては最新でないと入らないということに注意すべきです。特別Rubyが短いとは思えません。
ライフサイクルというものが無い物を考えると、仕様に対して複数の実装があるような、C/C++ぐらいになりますが、今度はコンパイラのライフサイクルを考えなくてはいけません。 Visual Studio等はUpdate(OSでいうServicePack相当)を適用しないと1年間しかサポート期間がありません。そして、最新OSに対応するには、やはりメジャーバージョンを上げなければならないという自体に陥ります。
ライフサイクルを気にされるのであれば、本当に枯れた言語か、C/C++を10年以上前の規格で書くしかありません。
2. Gemインストールにインターネット環境が必要
pipもcomposerもnpmもmavenもインターネット環境が前提です。どうしてもインターネットに繋げられない場合を想定して、gemもそうですが、これらはパッケージ単体のダウンロードしてインストールすることや、レポジトリサーバのクローン化ができるように作られています。とくにgemだから問題というわけでも、gemだから有利というわけでもありません。
3. Gemの入手元が度々変更される
gemはまだまともな方です。特殊な目的(たとえばRails Assetsとか)以外はRubygems.orgに集約されており、ツールもgemだけです。これと同じぐらい統一されているのはpipとcpanぐらいです。PHPにはかつてPEARなるものがありましたが、今はComposerと言われています。JavaなんてMavenとかGradleとか色々とあってよくわかりません。Node.jsなんかでもnpmの他にbowerと言うのがあります(一応、役目が違うのですが)。
C/C++なんてさらに酷いです。統合されたライブラリのレポジトリなんてありません。opensslのライブラリを使いたいとなったとき、RHEL系ならyumでDebian系ならapt-getでopenssl-devel落とすとか、MacならHomebrew使うとか、Windowsなら本家サイトから直接落とすとか、そんな世界です。
運用を考えると、現代において、定期的な更新を前提にできない言語などないと思います。ただし、メジャーバージョンアップでも無い限り、どの言語でも互換性はなるべく保つようにしており、マイナーバージョンアップをしたからといって問題が発生することは希です(どれぐらいかは言語によりますが、保守的と言われているJavaでさえ7->8(内部的には1.7から1.8)になるときに一部のアプリは問題が起きましたし、互換性を切り捨てたがる傾向が高いPHPでもアプリによっては7.0に移行しても問題なかったこともあります)。
Rubyにするか、別の言語にするかという選択をするときに、挙げられた3点に観点を置く必要は全くないと思います。もっと別の問題、重くて遅いとか、スケールし難いとか、グローバルインタプリンタロックのせいでマルチコアの意味が無いとか、動的型付けとか、そういった所を指摘して、Rubyを駆逐すべきです。といっても、そんなことが霞んで見えるほどの利点がRubyにはあると思っているので、私はRubyを使い続けますけどね。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+4
それが問題になるかは、Rubyをどのような環境で使うかにもよります。
Rubyを使った大規模システムで多くあるRuby on Railsでは、1と2はあまり問題となりません。
1: Rubyの進化と同レベル、あるいはそれ以上の速度でRails本体も進化しているため、そのアップデートについていけないGemは、自然とエコシステムから排除されていきます。また、Ruby 1.9以降は、言語への破壊的変更はあまり加わらなくなっています。
2: RailsはWebアプリケーションフレームワークであるという性質上、通常インターネット環境への構築となるので、あまり問題とされることはありません。閉じた環境使いたければ、「自前でGemサーバを立てる」という選択肢も存在します。
3については、公開されるGemのほとんどがRubyGemsに存在するので、あまり意識しなくて済むと思います。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう！
- ただいまの回答率 88.37%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる