実務でRailsを利用されている方に、最近の開発体験について伺いたいです。
以前Railsを使っていた際、「設定より規約（CoC）」による暗黙的な結合や、静的型付けがない点に強い苦手意識があり、それ以来離れていました。
今のRails環境において、これらの懸念を払拭するような変化は起きているのでしょうか。結局のところ、不満点は「相変わらず」なのか、実務レベルでの率直な感想を教えてください。
特に、Go、Java、TypeScriptなど、明示的な記述や静的型付けを重んじる言語の経験もある方から見て、今のRailsでの開発に「辛さ」を感じることはないでしょうか。
現在、転職活動中でRails採用企業を検討しているのですが、過去の苦手意識から踏み切れずにいます。以前抱いた不満点が現在どう扱われているのか、現場の視点からアドバイスをいただければ幸いです。
追記：
変化の有無に限らず、実務で使っている方の率直な感想を聞きたいです。
結局、日々の開発で「ここが辛い」「他言語より気に入っている」といった肌感覚の意見や、最近だとAIツールの活用で型不在などの弱点が楽になったのか、といった点も伺えれば嬉しいです。
業務でRailsを主に色々な言語やFWをかじってます。
使っていたRubyやRailsのバージョンがいつ頃のものかにもよると思いますが、静的型付けがないというのはどちらかと言うと言語に対する苦手意識ですかね？
僕はその辺りはそう言うものとして受け入れてしまっているので不満はないのですが、
最近はAIに関する実装をしようとするとどうしてもNode.jsやPythonの環境が必要になるので、もどかしく感じています。
一応非公式のgemでActiveAgentがありますがAIの流れが早いのでどこまでついていけるかな、と言う感じです。
まぁ最終リリース2ヶ月前なので期待薄でしょう。
AIから遠いプロダクトだとしても、僕が今から言語を乗り換えるなら、AIの学習比率が高いTSかPythonが主の企業を選ぶと思います。
AIに書かせることが今後増えていく...というかもうそういう時代に差し掛かってきているので、自分よりもAIが得意な言語を選ぶほうが良いんだろうなと考えています。
ご指摘の通り、静的型付けがない点については、言語特性そのものに対する苦手意識が強いのだと思います。
また、AI関連の実装でPythonやNode.jsが必要になる際のもどかしさや、AIの学習比率を言語選定の軸にするというお話は、今の時代ならではの視点として参考になりました。
実務に基づいた率直なご意見をいただき、ありがとうございました。
興味深いですね。
私は逆にRailsをよく触り、静的型付け言語はあまり馴染みがありません。
少しだけGoやTSを書きましたが、型はあってもなくてもまあどっちでもいいかなという所感です。
その観点でいうとそこまで変化は起きてない認識です。
最近はT-Rubyが話題になってましたね。
あれが普及すればスレ主さんは嬉しいんですかね？
私も型がなぜ必要なのか、あると何が嬉しいのかという生の意見は聞いてみたいです！
TypeScriptもそうですが、後付けの型は型のメリットをフルに受けられない割に手間は増えるので好みではないです。
Matzが型を嫌っているのも後付けの型を前提としているように感じます
型を重視する理由は、他の人や自分の返信でも書かれている通り、大規模なリファクタリングや複数人開発において機械的に安全性を担保したいからです。
教えていただいたT-Rubyは初めて知りましたが、これもTypeScriptのように「型があるのが当たり前」というレベルまで圧倒的に普及しない限り、実務上の解決策にはなりにくいと感じています。
Pythonが良い例ですが、型ヒントという仕組みがあっても、コミュニティ全体に広まっていない現状では使い物になりません。言語仕様やエコシステム全体が型前提で動くようにならない限り、ガードレールとしては機能しないからです。
機械的な安全性に確保したいみたいな要望だと、テスト書けばいいのかなと思うんですがそれだとダメなんですかね？意図したデータ型が渡されるかみたいなテストとか。
コードを読むだけでデータ型がわかるから可読性の観点で型を入れたいは納得できる(ただその場合、型ヒントレベルでいいし、もっといえばコメントでもいい)んですが、型がある=安全になりやすいはあまりイメージできなくて。
型に関しては、関数型プログラミングが重きを置いている型によるパターンマッチの文脈も入れて考えるといいかもしれません。
ドメイン世界をモデリングで分解整理した上で、そのモデルが型に紐づくと状態についても型を適用できるので、極論どんなエラーが発生しても雑にtry catchすることなく型でそれぞれに対して固有の処理を当てられます。
しかも関数型が強い言語でこれをやると、pipeの一連の処理の中で発生した例外が、すべてコード上で型として認識できる（読んだらわかる）ようになり、よりドメインモデルがコード化された状態を作り出せます。
型や関数型プログラミングについては、数学という学問がベースにあり、コードを書くことでのエンジニアリングをこれらによって豊かな数学と結びつけることができるとよく言われます。ここにおいても型は必須とされています。
型も関数型プログラミングもパラダイムの一つなので、もちろん銀の弾丸ではありません（どうしてもメモリ効率が悪くなるなどの課題もある）。ただ、型がない言語だとそもそもそのパラダイムを選択できないという点がある、という理解です。
ライブラリを作る側だと、テストを書いたとしても利用者がどんなデータを渡してくるかは制御できないと思います。
データをチェックするコードを書けば良いとは思いますが、コンパイラがあれば不必要なボイラープレートコードが増えるのは簡潔に書ける言語という利点をスポイルするのではないでしょうか。
個人的にはAIのガードレールとして静的型付け言語に優位性を感じてます。
が、結局は慣れな気もします。
Javaだって今どき型推論に任せてvarで書きますしね。
Javaでvarはめったなこと(ジェネリクスで超長くなるとか)がない限り使いませんね
ありがとうございます。「AIのガードレールとして静的型付けに優位性がある」という点には強く同意します。
ただ、Javaのvarの例えについては少し認識が異なります。
Javaのvarはあくまで「静的型付け」の範疇であり、静的に型が決定されています。対してRubyは「動的型付け」であり、静的なチェック段階でのガードレールは存在しません。実行するまで型が確定しない以上、静的な推論に頼るvarとは安全性の担保のされ方が根本的に異なります。
> 認識が異なります
ですね。
varに気持ち悪さを感じてましたが慣れてしまいましたという意味で書きました。
当然プロジェクトルールによって使い分けてますが。
以前にベンチャーで採用していた身としては、良い人材に限って、技術スタックがメインRails だと嫌厭される印象でした。
国内だと裾野が広いので採用には困らないですが、初学者レベルの人も多いですよね。
なので利用者の技術力の平均値は低く映るかなと
あんまりはっきり言う人はいないと思うので、あえて個人的な意見を述べますね。
・Railsはバージョンアップ追随が厳しい。確かにしっかりやっていればいいという話ではありますが、GoやNodejsなどと比べてバージョンが上がることへの対応工数が多すぎる気がします。
・どんどん世界の流れが変わっていきRubyやRails人口は減っています。主要ライブラリの更新や生成AIへの追随などを考えると、今後は厳しいかもしれないと思っています。ユーザーが減るとすなわちライブラリの脆弱性対応の問題が出てきます。
・フロントエンドTypeScriptとの相性が悪すぎる。特にReactなどと相性が最悪です。それが嫌でAPIとして使うとしたら、もうそれはGoとかRustでいいのでは？という気持ちになります。
・型がない不安定さ。脳内メモリが圧倒的に多く、数多くの言語をやってきた上でRailsをやっている人は悩みが少ないと言います。DHHのような人にはF1カーのように爆速で使えるはずです。ただ、採用市場においても、Railsメインの人は真逆の印象です。ディープにテックを追求する人はGoやRustに多い印象です。
・関数型がほぼできない。純粋関数で副作用を減らしつつ、疎結合かつ高凝集にしていくアプローチが難しいです。
・DIをベースにして変更容易性を高めるアプローチもしづらい印象です。データベースのモデルとドメインモデルも密結合になりやすく、ActiveRecordなどがベースにあるため永続化層を切り分けることがしづらい設計になっています。
ここまで述べましたが、業務要求と採用と既存実装の兼ね合いを考えてベターなのであればRailsを使い続けることに問題があるわけではないと思います。
しかし、今からどの技術でやるかと言われれば、Railsは選びません。パフォーマンス要求がそこまでではないのであればTSフルスタックで、パフォーマンスや監査設計などプロダクト要求が厳しいのであればGoでバックエンド + TSフロントエンドを選びますね。
詳細なご意見ありがとうございます。挙げられた懸念点はどれも技術的に納得のいくものばかりで、私も全く同感です。
私自身も、自分が技術選定をする立場であればRailsは選びません。ただ、今回の悩みは「事業内容など他の条件が良い企業がRailsを使っている場合、その技術スタックを妥協してでも入る価値があるか」という点にあります。
そのため、もし現在進行形でRailsを業務で使われているのであれば、こうした構造的な欠点を日々の開発でどう許容しているのか（あるいはやはり隠しきれない辛さがあるのか）という、実務上の肌感覚をぜひ伺いたいと考えていました。
おっしゃる通りですね。Railsへのあふれんばかりの気持ちが暴発してしまいました。すみません。
隠しきれない辛さばかりですね。常にリプレイスの話が出てきては消えていきます。
ただ、生成AIによってリプレイスもやりやすくはなってきたので、ストラングラーフィグパターンによって継続してGoやTSへ変えていくというのは現実味を帯びてきてはいます。
おそらくどこも悩みは同じかと思うので、スレ主さんの志望する企業も少しずつリプレイスしていく、あるいは新規プロダクトは別言語や別FW等でやっていくなど、方針があるかもしれません。
現状Railsであったとしても、ビジネスが儲かっていさえすれば、結局言語やFWは手段なので、よりよりものに変わっていくかとしれません。そう考えると、現状Railsがメインでも、そんなに悲観することもないのかもしれません。あくまで個人的な感想ですが。
ご回答ありがとうございます。「隠しきれない辛さ」というリアルな実感を伺ううちに、昔抱えていたRailsへの苦手意識がだんだん蘇ってきました（笑）。
特にPRのレビューなどで、型さえあれば機械的に解決するような瑣末な確認を、人間が目を皿にしてチェックしなければならないあの不毛感……。そのあたりのコストも踏まえて再検討する必要がありそうです。
志望企業ではRailsを使い続ける方針が固まっており、移行の機運はなさそうなので、改めてその「辛さ」と向き合えるか慎重に考えてみます。
現場のリアルな感覚を思い出させていただき、大変助かりました。ありがとうございました。
静的に明確にメリットを感じてるなら避けた方がいいと思います。
それでも事業に共感するならいいと思いますが、恐らく書いてある通りになるので、後悔するんじゃないなかなと思います。
アドバイスありがとうございます！
確かにおっしゃる通りですね。
そのままストレスになりそうなので、今は「無理にRails環境を選ばなくてもいいかな」って方向に傾いています。
Railsの案件はいつそのプロジェクトに入った時期によって印象が違うんですよね。
初期からもしくは新規で3年以内で参加した人は最初からいるので仕様も把握しやすいし、やりたい事がすぐに出来るので概ね好評です。また新規サービスの場合はドメインが明確では無い中で見切りスタートさせられることが多く、そういう意味でも相性が良いです。(つまりドメイン駆動の前にそもそも誰も明確なドメインの答えが分からない)
ただ5年以上経ったRailsのプロジェクトに参加した人は前提となる業務知識も少ない上に型での安全性も少ないので心理的ストレス(早く結果を出さなきゃという重圧)がどうしても高くなります。また高速に開発してきた、裏を返せばドキュメント類もさほど充実してないのでさらに消耗します。
そういう傾向があるので、Rails自身の問題ではないところで両極端な評価がされやすいフレームワークです。そのため型の重要性を説明されても古参メンバーにはあまり響かないので話は平行線になりやすいです(理解はされるが共感は、されない)。
ここからは個人的な意見ですが、Railsは試行錯誤しやすい強みがあり、GoやRustは答えが明確に決まっている場合に強いので実は型はあんまり重要な論点じゃないと考えてます。
「参加時期によって評価が分かれる」という分析、非常に興味深いです。Railsの二面性が論理的に整理されていて、伺って非常に腑に落ちました。
特に、5年以上経過したプロジェクトでの「ドキュメントも型も不十分な中での消耗」というお話は、実務上の辛さの本質だと感じます。古参と後発で共感が得られないという構造的な視点も、非常に参考になりました。
鋭い視点を共有いただき、ありがとうございました。
端的な話だと、Ruby(Rails)はやめておけ
流行度、言語仕様、コミュニティ、性能、将来性、仕事の質…いろんな面で「PHPの跡継ぎ感」がすごい。
保守開発の仕事があっても、新規事業でRailsを採用することはほぼないと思います。なので、その経験は将来のためになれるかと言うと、あまりそうと思いませんね
