Antwort auf „Ruby ist keine ernsthafte Programmiersprache“

 (robbyonrails.com)
6 Punkte von GN⁺ 2025-12-03 | 2 Kommentare | Auf WhatsApp teilen
  • Obwohl Ruby manchmal als „nicht-seriöse Sprache“ gilt, ist Ruby eine Sprache, die Programmieren menschlicher und freudvoller macht
  • Die frühe Ruby-Community begann wie eine kleine, heitere Rebellion, mit Fokus auf Klarheit und Zugänglichkeit statt auf Komplexität
  • Durch reale Beispiele wie Shopify, Doximity, GitHub und weitere großskalige Services, die mit Ruby betrieben werden, wurde praktischer Erfolg nachgewiesen
  • Der Kern von Ruby liegt in der Erfahrung der Menschen beim Schreiben von Code und in einer nachhaltigen Entwicklungskultur; das ist keine bloße Nostalgie, sondern eine Haltung von Dankbarkeit und Respekt
  • Auch in der Zukunft der Softwareentwicklung werden Lesbarkeit, Wartbarkeit und Freude wichtiger werden, und Rubys Wert bleibt ein relevanter Referenzpunkt

Ruby und das Konzept der „Ernsthaftigkeit“

  • Die Frage „Ist Ruby eine ernsthafte Sprache?“ zeigt einen Unterschied in der Sichtweise, welche Emotionen Programmieren haben sollte
    • Manche halten ein Werkzeug, das Spaß macht, für „nicht ernst“, doch Ruby lehnt diese Definition ab
  • Die Anfangszeit von Ruby war voller kleiner Community und spielerischer Energie und zeigte, dass Programmieren nicht einschüchternd sein muss
  • Die Kritiker damals waren vor allem Java-Architekten oder klassische Enterprise-Entwickler; die Ruby-Community kümmerte sich nicht darum und konzentrierte sich auf echte Produktentwicklung

Eine Sprache, die auf Zugänglichkeit und Produktivität setzt

  • Ruby strebt nicht nur nach Einfachheit, sondern nach Zugänglichkeit (Approachability), damit Einsteiger und kleine Teams schnell wachsen können
    • Sie setzt mehr auf Dynamik und Klarheit statt auf komplexe Theorien und macht es möglich, ohne Unsicherheit kontinuierlich zu entwickeln
  • Durch diese Eigenschaften entschieden sich Bootcamps und Startups für Ruby, was in Umgebungen passte, die Tempo und Kreativität priorisieren
  • Wie im Fall von Twitter gezeigt, hat Ruby Unternehmen beim Wachstum ausreichend unterstützt; der spätere Wechsel auf andere Technologien wird als Ergebnis des Erfolgs dargestellt

Vertrauen in der Praxis und reale Fallbeispiele

  • In jahrzehntelanger Beratungserfahrung gab es keine Teams, die mit der Wahl von Ruby gescheitert sind; stattdessen waren Komplexität, Zögern und übermäßige „Ernsthaftigkeit“ die Hauptgründe für Fehlschläge
  • Ruby gilt als Sprache, die Entwickler nicht behindert und sie auf die Kernarbeit konzentrieren lässt
  • Shopify, Doximity, GitHub und weitere wichtige Services wurden mit Ruby betrieben und dienen als praktischer Beweis statt bloßer Gefühle

Ruby-Kultur und menschenzentrierte Entwicklungsethik

  • Ruby zieht Menschen an, die das Gefühl beim Schreiben von Code und die Leseerfahrung betonen; das ist keine nostalgische Haltung, sondern nachhaltige Softwareherstellung
  • Die Ruby-Community betont Ausdruckskraft und Menschenzentriertheit und erinnert daran, dass Programmieren eine Handlung für Menschen ist
  • Der Unterschied zu Menschen, die andere Sprachen bevorzugen, ist eine Frage des Geschmacks; Ruby versucht nicht, alle zu überzeugen

Die Zukunft der Programmierung und Rubys Rolle

  • Die Softwareentwicklung der Zukunft wird nicht von einer einzigen Sprache, einem Paradigma oder einer Ideologie dominiert, sondern in einer hybriden und flexiblen Form verlaufen
  • In der Ära, in der KI Code schreibt, werden Lesbarkeit und Wartbarkeit noch bedeutender, und in einer Welt, in denen Burnout alltäglich geworden ist, wird Freude zu einem zentralen Wert
  • Rubys Werte Klarheit, Empathie und Menschenzentriertheit sind kein Erbe aus der Vergangenheit, sondern werden zukünftige Maßstäbe bleiben

Resonanz statt Ernsthaftigkeit

  • Gesellschaft und Wirtschaft honorieren Resonanz (resonance), Klarheit und Menschlichkeit stärker als bloße Ernsthaftigkeit
    • Ernste Kandidaten, Musiker, Künstler, Startups oder Ingenieure sind nicht immer erfolgreich
  • Ruby steht für Code für Teams und Programmierung für Menschen und hält die Industrie dadurch menschlicher
  • Neugierige und heitere Entwickler werden in der künftigen Technologieökosysteme eine wichtige Rolle spielen, und Ruby bleibt dort weiterhin eine sinnvolle Sprache

Schlussfolgerung

  • Die Frage „Ist Ruby eine ernsthafte Sprache?“ ist falsch gestellt
  • Die passendere Frage ist, ob Ruby der nächsten Generation von Software noch einen sinnvollen Beitrag leisten kann, und die Antwort ist ja
  • Wenn das bedeutet, dass es „nicht ernsthaft“ ist, dann ist genau das der Grund, warum Ruby in der Debatte dabei sein sollte

Verwandte Beiträge

2 Kommentare

 
GN⁺ 2025-12-03
Hacker-News-Kommentare
  • Ich halte das oft als Grund für Ruby-Hass angeführte Twitter-Beispiel für unpassend
    Selbst wenn Ruby die Ursache gewesen wäre, konnte das Unternehmen dank dieser Wahl überhaupt starten und erste Erfolge erzielen
    Twitters Problem lag nicht an der Sprache, sondern an der besonderen Situation eines massiven Fan-out (Celebrity-Tweet → Millionen von Followern)
    Außerdem spricht niemand über Startups, die von Anfang an eine „skalierbare“ Sprache gewählt haben und trotzdem gescheitert sind — ein typischer Survivorship Bias
    Wenn man sich die Autorenseite bei Wired ansieht, wirkt es so, als schreibe der Autor strategisch provokante Texte
    Ich gehöre weiterhin zur stillen Mehrheit, die mit Ruby nützliche Software baut
    • Es gibt auch den Einwand: „Wenn es nicht Ruby gewesen wäre, hätte man dasselbe Geschäft mit einer besseren Sprache starten und die Probleme vermeiden können“
    • Es ist viel Zeit vergangen, und das heutige Ruby ist völlig anders als damals
  • Im Originalartikel hat der Autor nicht konkret erklärt, warum er Ruby hasst
    Er hat nur frühere Schwächen aufgezählt, und in Wirklichkeit lag das Problem womöglich an der Codebasis, für die er zuständig war
    Der Kern des ersten Textes war „2025 gibt es keinen Grund mehr, Ruby neu zu wählen“, und genau darum hätte sich die Diskussion drehen sollen
    Dieser zweite Text ging in Richtung emotionaler Appelle und bestätigte ironischerweise selbst die Behauptung aus dem ersten Artikel, Ruby funktioniere über Gefühl
    Viele Leute, die Elixir mögen, halten Ruby für „nicht ernsthaft“, dabei ist auch Elixir stark von Ruby beeinflusst
    • Ich nutze Elixir seit vielen Jahren und habe anfangs auch Ruby verwendet
      Viele fühlen sich von Elixir angezogen, weil es Rubys vertraute Syntax mit einer funktionalen Grundlage verbindet
      Vor allem dank der BEAM-Runtime sind die Betriebseigenschaften aber völlig anders
      BEAM wirkt nicht einfach wie eine Sprache, sondern wie ein System für Systeme — man kann alles verfolgen, neu starten und beobachten
    • Ich war überrascht, dass die von Ruby inspirierte kompilierte Sprache Crystal nicht erwähnt wurde
      Allerdings ist bei Crystal das Problem der geringeren Popularität noch ausgeprägter als bei Elixir
      Laut TIOBE-Ranking liegt Elixir unter den Top 50
    • Auf macOS ist Ruby standardmäßig installiert, daher muss man für Skripte ohne Zusatzinstallation Perl, Bash, AppleScript oder eben Ruby verwenden
    • Beide Artikel wirken auf mich inhaltsleer
      Der erste spricht nur über StackOverflow-Statistiken und Twitter, der zweite nur über Nostalgie und Ästhetik
      Dass das nicht von einem LLM, sondern von einem Menschen geschrieben wurde, ist eher noch deprimierender
  • Mein Maßstab für eine Sprache, die ich mag, ist nicht „Schreibe ich gern Code in dieser Sprache?“, sondern
    „Möchte ich, dass ein produktives System in dieser Sprache geschrieben ist?“
    Nicht viele Menschen beantworten beide Fragen gleich
    • Code schreiben und ein Geschäft betreiben sind zwei verschiedene Dinge
      Ich mag Ocaml, würde es aber wegen des schwachen Ökosystems und der schwierigen Personalgewinnung nicht für produktive Systeme einsetzen wollen
    • Es hängt vom Zeitalter der Sprache und von der Coding-Kultur des Teams ab
      Python mit Typannotationen und Prüfwerkzeugen ist gut wartbar, andernfalls ist eine starke Dokumentationskultur unverzichtbar
    • Die Antwort fällt anders aus, je nachdem, ob man ein System nur erhalten oder weiterentwickeln will
      Im ersten Fall wäre COBOL denkbar, im zweiten werden andere Optionen interessanter
    • Wenn ich das System selbst gebaut habe, ist mir jede Sprache recht; andernfalls würde ich es lieber an jemand anderen übergeben
    • Ich programmiere gern in Forth, möchte damit aber nicht meinen Lebensunterhalt verdienen
  • Ich mag Ruby wirklich sehr
    Nicht wegen irgendeiner Emotionalität, sondern einfach, weil das Schreiben Freude macht — besonders viel mehr als JavaScript
    Texte, die Ruby angreifen, wirken seltsam auf mich
    Es gibt Erfolgsgeschichten wie Github, Twitter, Coinbase und Shopify, und Skalierungsprobleme sind nur ein Nebenprodukt des Erfolgs
    Ruby ist ein großartiges Werkzeug, und ich würde empfehlen, selbst zu beurteilen, ob es zum nächsten Projekt passt
  • Sowohl der Originalartikel als auch die Erwiderung darauf sind begrifflich unscharf
    Wenn die Behauptung lautet „Ruby skaliert niemals“, dann gilt das für die meisten anderen Sprachen ebenso
    Am Ende stimmen beide Texte darin überein, dass „Ruby auf ewig nicht funktioniert“
    Interessant ist, dass der Originaltext Ruby wegen Platz 18 bei StackOverflow herabsetzt,
    obwohl Ruby 2024 tatsächlich auf Platz 14 liegt und das gelobte Scala neun Plätze darunter steht
    Link zur StackOverflow-Umfrage 2024
    • Der Aussage „Ruby funktioniert auf ewig nicht“ stimme ich nicht zu
      Mein vor zehn Jahren geschriebener Ruby-Code, zum Beispiel WebKits offlineasm-Compiler, läuft immer noch einwandfrei
    • Es ist auch komisch, Java zu verspotten und gleichzeitig Scala zu loben — die meisten Stärken von Scala verdankt es Java
  • Viele bezeichnen Ruby als eine „Sprache für Menschen“, aber tatsächlich wurden alle Sprachen für Menschen geschaffen
    Ruby hat eine saubere Syntax und ist ausdrucksstark, wirkt aber wegen dynamischer Typisierung und Magie (implizitem Verhalten) schwer benutzbar
    Für mich passt es nicht, aber für manche Menschen ist es die perfekte Sprache
    • Rails hat das Konzept „magischer Objekte“ popularisiert
      Fans finden das erstaunlich und angenehm, auf manche wirkt es aber beängstigend
      Auch Pythons Flask nutzt auf ähnliche Weise context local proxy
      Zig und Go entstanden dagegen als Gegenreaktion unter dem Motto „Alles muss explizit sein“, Rust liegt irgendwo dazwischen
      Rust ist streng, bietet aber DSL-artige Ausdruckskraft auf saubere Weise
  • Ich bin vor zehn Jahren bei Ruby zu Elixir gewechselt
    Die Algorithmusleistung wurde zehnmal besser, dank Immutability traten weniger Bugs auf, und auch die Concurrency-Unterstützung war hervorragend
    Durch Pattern Matching und Guards verschwand Boilerplate, es gibt keinen GIL und pro Prozess eine eigene GC
    Die Lernkurve ist etwas steil, aber Elixir skaliert langfristig bei Wartung und Last deutlich besser
    Die Ruby-Community ist weiterhin großartig
    Ich wünschte nur, Elixir könnte zu nativen Executables kompiliert werden oder im Browser laufen
    • Ich hatte eine sehr ähnliche Erfahrung
      Ich „denke“ immer noch in Ruby, mache private Projekte aber in Elixir/Erlang
      Im Unternehmen nutze ich Golang und Python, aber das macht keinen Spaß
      Persönliche Skripte schreibe ich weiterhin in Ruby
  • Dieser Text wirkt, als würde jemand seine Sprache verteidigen
    Wertvoller als Popularität oder Vertrautheit fände ich eine nüchterne Diskussion darüber, wie sich die Eigenschaften einer Sprache auf die Codequalität auswirken
    Solche Diskussionen schrecken Menschen oft wegen Begriffen wie Monaden oder Applikativen ab, dabei sind gerade das die wirklich nützlichen Debatten
    • Codequalität, Produktivität und Stabilität lassen sich objektiv nur schwer messen, daher läuft es am Ende oft auf unterschiedliche Erfahrungen hinaus
    • Nicht nur Codequalität, auch Einfachheit, Lesbarkeit und Ausdrucksgeschwindigkeit sind wichtig
      Je mehr Typen und Einschränkungen es gibt, desto höher ist die Qualität, aber desto geringer sind Entwicklungstempo und Flexibilität
    • Wer sich für solche Themen interessiert, kann zu Büchern wie Eloquent Ruby greifen
    • Falls es Aufsätze oder Artikel gibt, die analysieren, „welche Sprachmerkmale beim Bau großer Systeme vorteilhaft sind“, würde ich sie wirklich gern lesen
  • Ich bin kein Ruby-Fan, aber der Wired-Originaltext war 100% clickbait-getriebener Rage-Content
    Solche Texte sind auf HN wie ein Giftstoff, der Sprachkriege auslöst
    Man muss sie nicht ernst nehmen
  • Ich mochte Ruby wegen seiner Ausdrucksstärke, seiner vollständigen Objektorientierung und seiner gut lesbaren Syntax
    Inzwischen passt Kotlin besser zu mir — dank statischer Typisierung und ergonomisch gestaltetem Syntaxdesign
    Ruby wirkt mit wachsender Projektgröße unsicher, bleibt aber für kleine Aufgaben eine liebenswerte Sprache
    • Früher habe ich einmal gesehen, wie durch falsch verwendete sessionbezogene Variablen in Ruby Benutzerkonten durcheinandergerieten
      Vielleicht lag das nicht an der Sprache, aber in Sprachen mit weniger Schutzmechanismen sammelt sich tendenziell eher riskanter Code an
    • Ruby gilt als vollständig objektorientiert, aber wenn man zum Beispiel if.class ausführt, ist das nicht ganz so
      Unter verbreiteten Sprachen kommt es diesem Ideal aber wohl am nächsten