R für Quant-Trading: warum Statistiker es lieben, aber Python gewonnen hat.

R ist die Sprache, in der man am elegantesten eine GARCH-Familie schätzt, einen Cointegration-Test schreibt und einen ggplot-Plot baut, der publikationsreif ist — ohne dass man dafür eine Zeile zusätzlichen Code braucht. Und trotzdem läuft heute kaum noch ein Produktivsystem in R. Hier ist die Bestandsaufnahme.

Warum R unter Statistikern Kultstatus hat.

R wurde von Statistikern für Statistiker geschrieben. Das hört man der Sprache an — jeder zweite Operator ist auf statistische Notation hin entworfen. Eine lineare Regression mit Diagnostik in einer Zeile, eine Zeitreihen-Zerlegung in zwei, ein QQ-Plot in drei. Was in Python eine Funktionsaufruf-Choreographie ist, ist in R ein Ausdruck.

Dazu kommen Bibliotheken, die in der Tiefe immer noch Maßstab sind:

• forecast (jetzt im fable-Stack): ARIMA, ETS, TBATS — Rob Hyndmans Lebenswerk. State-of-the-Art-Forecasting mit fünf Funktionsaufrufen.
• fGarch / rugarch: GARCH-Familie in allen Spielarten (EGARCH, GJR, APARCH). Saubere Likelihood-Schätzung, robuste Standardfehler, ordentliche Diagnostik.
• PerformanceAnalytics: Sharpe, Sortino, Omega, Drawdown-Statistiken, Style-Analysis. Eine der ehrlichsten Bibliotheken zur Strategie-Evaluation überhaupt.
• quantmod: Datenbeschaffung (Yahoo, FRED, Quandl), Charting, einfache Indikator-Layer.
• blotter / quantstrat: ehrwürdige Backtest-Engine, etwas verwaist, aber funktional.
• tidyverse: dplyr, tidyr, ggplot2 — pipelinige Datenverarbeitung in einer Eleganz, die Pandas erst nach zehn Jahren ungefähr einholt.

Ein kleines Beispiel: GARCH(1,1) auf DAX-Renditen.

library(quantmod)
library(rugarch)

# Daten holen
getSymbols("^GDAXI", from = "2015-01-01")
ret <- na.omit(diff(log(Cl(GDAXI))))

# GARCH(1,1) mit Student-t-Innovationen
spec <- ugarchspec(
  variance.model = list(model = "sGARCH", garchOrder = c(1, 1)),
  mean.model     = list(armaOrder = c(0, 0), include.mean = TRUE),
  distribution.model = "std"
)

fit <- ugarchfit(spec, ret)
show(fit)

# Forecast
fc <- ugarchforecast(fit, n.ahead = 10)
sigma(fc)

Das ist sieben Zeilen produktiver Code für ein Modell, für das Sie in Python mit arch auch nicht schneller ans Ziel kommen — aber die Diagnostik-Ausgabe von show(fit) ist dichter und besser interpretierbar. Wer als Researcher täglich Volatilitätsmodelle schätzt, hat es in R ein Stück angenehmer.

Wo R im Trading-Stack zuverlässig scheitert.

• Performance bei großen Daten: R hält Daten standardmäßig im Hauptspeicher, mit etwas Overhead pro Vektor. Bei 50 Mio. Bars und Joins über mehrere Tabellen wird das schmerzhaft. data.table hilft enorm, hebt das Problem aber nicht auf.
• Live-Trading-Integration: gibt es, aber halbgar. IBrokers für IBKR ist funktional, hat aber keine Community-Energie mehr. Async ist nie eine Stärke von R gewesen.
• Machine Learning: caret, tidymodels und mlr3 sind ordentliche Frameworks. Aber XGBoost, LightGBM, PyTorch — das R-Wrapping bleibt einen Schritt hinter der Python-Welt zurück. Wer ernsthaft Deep Learning macht, geht in Python.
• Deployment: plumber für REST-APIs funktioniert, aber das Docker-Image für eine R-API mit allen System-Libraries ist zwei Größenordnungen umständlicher als ein FastAPI-Container.
• Sprach-Idiosynkrasien: 1-basierte Indizierung, NSE (Non-Standard-Evaluation), drei OOP-Systeme parallel. Wer aus Python kommt, stolpert eine Weile.

Python vs. R, ehrlich verglichen.

Drei Felder:

• Statistik und Ökonometrie: gleichwertig. Für GARCH, Cointegration, Bayes-Modelle (brms, rstan) ist R noch immer ein Tick eleganter. Für klassische Inferenz nehmen sich beide nichts mehr.
• Research-Reports: R Markdown / Quarto und ggplot sind unschlagbar für Forschungsergebnisse mit publikationsreifen Grafiken. Jupyter mit Matplotlib kommt nahe, aber nicht ganz heran.
• Production-Code, ML, Live-Trading: Python eindeutig vorne. Ökosystem, Container, Async, Cloud-Tooling — alles ist in Python schon vor R angekommen, oft Jahre vorher.

Das Ergebnis: R bleibt die Sprache der akademischen Quant-Forschung, Python ist die Sprache des Tradings. Diese Aufteilung hat sich in den vergangenen zehn Jahren verfestigt und wird sich nicht mehr umkehren.

Ein PerformanceAnalytics-Snippet, das ich vermisse, wenn ich in Python bin.

library(PerformanceAnalytics)

# returns: xts-Objekt mit Strategie-Renditen, Benchmark
charts.PerformanceSummary(returns, main = "Strategie vs. Benchmark")

table.AnnualizedReturns(returns)
table.DownsideRisk(returns)
table.Drawdowns(returns$strategy, top = 5)

# CAPM-Statistik auf einen Schlag
table.CAPM(returns$strategy, returns$benchmark, Rf = 0.02 / 252)

Sechs Funktionsaufrufe, und Sie haben eine komplette Strategie-Evaluation inklusive Drawdown-Tabelle, jährlicher Renditen und CAPM-Statistik. In Python ist das machbar, aber kein Einzeiler — Sie schreiben sich diese Tabellen entweder selbst zusammen oder benutzen quantstats, das hier ein direkter R-Erbe ist.

Meine Praxis.

R taucht bei mir noch in zwei Kontexten auf. Erstens: statistische Forschung. Wenn ich eine neue Volatilitätsmodellfamilie oder eine Regime-Switching-Idee teste, fühlt sich R nach wie vor schneller an als Python. Zweitens: Backtest-Reports für Akademiker oder konservative Mandanten, die einen Quarto-Bericht mit ggplot lieber sehen als eine HTML-Seite aus Plotly.

Alles, was Production wird — Live-Trading, ML-Pipeline, Datenpipeline, REST-API — geht bei mir in Python. Nicht weil R es nicht könnte, sondern weil das umliegende Ökosystem (Container, Cloud, Observability) in Python schlicht reifer ist und das Team-Onboarding einfacher ist.

Wenn Sie heute mit Quant-Trading anfangen und sich für eine Sprache entscheiden müssen: Python. R lernt sich später als Zweitsprache an einem Wochenende — umgekehrt funktioniert das nicht so reibungslos.

Sie haben ein bestehendes R-Setup und überlegen, was davon nach Python wandern soll? Erstgespräch buchen — wir trennen, was bleibt und was migriert.