Ein kleines Team soll in wenigen Wochen eine Buchungsplattform für Seminarräume bauen: Benutzerkonten, Kalender, Rechnungen, eine Verwaltungsoberfläche. Für solche Aufgaben greifen viele Start-ups und Agenturen seit mehr als zwei Jahrzehnten zu Ruby, genauer zu Ruby on Rails. Der Grund ist selten die Rechengeschwindigkeit, sondern die Geschwindigkeit, mit der Menschen in dieser Sprache funktionierende Software schreiben und später noch verstehen.

Ruby ist keine neue Sprache und nicht mehr der Liebling der Konferenzbühnen. Gerade deshalb lohnt ein nüchterner Blick: Was macht Ruby aus, was hat sich in den vergangenen Jahren getan, und in welchen Projekten ist die Sprache heute eine gute Wahl?

Woher Ruby kommt und was die Sprache will

Ruby stammt von dem japanischen Entwickler Yukihiro Matsumoto, in der Szene „Matz“ genannt. Er begann 1993 mit der Arbeit an der Sprache, 1995 erschien die erste öffentliche Version. Matsumoto kombinierte Ideen aus Perl, Smalltalk, Lisp und anderen Sprachen und formulierte ein ungewöhnliches Ziel: Eine Programmiersprache solle in erster Linie Menschen dienen, nicht der Maschine. Programmieren solle Freude machen.

Dieses Ziel prägt bis heute viele Entscheidungen. Ruby bietet oft mehrere Wege, dasselbe auszudrücken, und bevorzugt Formulierungen, die sich fast wie ein Satz lesen. Kritiker halten das für zu viel Freiheit, weil Teams sich auf einen Stil einigen müssen. Befürworter schätzen, dass Code in Ruby oft kurz ist und trotzdem verständlich bleibt.

Ruby ist eine interpretierte, dynamisch typisierte Sprache. Interpretiert heißt: Ein Programm wird nicht vorab in Maschinencode übersetzt, sondern von einer Laufzeitumgebung ausgeführt. Dynamisch typisiert heißt: Der Typ einer Variablen steht erst zur Laufzeit fest, Typangaben im Code sind nicht nötig. Die Referenzimplementierung heißt CRuby oder MRI und ist in C geschrieben. Daneben gibt es Varianten wie JRuby für die Java-Laufzeitumgebung und TruffleRuby auf Basis von GraalVM.

Alles ist ein Objekt: das Grundprinzip

In Ruby ist jeder Wert ein Objekt, auch Zahlen, Zeichenketten und sogar nil, der Wert für „nichts“. Jedes Objekt hat Methoden, die man direkt aufrufen kann. Das klingt abstrakt, hat aber eine praktische Folge: Der Code liest sich von links nach rechts in der Reihenfolge, in der etwas passiert.

name = "Welt"
puts "Hallo, #{name}!"

3.times { puts "Ruby" }          # Zahl 3 hat eine Methode times
puts "köln".capitalize            # => Köln
puts [3, 1, 2].sort.reverse.inspect # => [3, 2, 1]

Die erste Zeile zeigt die typische Zeichenketten-Interpolation: Was in #{...} steht, wird ausgewertet und eingesetzt. Semikolons am Zeilenende und Klammern um Methodenargumente sind in Ruby in vielen Fällen optional.

Duck Typing statt Typhierarchie

Ruby fragt bei einem Objekt nicht, zu welcher Klasse es gehört, sondern ob es die benötigte Methode versteht. Diese Haltung heißt Duck Typing, nach dem Satz „Wenn es aussieht wie eine Ente und quakt wie eine Ente, ist es eine Ente“. Angenommen, ein Webshop exportiert Bestellungen wahlweise als CSV-Datei oder an eine Buchhaltungs-API. Solange beide Exportobjekte eine Methode export haben, kann der restliche Code sie gleich behandeln, ohne dass beide von einer gemeinsamen Basisklasse erben. Das macht Ruby flexibel, verschiebt aber Fehler in die Laufzeit: Fehlt die Methode, merkt man es erst beim Aufruf.

Blöcke: das Markenzeichen der Sprache

Was Ruby-Code so kompakt macht, sind Blöcke. Ein Block ist ein Stück Code, das einer Methode mitgegeben wird und das diese Methode aufrufen kann, eine Art anonyme Funktion. Fast alle Schleifen und Datenumformungen in Ruby funktionieren so.

preise = [19.99, 5.49, 120.0]

# Jeden Preis um 19 % Umsatzsteuer erhöhen
brutto = preise.map { |netto| (netto * 1.19).round(2) }

# Nur Positionen über 20 Euro behalten
gross = brutto.select { |betrag| betrag > 20 }

# Eigene Methode, die einen Block ausführt
def protokolliert
  puts "Start"
  ergebnis = yield
  puts "Ende"
  ergebnis
end

protokolliert { gross.sum }

Das Schlüsselwort yield ruft den Block auf, den der Aufrufer übergeben hat. Seit Ruby 3.4 gibt es zudem den impliziten Blockparameter it, mit dem sich kurze Blöcke wie preise.map { it * 1.19 } noch knapper schreiben lassen. Ab Ruby 3.0 kam außerdem Pattern Matching mit case ... in hinzu, mit dem sich verschachtelte Daten, etwa die Antwort einer JSON-API, elegant zerlegen lassen.

Ruby on Rails: der Grund, warum die meisten Ruby kennen

Den Durchbruch außerhalb Japans brachte ein Framework. David Heinemeier Hansson veröffentlichte Ruby on Rails 2004 als Open Source, herausgelöst aus der Projektmanagement-Software Basecamp. Version 1.0 folgte Ende 2005. Rails setzte zwei Prinzipien durch, die später viele andere Frameworks übernahmen:

• Convention over Configuration: Statt jede Kleinigkeit zu konfigurieren, folgt man Namenskonventionen. Heißt ein Modell Booking, sucht Rails die Daten automatisch in der Tabelle bookings.
• Don’t Repeat Yourself: Jede Information soll nur an einer Stelle im Code stehen.

Dazu kamen Generatoren, die Grundgerüste für Datenbanktabellen, Formulare und Tests erzeugen, und das Datenbankwerkzeug Active Record. Bekannte Plattformen wie GitHub, Shopify und GitLab sind auf Rails gebaut und betreiben bis heute große Rails-Codebasen. Twitter nutzte Rails in den Anfangsjahren und stellte zentrale Teile ab etwa 2010 auf JVM-Sprachen um, ein oft zitiertes Beispiel für die Leistungsgrenzen der damaligen Ruby-Versionen.

Rails hat sich seither weiterentwickelt. Mit Hotwire setzt das Framework seit Version 7 auf serverseitig gerenderte Oberflächen, die sich ohne großes JavaScript-Framework dynamisch anfühlen. Rails 8 erschien 2024 und brachte unter anderem eigene Lösungen für Hintergrundjobs, Caching und Deployment mit, die ohne zusätzliche Dienste wie Redis auskommen sollen. Wer tiefer in die Geschichte und Arbeitsweise des Frameworks einsteigen möchte, findet im Beitrag Die Magie von Ruby on Rails eine ausführliche Darstellung.

Ökosystem: RubyGems, Bundler und Werkzeuge

Bibliotheken heißen in Ruby Gems und werden über das zentrale Verzeichnis RubyGems.org verteilt. Für fast jede Aufgabe aus dem Webumfeld gibt es ausgereifte Gems: Authentifizierung, Zahlungsabwicklung, PDF-Erzeugung, Hintergrundverarbeitung. Bundler hält fest, welche Gems ein Projekt in welcher Version braucht, und sorgt dafür, dass alle Entwicklerinnen und Entwickler sowie der Server mit identischen Versionen arbeiten.

Für die Qualitätssicherung sind RSpec und Minitest als Testwerkzeuge verbreitet, RuboCop prüft den Stil. Wichtig für Unternehmen: Ein großes Gem-Angebot ist auch ein Wartungsthema. Jede Abhängigkeit muss aktualisiert und auf Sicherheitslücken geprüft werden. Werkzeuge wie bundle audit oder die Sicherheitswarnungen von GitHub helfen dabei, ersetzen aber keine Disziplin im Team.

Tempo und Typen: was sich bei Ruby getan hat

Lange galt Ruby als langsam. Das stimmte im Vergleich mit kompilierten Sprachen wie Go oder Java, und es stimmt im Kern bis heute. Die Lücke ist aber kleiner geworden. Ruby 3.0 erschien Ende 2020 mit dem erklärten Ziel, deutlich schneller zu sein als Ruby 2.0. Seit Ruby 3.1 gibt es YJIT, einen Just-in-time-Compiler, der häufig ausgeführten Code während der Laufzeit in Maschinencode übersetzt. Er wurde maßgeblich von Shopify entwickelt und gilt seit Ruby 3.2 als produktionsreif. Laut den Entwicklern beschleunigt er typische Rails-Anwendungen spürbar; wie stark, hängt von der Anwendung ab.

Für die meisten Webanwendungen ist die reine Rechenleistung ohnehin selten der Engpass. Datenbankabfragen, Netzwerkzugriffe und Caching entscheiden mehr über die Antwortzeit. Wo Ruby tatsächlich an Grenzen stößt, sind rechenintensive Aufgaben und hochgradig parallele Verarbeitung. Mit Ractors und einem Fiber-Scheduler bietet Ruby 3 zwar neue Modelle für Nebenläufigkeit, in der Praxis sind sie aber noch wenig verbreitet.

Beim Thema Typen geht Ruby einen eigenen Weg. Mit Ruby 3.0 kam RBS, ein Format, in dem Typen in separaten Dateien beschrieben werden. Prüfwerkzeuge wie Steep nutzen diese Angaben. Daneben hat Stripe mit Sorbet einen eigenen Typprüfer entwickelt, der Typangaben direkt im Code erlaubt. Beides ist optional. Wer an TypeScript gewöhnt ist, wird die Integration als weniger rund empfinden. Für große Codebasen mit vielen Beteiligten lohnt sich der Aufwand trotzdem, weil Fehler früher auffallen.

Neue Ruby-Versionen erscheinen traditionell einmal im Jahr am 25. Dezember. Jede Version wird einige Jahre mit Sicherheitsupdates versorgt; ältere Versionen sollten Unternehmen rechtzeitig ablösen.

Wo Ruby passt und wo nicht

Ruby ist vor allem eine Sprache für Webanwendungen und Backend-Dienste. Typische Einsatzfelder sind:

• Geschäftsanwendungen mit vielen Formularen, Rollen und Datenbanktabellen, etwa Kundenportale, Buchungssysteme oder interne Verwaltungswerkzeuge
• SaaS-Produkte in der Frühphase, bei denen es darauf ankommt, schnell einen ersten nutzbaren Stand zu haben
• Webshops und Marktplätze, ob mit Rails selbst oder als Erweiterung bestehender Plattformen
• Automatisierung und Skripte, etwa mit dem Build-Werkzeug Rake oder der Infrastruktur-Software Chef

Wie schnell sich mit Rails ein erstes Produkt aufbauen lässt, beschreibt der Infothek-Artikel Schnell zum SaaS-MVP mit Ruby on Rails.

Weniger geeignet ist Ruby für Datenanalyse und maschinelles Lernen, wo Python mit seinen Bibliotheken klar dominiert, für Systemprogrammierung und für mobile Apps. Projekte wie RubyMotion für native Apps sind Nischen geblieben. Auch im Frontend spielt Ruby keine Rolle; hier bleibt JavaScript beziehungsweise TypeScript der Standard, auch wenn Rails mit Hotwire den Anteil an eigenem JavaScript klein halten kann.

Ein Punkt, den Entscheider beachten sollten, ist der Arbeitsmarkt. Die Zahl der Ruby-Entwicklerinnen und -Entwickler ist kleiner als bei Java, Python oder JavaScript. Wer ein Rails-Projekt startet, sollte sicherstellen, dass das Wissen nicht an einer einzigen Person hängt. Gleichzeitig sind erfahrene Rails-Teams oft sehr produktiv, weil die Konventionen viel Abstimmung ersparen.

Was das für Ihr Team bedeutet

Ruby ist kein Trendthema mehr, aber eine ausgereifte, stabil gepflegte Sprache mit einem der produktivsten Webframeworks. Unsere Einschätzung: Für datenbankgetriebene Webanwendungen mit überschaubarem Rechenaufwand und einem kleinen bis mittleren Team ist Ruby on Rails nach wie vor eine sehr gute Wahl. Wer bereits eine Rails-Anwendung betreibt, hat selten Grund für einen teuren Wechsel. Sinnvoller ist es, auf aktuelle Ruby- und Rails-Versionen zu aktualisieren und YJIT einzuschalten.

Überschätzt wird dagegen die Sorge, Ruby sei „zu langsam“. Für die allermeisten Geschäftsanwendungen entscheidet die Architektur über die Leistung, nicht die Sprache. Unterschätzt wird eher der Aufwand für Pflege: Dynamische Typisierung verlangt gute Tests, und Gems wollen regelmäßig aktualisiert werden.

Wenn in Ihrem Unternehmen eine Rails-Anwendung modernisiert, ein neues Projekt aufgesetzt oder ein Team geschult werden soll, bietet die Seite zu Ruby on Rails mit Beratung, Coaching und Seminaren einen Überblick über unsere Angebote. Für den Einstieg ins Programmieren allgemein eignet sich das Seminar Web- und App-Entwicklung für Einsteiger.

Häufige Fragen zu Ruby

Ist Ruby schwer zu lernen?

Nein, die Grundlagen gelten als vergleichsweise leicht zugänglich, weil die Syntax knapp und gut lesbar ist. Schwieriger wird es bei fortgeschrittenen Techniken wie Metaprogrammierung, also Code, der zur Laufzeit anderen Code erzeugt oder verändert. Rails nutzt solche Techniken intensiv, was Einsteigern manchmal wie Magie vorkommt. Es lohnt sich, zuerst Ruby selbst und dann das Framework zu lernen.

Was ist der Unterschied zwischen Ruby und Ruby on Rails?

Ruby ist die Programmiersprache, Ruby on Rails ein darauf aufbauendes Framework für Webanwendungen. Ruby lässt sich auch ohne Rails nutzen, etwa für Skripte oder mit schlankeren Webframeworks wie Sinatra oder Hanami.

Kann man mit Ruby mobile Apps entwickeln?

Nur eingeschränkt. Native Apps entstehen heute meist mit Swift, Kotlin oder Cross-Plattform-Frameworks wie Flutter und React Native. Ruby kommt hier vor allem als Backend ins Spiel: Eine Rails-Anwendung stellt die API bereit, mit der die App kommuniziert.

Wie gefragt sind Ruby-Kenntnisse auf dem Arbeitsmarkt?

Es gibt weniger Ruby-Stellen als für die großen Sprachen, aber auch weniger Bewerberinnen und Bewerber. Gesucht werden vor allem Rails-Erfahrung, Kenntnisse in Testautomatisierung und die Fähigkeit, ältere Rails-Anwendungen zu modernisieren.