「Rubyは真剣なプログラミング言語ではない」という見解への応答

 (robbyonrails.com)
6 ポイント 投稿者 GN⁺ 2025-12-03 | 2件のコメント | WhatsAppで共有
  • Ruby を『真剣な言語』ではないとみなす見方に対し、Rubyはプログラミングを人間的で楽しくする言語である
  • 初期の Ruby コミュニティは小規模で陽気な反乱のように始まり、複雑さより明瞭さとアクセスのしやすさを重視した
  • Shopify、Doximity、GitHubなどの実際の大規模サービスが Ruby で運用された事例を示し、実績を立証
  • Ruby の核心はコードを書く人の体験と持続可能な開発文化にあり、これは単なる懐かしさではなく敬意と感謝の姿勢である
  • これからのソフトウェア開発でも可読性、保守性、楽しさがさらに重要になり、Ruby の価値は依然として意味のある基準点として残るだろう

Rubyと「真剣さ」の概念

  • 「Ruby は真剣な言語か？」という問いは、プログラミングがどのような感情を持つべきかについての認識差を示している
    • 一部の人は使うのが楽しいツールを『真剣ではない』と捉えるが、Ruby はその定義には同意しない
  • Ruby の初期の時代は小規模コミュニティと冗談めいたエネルギーで満ちており、プログラミングが威圧的である必要はないという可能性を示した
  • 当時の批判者は主に Java アーキテクトや伝統的なエンタープライズ開発者だったが、Ruby コミュニティは気にすることなく実際の製品開発に集中した

アクセスしやすさと生産性を重視する言語

  • Ruby はシンプルさではなく**アクセスしやすさ（approachability）**を追求し、初心者や小規模チームが素早く成長できるよう支援してきた
    • 複雑な理論よりモメンタムと明瞭さを重視し、不安感なく開発を継続できるようにする
  • この特性のため、ブートキャンプとスタートアップが Ruby を採用し、これは速度と創造性を重視する環境に適していた
  • Twitter の例のように、Ruby は企業が成長するのに十分貢献し、その後他の技術に移行したことは成功の結果として示されている

実務における信頼性と実例

  • 数十年にわたるコンサルティング経験では、Ruby を選んだことで失敗したチームはなかった。むしろ**複雑性・優柔不断さ・過度な『真剣さ』**が失敗要因だった
  • Ruby は開発者が中核業務に集中できるよう邪魔をしない言語と評価される
  • Shopify、Doximity、GitHubなど主要サービスが Ruby で運用されており、これは**感情ではなく実質的な証拠（proof）**として提示されている

Ruby文化と人間中心の開発哲学

  • Ruby はコードを書く感覚と読む体験を重視する人を惹きつけ、これは懐古趣味ではなく持続可能なソフトウェア製造のあり方だ
  • Ruby コミュニティは表現力と人間中心性を重視し、プログラミングは人のための行為であることを想起させる
  • 別の言語を好む人々との違いは嗜好の問題であり、Ruby はすべての人を説得しようとはしない

未来のプログラミングと Ruby の役割

  • 将来のソフトウェア開発は単一の言語・パラダイム・イデオロギーに支配されず、混成で柔軟な形で進展する
  • AI がコードを書く時代には、可読性と保守性がさらに重要になり、バーンアウトが日常化した環境では楽しさが主要価値として浮上する
  • Ruby の価値である明瞭さ・共感・人間中心性は、過去の遺産ではなく未来の基準点となるだろう

「真剣さ」より共鳴するコード

  • 社会とビジネスは『真剣さ』より共鳴（resonance） と明確さ、人間性を報いる
    • 真剣な候補者・音楽家・芸術家・スタートアップ・エンジニアが常に成功するわけではない
  • Ruby はチームのためのコード、人のためのプログラミングを目指し、このアプローチが産業をより人間的に維持する
  • 好奇心が豊かで陽気な開発者たちが将来の技術エコシステムで重要な役割を果たすだろうが、Ruby はその流れの中でなお意味のある言語として残る

結論

  • 「Ruby は真剣な言語か？」という問いは誤った問いだ
  • より適切な問いは「Ruby が次世代のソフトウェアになお 意義ある貢献をし続けられるか」であり、答えはそうである
  • それが『真剣でない』という意味だとしても、それこそが Ruby が議論に含まれるべき理由

関連記事

2件のコメント

 
GN⁺ 2025-12-03
Hacker Newsの意見
  • 私はRubyを嫌う理由としてよく持ち出される Twitterの事例 は不適切だと思う
    たとえRubyが原因だったとしても、その選択のおかげで事業は始まり、最初の成功を収めることができた
    Twitterの問題は言語のせいではなく、大規模ファンアウト（有名人のツイート → 数百万人のフォロワー） という特殊な状況によるものだった
    また、「最初からスケーラブルな」言語を使ったのに失敗したスタートアップについては誰も語らない — 典型的な 生存者バイアス だ
    Wiredの当該筆者ページを見ると、論争を引き起こす書き方を戦略的にしているように思える
    私は引き続き、Rubyで役に立つソフトウェアを作っている静かな多数派の一人に戻る
    • 「Rubyでなければ、もっと良い言語で同じ事業を始めて問題を避けられたはずだ」という反論もある
    • かなり時間が経っており、今のRubyは当時とは完全に違う
  • 元記事では、著者がRubyを嫌った理由を具体的に説明していなかった
    ただ過去の限界を並べただけで、実際には自分が担当したコードベースの問題だった可能性が高い
    最初の記事の核心は「2025年にRubyを新たに選ぶ理由はない」だったので、そこが議論の中心であるべきだった
    今回の記事は感情に訴える方向へ進み、皮肉にもRubyは感性で動くという前回の主張を自ら証明した形になっている
    Elixirを好む人の多くはRubyを『真面目ではない』と見るが、ElixirもまたRubyの強い影響を受けている
    • 私はElixirを何年も使ってきて、初期にはRubyも使っていた
      多くの人は、Rubyの親しみやすい文法と 関数型の基盤 を組み合わせたElixirに惹かれる
      特に BEAMランタイム のおかげで運用特性がまったく異なる
      BEAMは単なる言語ではなく、システムのためのシステム という感覚がある — あらゆるものを追跡、再起動、観測できる
    • Rubyに着想を得たコンパイル言語 Crystal に触れられていないのは意外だった
      ただしCrystalはElixirより 人気不足 の問題がさらに深刻だ
      TIOBEランキング基準では、Elixirは上位50位以内に入っている
    • macOSにはRubyが標準でインストールされているので、別途インストールせずにスクリプトを書くならPerl、Bash、AppleScript、あるいはRubyを使うことになる
    • どちらの記事にも中身がないと感じた
      最初の記事はStackOverflowの統計とTwitterの話だけで、二つ目の記事はただ郷愁と美学の話をしているだけだ
      LLMではなく人間が書いた文章だということが、かえってもっと憂鬱だ
  • 私が好きな言語を判断する基準は、「この言語でコードを書くのが好きか」ではなく
    「運用中のシステムがこの言語で書かれていてほしいか」だ
    この二つの問いに同じ答えを出す人は多くない
    • コードを書くことと ビジネス運営 は別問題だ
      私はOcamlが好きだが、エコシステムが弱く人材確保も難しいので、運用システムには使いたくない
    • 言語の時代性やチームの コーディング文化 によっても変わる
      型注釈と検査ツールがあるPythonは保守しやすいが、そうでないならドキュメント文化が必須だ
    • システムを単に維持するのか、継続的に発展させるのかで答えは変わる
      前者ならCOBOL、後者なら別の選択肢が面白くなる
    • 自分で作ったシステムならどの言語でも構わないが、そうでないなら他の人に引き継ぎたい
    • Forthでコーディングするのは楽しいが、それで生計を立てたいとは思わない
  • 私はRubyが本当に好きだ
    感性のせいではなく、単純に 書く楽しさ が大きい — とくにJavaScriptよりずっと楽しい
    Rubyを攻撃する記事は妙に感じる
    Github、Twitter、Coinbase、Shopifyのような成功事例があり、スケーラビリティの問題は成功の副産物 にすぎない
    Rubyは優れたツールであり、次のプロジェクトに適しているかは自分で判断してみることを勧める
  • 元記事も、それへの反論も定義が曖昧だ
    「Rubyは永遠にスケールしない」という主張なら、たいていの言語も同じだ
    結局のところ両方の記事は「Rubyは永遠には動かない」という点では一致している
    興味深いのは、元記事がRubyのStackOverflow順位を18位だとけなしておきながら、
    実際には2024年時点で14位で、称賛していたScalaはそこから9段階下だという点だ
    StackOverflow 2024調査リンク
    • 「Rubyは永遠には動かない」という言い方には同意しない
      私が10年前に書いたRubyコード、たとえば WebKitのofflineasmコンパイラ は今でも問題なく動いている
    • JavaをからかいながらScalaを褒めるのもおかしい — Scalaの強みの多くはJavaのおかげだ
  • 多くの人はRubyを「人間のための言語」と表現するが、実際にはすべての言語は人間のために作られている
    Rubyは文法がきれいで表現力も高いが、動的型付け と マジック（暗黙的な動作） のせいで使いづらく感じる
    私には合わないが、ある人たちには完璧に合う言語だ
    • Railsが「魔法のようなオブジェクト」という概念を大衆化した
      ファンはこれを驚くほど楽しいと感じるが、人によっては怖く感じる
      PythonのFlaskも同様に context local proxy を使う
      一方でZigやGoは「すべては明示的であるべきだ」という反発から登場し、Rustはその中間あたりに位置する
      Rustは厳格だが、DSLのような表現力 をきれいに提供する
  • 私は10年前にRubyから Elixirへ移行 した
    アルゴリズム性能は10倍向上し、イミュータビリティ のおかげでバグが減り、並行性サポート も素晴らしかった
    パターンマッチングとガードのおかげでボイラープレートが消え、GILがなく、プロセスごとのGCがある
    学習曲線は多少あるが、Elixirは長期保守や負荷の面ではるかによくスケールする
    Rubyコミュニティは今でも素晴らしい
    ただ、Elixirが ネイティブ実行ファイル にコンパイルされたり、ブラウザで動いたりするといいのにと思う
    • 私も似た経験をした
      いまだに「Rubyで考える」ものの、個人プロジェクトはElixir/Erlangでやっている
      会社ではGolangとPythonを使っているが、楽しくはない
      個人用スクリプトはいまもRubyで書いている
  • この記事は、まるで誰かが自分の言語を 擁護 しているように見える
    人気や慣れよりも、言語の 特性がコード品質に与える影響 を冷静に分析する議論のほうが価値があると思う
    そうした議論はしばしば モナドやアプリカティブ のような概念のせいで人を遠ざけるが、それこそが本当に有益な議論だ
    • コード品質、生産性、安定性は客観的に測るのが難しく、結局は 経験の違い に帰着する
    • コード品質だけでなく 単純さ、可読性、表現速度 も重要だ
      型や制約が多いほど品質は上がるが、開発速度と柔軟性は下がる
    • このテーマに関心があるなら Eloquent Ruby のような本は参考になる
    • 「大規模システム構築にどの言語機能が有利か」を分析した論文や記事があるなら、ぜひ読んでみたい
  • 私はRubyファンではないが、Wiredの元記事は 純度100%のクリック誘導型怒りコンテンツ だった
    こういう記事はHNで言語戦争を引き起こす 毒 のような存在だ
    真面目に受け取る必要はない
  • 私はRubyの 表現力 と完全なオブジェクト指向性、読みやすい文法が好きだった
    だが今は Kotlin のほうが自分に合っている — 静的型付けと文法のエルゴノミクスのおかげだ
    Rubyはプロジェクトが大きくなるほど不安だが、それでも小さな作業には愛らしい言語だ
    • 以前、Rubyでセッション関連の変数を誤って使い、ユーザーアカウントが混線する事故を見たことがある
      言語のせいではないかもしれないが、安全装置の少ない言語 ほど危険なコードが集まりやすい傾向がある
    • Rubyは完全なオブジェクト指向だと言われるが、たとえば if.class を実行してみると完全にそうではない
      それでも大衆言語の中では最もそれに近い水準だ