質問: ### 前提・実現したいこと サービス、パッケージの開発言語にRubyを採用する際、Gemを使う事についての意見を聞きたいと思い質問してみます。 直接プログラミングには関係ない話題ですのでteratailとしては非推奨ではありますが、意見がきければ幸いです。 ### 発生している問題・エラーメッセージ Rubyは広く使われている言語の一つで、ライブラリが豊富、技術者が多い、との理由から開発速度はそれなりに速いと思います。 よって、導入までは低コストであると思っています。 一方、運用を考えると以下の理由から他のポピュラーな言語と比較すると高コストではないか、と感じています。 1. Ruby言語そのもののライフサイクルが短い 4, 5年以上運用する場合、RubyのEOLへの対応にコストがかかる。大体4, 5年利用する上でのシステム導入が多いが、その前に言語がEOLを迎え、利用しているフレームワークによっては大幅に変更が必要になる事がある。 2. Gemインストールにインターネット環境が必要 インターネットに接続できない環境へのインストールが非常に手間。Nativeコンパイルされるものもあるのでバイナリでのパッケージングでの動作が不安。商用と全く同じOS環境を構築し、そこでビルドしたものをアーカイブして持ち込んでいる。私が知らないだけで他に方法があるのか? 3. Gemの入手元が度々変更される 過去インストールできていたものが、インストールできなくなる。パッケージングできれば解消できそうだが、それでどの環境に持っていっても動くものなのか疑問。 他にも細かいものはまだまだありますが、大きく感じているのは上記3点です。 Rubyを使って開発・運用している方の問題や解決法、他にもご意見等ありましたらおきかせいただければと思います。
回答: 私は逆にその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を使い続けますけどね。