Warum Ruby sich auch nach langer Zeit immer noch wie Zuhause anfühlt

 (caio.ca)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ruby ist weder die schnellste noch die angesagteste Sprache, bleibt aber auch nach mehr als 15 Jahren mit vielen anderen Sprachen die Wahl, zu der man zurückkehrt, wenn man die Arbeit tatsächlich genießen möchte
  • refinements, Forwardable, SimpleDelegator, Object#then, Kernel#tap und nummerierte Parameter bieten kleine syntaktische Annehmlichkeiten und einen gut lesbaren Ablauf
  • Die Standardbibliothek mit Thread::Queue, json, csv sowie RuboCop und Ruby LSP ermöglicht eine praktische Entwicklungsumgebung ohne viele kleine Gems und komplexe Konfiguration
  • Auf YJIT in Ruby 3.x folgen in 4.x ZJIT, die den Abstand bei CPU-intensiven Aufgaben verkleinern; in einem einfachen Fibonacci-Vergleich lag Ruby mit ZJIT innerhalb des 2- bis 3-Fachen von Go
  • Es gibt Bereiche, in denen Rust, Go oder Python besser passen, aber bei Web-Apps, Hintergrundverarbeitung und internen Tools bleiben Developer Happiness und schnelle Iteration klare Stärken von Ruby

Sprachliche Gründe, warum Ruby sich angenehm anfühlt

  • Ruby ist weder die schnellste noch die angesagteste Sprache, bleibt aber auch nach mehr als 15 Jahren zwischen verschiedenen Sprachen die Sprache, zu der man zurückkehrt, wenn man die Arbeit wirklich genießen möchte
  • refinements erlauben es, Klassen nur in einem begrenzten Gültigkeitsbereich zu öffnen, sodass sich kleine syntaktische Annehmlichkeiten in Dateien oder Blöcken ergänzen lassen, ohne den gesamten Namespace zu verschmutzen
    • Das passt gut zu Test-Helpern oder internen DSLs in großen Codebasen
    • Methoden wie "hello".quote sind nur dort verfügbar, wo using QuotingRefinement aufgerufen wurde
  • Die Standardbibliothek mit Forwardable und SimpleDelegator ermöglicht saubere Delegation, ohne Wrapper-Methoden von Hand zu schreiben oder zusätzliche Gems hereinzuziehen
    • Wenn man ohnehin Rails nutzt, kann delegate aus Active Support bequemer sein, aber die Ruby-Kernvariante hält allgemeine Skripte leichtgewichtig
  • Object#then und Kernel#tap helfen dabei, Verarbeitungsschritte ohne Zwischenvariablen zu Ketten zu verbinden, die sich von oben nach unten lesen lassen
    • So lässt sich etwa ein Ablauf wie User.new(params).tap { ... }.then { ... }.save für Erzeugung, Logging, Normalisierung und Speichern durchgängig schreiben
  • Nummerierte Parameter seit Ruby 2.7 reduzieren Rauschen in kurzen Callbacks
    • In items.map { _1.price * 1.1 } muss das Block-Argument nicht explizit angegeben werden
  • Der Fiber Scheduler ermöglicht nebenläufigen Code, der wie sequentieller Code aussieht, wenn ein Event Loop angebunden ist
    • In der Form Fiber.schedule do ... end lässt sich Code ausdrücken, der mit anderen Fibers kooperiert

Der aktuelle Stand bei Tools, Performance und Ökosystem

  • Shopifys Ruby LSP bietet Editor-Integration mit minimaler Konfiguration und arbeitet gut mit Steep oder RBS für schrittweise Typisierung zusammen
  • RuboCop sorgt für konsistenten Stil, ohne die zeremoniellen Abläufe, die man in anderen Ökosystemen sieht
  • Die Standardbibliothek bleibt eine stille Stärke, weil für häufige Aufgaben nicht viele kleine Gems ergänzt werden müssen
    • Wer eine Queue braucht, kann Thread::Queue verwenden
    • Für JSON- oder CSV-Parsing decken json und csv die meisten realen Anwendungsfälle ohne großen Aufwand ab
  • Nach YJIT in Ruby 3.x kommt in der 4.x-Serie ZJIT hinzu
    • ZJIT ist ein auf derselben Grundlage aufbauender, aggressiver arbeitender JIT, der heißere Ausführungspfade effektiver kompiliert
    • Erste Zahlen zeigen, dass sich der Abstand zu Sprachen, die bei CPU-intensiven Aufgaben früher deutlich vor Ruby lagen, spürbar verkleinert
    • CRuby ZJIT wird im Ruby-Hauptrepository entwickelt
  • In einem einfachen Benchmark mit rekursiver Fibonacci-Implementierung auf derselben Maschine lag Ruby mit ZJIT innerhalb des 2- bis 3-Fachen von Go, blieb in diesem Fall auch nicht weit hinter optimiertem Rust zurück, während Python mit pypy zurücklag
    • Mikrobenchmarks haben zwar Grenzen, aber auf warmen Codepfaden, in denen der JIT Zeit zum Optimieren hat, können reale Anwendungen noch stärker profitieren
  • Im Vergleich zu Rust liegt Rubys Stärke in der Iterationsgeschwindigkeit für Business-Logik
    • In Rust kann selbst bei Dingen, die zur Laufzeit eindeutig sind, Zeit im Ringen mit dem Borrow Checker verloren gehen
    • Go hat hervorragende Grundlagen für Nebenläufigkeit, aber bis vor Kurzem keine Generics, und die etwas starre Fehlerbehandlung kann einfache Skripte schwerfälliger machen als nötig
    • Python ist der engste geistige Verwandte, verlangt aber insbesondere rund um Klassen und Decorators mehr Boilerplate, um dieselben Ideen auf hohem Niveau auszudrücken
  • Auch Token-Effizienz wirkt sich als praktischer Vorteil von Ruby aus, wenn Code in Modelle eingebettet wird
    • Blöcke lassen sich mit do/end oder geschweiften Klammern ausdrücken, und wenn die Lesbarkeit es zulässt, sind bei Methodenaufrufen kaum Klammern nötig
    • Hashes und Keyword-Argumente sind erstklassige, knappe Sprachmittel, sodass sich im gleichen Kontextfenster mehr tatsächliche Logik unterbringen lässt als in Sprachen mit viel strukturellem Rauschen
  • Rubys Metaprogrammierungs-Werkzeuge eignen sich gut für kleine, gut lesbare APIs
    • Mit Funktionen wie define_method, class_eval und dem Abfangen fehlender Methoden lassen sich ausdrucksstarke APIs ohne Codegenerierungsphase bauen
    • Bibliotheken wie dry-rb oder aasm setzen das maßvoll ein und liefern saubere Zustandsmaschinen und Validierungsschichten
  • Auch Community-Tools und Deployment-Workflows sind gereift
    • byebug und pry fühlen sich flexibler an als viele Debugger, die man anderswo benutzt hat
    • Für Hintergrundjobs sind solid_queue und good_job so einfach, dass man ihre gesamte Implementierung an einem Nachmittag verstehen kann
    • Kamal hat für viele die alten capistrano-artigen Abläufe ersetzt und wirkt wie ein Tool, das von Menschen gebaut wurde, die wirklich kleine Teams betreiben
  • Das bedeutet nicht, dass Ruby Rust oder Go bei jeder Aufgabe schlägt; es gibt weiterhin Bereiche, in denen Rust oder Go besser passen
  • Im breiten mittleren Bereich aus Webanwendungen, Hintergrundverarbeitung und internen Tools bietet Ruby weiterhin Developer Happiness ohne übermäßige Zeremonie oder ständige Kontextwechsel
  • Kleine Annehmlichkeiten und das Gesamtgefühl der Sprache bleiben auch nach mehr als zehn Jahren der Grund, warum man zuerst zu Ruby greift, und neue JIT-Arbeit sowie stetige Sprachverbesserungen verstärken diesen Eindruck weiter

Verwandte Beiträge

  • Ruby 4.0.0
    6 Punkte · 1 Kommentare · 2025-12-26

1 Kommentare

 
GN⁺ 1 시간 전
Lobste.rs-Kommentare

  • Mit dem Ausdruck „no ceremony RuboCop“ kann ich mich schwer anfreunden
    Bei RuboCop steckt ziemlich viel Diskussion darin, welche Cops man auswählt und anpasst und ob man neue Cops aktiviert, die mit aktuellen Updates dazukommen
    StandardRB kommt einem deutlich zeremonieloseren Ansatz näher, aber am Ende muss man sich trotzdem für eines entscheiden
    Sprachen mit eingebautem Linting sind in dieser Hinsicht viel weniger umständlich als Ruby, und es gibt auch weniger belanglose Stil-Debatten

    • Ich habe mich vor etwa 10 Jahren in der Sidekiq-Codebasis für Standard entschieden und es nie bereut
      Einschränkungen geben paradoxerweise Freiheit
    • Kann man nicht einfach überall die Standardwerte verwenden?
      Ich bin generell eher gegen Linter-Konfiguration und würde solche Entscheidungen lieber den Community-Standards überlassen
    • Ehrlich gesagt schwanke ich bei diesem Punkt hin und her
      Einerseits finde ich, dass die RuboCop-Defaults gut genug sind und man ihnen folgen und sie gemeinsam weiterentwickeln sollte, statt den Coding-Stil noch weiter aufzuteilen
      Andererseits sind sie manchmal auch zu meinungsstark, sodass etwas wie standard.rb nötig erscheint
      Ich habe den Artikel aus der Perspektive geschrieben, dass jemand, der Ruby lernt oder wieder dazu zurückkehrt, sich nicht mit unzähligen Gems herumschlagen müssen sollte, nur um angenehm Code schreiben zu können
    • Stimme zu 100 % zu
      Als Go erschien, fand ich es wirklich großartig, dass es ein offizielles Formatierungssystem mitbrachte
      Das Gehirn ist eine Musterabgleichsmaschine, also blendet man Dinge irgendwann einfach aus, sobald man sich daran gewöhnt hat; wenn es Wahlmöglichkeiten gibt, entsteht Unbehagen und alle werden in unterschiedliche Richtungen gezogen
      Das Problem ist, dass weder RuboCop noch Standard in Ruby diese Autorität haben können
      Diese Autorität müsste vom Core-Team kommen, aber das wird wahrscheinlich nicht passieren, weil es der Ruby-Philosophie widerspricht
      In meinen Projekten schalte ich alle RuboCop-Cops aus und aktiviere nur einige wenige
      Einfache Anführungszeichen sind die besten 😀
    • An der Stelle bin ich auch kurz hängen geblieben
      Andere Beiträge scheinen denselben Punkt anzusprechen: https://caio.ca/blog/coding/my-complicated-relationship - „The Wild West of Code Formatting“
      Sinngemäß: „Es ist keine einfache eingebaute Lösung. Es gibt Hunderte konfigurierbare Cops, was zu endlosen Diskussionen darüber führt, welche Regeln aktiviert werden sollen.“

  • Ich stimme größtenteils zu, finde es aber etwas schade, dass Refinements das erste Beispiel sind
    Ich verstehe, warum man sie mag, aber sie gehören eher in die Kategorie, bei der man besser nicht weiß, wie die Wurst gemacht wird
    Die Semantik ist so knifflig, dass man auch 10 Jahre nach der Einführung in MRI noch ständig lästige Bugs findet
    Zum Beispiel gab es allein in den letzten 2 Wochen https://bugs.ruby-lang.org/issues/22071 und https://bugs.ruby-lang.org/issues/22058
    Auch aus Performance-Sicht erschweren sie viele Optimierungen, und bei boxes passiert gerade wieder etwas Ähnliches

    • Die Idee mit boxes wirkt so, als ließe sie sich nur schwer nachträglich in eine Sprache einbauen, in der seit Jahrzehnten alles im selben globalen Namespace lebt
      Auch auf Implementierungsebene wird es vermutlich noch viele versteckte Bugs geben, und bei Bibliotheken wohl ebenfalls
      Ich nutze Ruby inzwischen nicht mehr viel, bin aber gespannt, wie sich das entwickelt
      Sieht interessant aus

  • Dieser Artikel überschneidet sich stark mit meinen Erfahrungen aus meinem Artikel „Returning to Rails“[1]
    Vielleicht ist es Bestätigungsfehler, aber es wirkt so, als würden immer mehr Leute die Schönheit von Rails-Code wiederentdecken oder neu würdigen
    Gleichzeitig muss ich an das Phänomen denken, dass sich Musik- oder Kunstgeschmack oft in den späten Teenagerjahren oder frühen Zwanzigern festigt
    Vielleicht blicken Menschen, die Ruby zum ersten Mal in der „Goldenen Ära“ von Rails erlebt haben, mit rosaroter Brille auf die Zeit von Rails 3 und Capistrano zurück
    Damals war ich tief in einem Ruby-„Shop“ und von lauter Rails-Entwicklern umgeben, sodass es sich anfühlte, als wäre Ruby überall
    Dann sah ich aber im lobste.rs-Thread[2] die Ansicht, dass Ruby in Wahrheit schon immer ziemlich nischig war, und das könnte ebenfalls Einfluss darauf haben
    Trotzdem fühlt sich Ruby für mich immer noch wie Zuhause an und scheint genau so zu funktionieren, wie mein Kopf arbeitet
    Es braucht fast keine Übersetzung, es gibt kaum Überraschungen, und es fühlt sich eher an wie ein Gespräch mit einem Freund als wie das Schreiben einer formalen Arbeit
    Ich habe noch keine Sprache gefunden, die so gut passt, und ich glaube nicht, dass das nur „die Jugend von heute“-Denken ist
    Jedenfalls freue ich mich, dass sie nach all der Zeit immer noch da ist
    Und danke dafür, die Kette „tap / new“ zu zeigen
    Diese Struktur ist so schön und nützlich, dass ich kurz innehalten musste, und ich werde sie sicher ausprobieren
    PS - Nicht direkt themenbezogen, aber der AI-Avatar auf der Startseite wirkt etwas unheimlich
    Er erzeugt stark dieses Uncanny-Valley-Gefühl von „Hat das ein Bot geschrieben?“
    Immer wenn ich so etwas sehe, frage ich mich kurz, ob ich gerade mit einem echten Menschen spreche
    [1]=https://www.markround.com/blog/2026/03/05/returning-to-rails-in-2026/
    [2]=https://lobste.rs/s/jreqtw/returning_rails_2026

    • Ich kann mit Sicherheit sagen, dass ich ein echter Mensch bin
      Ich möchte nur kein echtes Foto von mir veröffentlichen, und der Avatar sieht tatsächlich ähnlich genug aus, dass Leute, die mich kennen, mich erkennen würden

  • In Ruby 3.4 wurde der it-Blockparameter hinzugefügt, den man statt _1 im Beispiel verwenden kann

    items.map { it.price * 1.1 }

    https://rubyreferences.github.io/rubychanges/3.4.html/…

    • Ich hatte vergessen, it zu erwähnen
      Es ist wohl eine relativ neue Funktion, und deshalb will sich die Gewohnheit, in Iteratoren it zu tippen, bei mir einfach nicht einschleifen

  • Ich habe es wirklich geliebt, Code in Ruby zu schreiben, aber die Testlast ist einfach zu groß geworden
    Ich dachte, etwas mehr Typsicherheit in der Sprache würde helfen, aber als wir bei #{last_job} Sorbet in die Codebasis eingebracht haben, hat das den Schwung und den Spaß am Schreiben von Code völlig abgetötet
    Das ist vielleicht keine populäre Meinung, aber ich sehe schon die bloße Existenz von so etwas wie Sorbet eher als schlechtes Zeichen für Ruby
    Ruby selbst ist eine mächtige und unterhaltsame Sprache, aber die Leute haben begonnen, sie für Aufgaben zu verwenden, für die sie ursprünglich nicht entworfen wurde, und dabei Werkzeuge obendrauf gesetzt, um die Anti-Features der Sprache auszugleichen
    Irgendwann fühlte sich jede Zeile wie eine zähe Plackerei an, und ich verbrachte weit mehr Zeit damit, auf verschiedene Build-, Test- und Lint-Tools zu warten, als tatsächlich Code zu schreiben
    Dazu kamen überengineerte Build- und Deployment-Prozesse, sodass selbst grundlegende Dinge lange dauerten und die Arbeit unerquicklich wurde
    Ich vermisse die Ruby-Welt um 2012 sehr
    Rückblickend waren das wirklich gute Zeiten

    • Welche Sprache war deiner Erfahrung nach besser geeignet?
      Ich habe „Aufgaben, für die sie ursprünglich nicht entworfen wurde“ so verstanden, dass du damit große Rails-Anwendungen meinst

  • Ich bin nach 10 Jahren zu Ruby zurückgekehrt, und im „AI“-Zeitalter ist es nützlich, Code, der einem vor den Augen vorbeizieht, tatsächlich zu verstehen und ein LLM steuern oder stoppen zu können
    In ausführlicheren Sprachen ist das schwieriger

  • Ich vermisse Ruby, und noch mehr vermisse ich, dass eine solche Sprache im alltäglichen Produktionseinsatz überhaupt möglich war
    Das war Hoffnung, nein, die Hoffnung selbst
    Zumindest war es das für mich lange Zeit

    • Was ist passiert?

  • Liest sich wie ein von AI hingeschludeter Text
    Andere aktuelle Blogposts klingen ähnlich

    • Ich habe keine solchen Anzeichen wahrgenommen
      Welche Hinweise haben dich zu dieser Einschätzung gebracht?
      Es ist gut, AI-generierte minderwertige Texte auf dieser Website zu benennen, aber man sollte Fehlalarme vermeiden und genau sagen, warum man das denkt
    • Für mich klang das nicht wie ein von AI hingeschluderter Text
      Warum denkst du das?
      Solche Warnungen an sich sind gut, aber ich fände es viel besser, wenn man die Gründe dazusagt

  • Ich habe gute Erinnerungen daran, zu Beginn meiner Karriere mit Ruby gearbeitet zu haben
    Ruby hat wirklich etwas sehr Angenehmes an sich
    Als ich aber wahrscheinlich letztes Jahr wieder etwas aktuelles Ruby benutzt habe, fand ich es schwierig, mich durch die webbasierte Standardbibliotheks-Dokumentation zu navigieren
    Geht das nur mir so? Gibt es Alternativen zur Dokumentation auf ruby-lang.org?

  • Dieser Artikel fühlt sich etwas seltsam an
    Ich hatte einmal Gelegenheit, ein Projekt und ein SDK in Ruby zu schreiben, und seitdem hatte ich überhaupt kein Verlangen mehr, Ruby noch einmal zu verwenden