開発言語にRubyを採用することについて

Question

###前提・実現したいこと
サービス、パッケージの開発言語にRubyを採用する際、Gemを使う事についての意見を聞きたいと思い質問してみます。
直接プログラミングには関係ない話題ですのでteratailとしては非推奨ではありますが、意見がきければ幸いです。

###発生している問題・エラーメッセージ
Rubyは広く使われている言語の一つで、ライブラリが豊富、技術者が多い、との理由から開発速度はそれなりに速いと思います。
よって、導入までは低コストであると思っています。
一方、運用を考えると以下の理由から他のポピュラーな言語と比較すると高コストではないか、と感じています。

1. Ruby言語そのもののライフサイクルが短い

4, 5年以上運用する場合、RubyのEOLへの対応にコストがかかる。大体4, 5年利用する上でのシステム導入が多いが、その前に言語がEOLを迎え、利用しているフレームワークによっては大幅に変更が必要になる事がある。
0. Gemインストールにインターネット環境が必要
インターネットに接続できない環境へのインストールが非常に手間。Nativeコンパイルされるものもあるのでバイナリでのパッケージングでの動作が不安。商用と全く同じOS環境を構築し、そこでビルドしたものをアーカイブして持ち込んでいる。私が知らないだけで他に方法があるのか？
0. Gemの入手元が度々変更される
過去インストールできていたものが、インストールできなくなる。パッケージングできれば解消できそうだが、それでどの環境に持っていっても動くものなのか疑問。

他にも細かいものはまだまだありますが、大きく感じているのは上記3点です。
Rubyを使って開発・運用している方の問題や解決法、他にもご意見等ありましたらおきかせいただければと思います。

Answer 1

私は逆にその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年以上前の規格で書くしかありません。

1. Gemインストールにインターネット環境が必要

pipもcomposerもnpmもmavenもインターネット環境が前提です。どうしてもインターネットに繋げられない場合を想定して、gemもそうですが、これらはパッケージ単体のダウンロードしてインストールすることや、レポジトリサーバのクローン化ができるように作られています。とくにgemだから問題というわけでも、gemだから有利というわけでもありません。

1. 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を使い続けますけどね。

Answer 2

それが問題になるかは、Rubyをどのような環境で使うかにもよります。

Rubyを使った大規模システムで多くあるRuby on Railsでは、1と2はあまり問題となりません。

1: Rubyの進化と同レベル、あるいはそれ以上の速度でRails本体も進化しているため、そのアップデートについていけないGemは、自然とエコシステムから排除されていきます。また、Ruby 1.9以降は、言語への破壊的変更はあまり加わらなくなっています。
2: RailsはWebアプリケーションフレームワークであるという性質上、通常インターネット環境への構築となるので、あまり問題とされることはありません。閉じた環境使いたければ、「自前でGemサーバを立てる」という選択肢も存在します。

3については、公開されるGemのほとんどがRubyGemsに存在するので、あまり意識しなくて済むと思います。