ADR-0002: Programmiersprache & Tooling

Status: Proposed
Datum: 2026-05-15
Decider: Malte (mit Claude)
Verwandt: ADR-0004 (Framework), ADR-0009 (Marktdaten), ADR-0010 (Backtesting)
Tags: tooling, foundation

Kontext

mvest braucht eine Programmiersprache und ein Tooling-Setup als Fundament. Die Wahl prägt verfügbare Bibliotheken (Quant, ML, Daten-APIs, Agent-Frameworks), die Geschwindigkeit der Entwicklung und welche Mitwirkenden später leicht beitragen können.

Entscheidungstreiber

Quant/Finance-Ökosystem: pandas, numpy, vectorbt, backtesting.py, yfinance, ccxt, ta-lib, pdfplumber — alle Python.
LLM-Ökosystem: Anthropic SDK, OpenAI SDK, Pydantic AI, LangGraph — Python ist de facto Standard.
Web-Backend: FastAPI ist erstklassig in Python; passt nahtlos zu Pydantic-Modellen aus den Agents.
Reproduzierbarkeit: deterministische Dependency-Resolution, lockfile, schnelle Installs.
Entwicklungsgeschwindigkeit: dynamische Sprache + typing reicht für die Domäne.

Betrachtete Optionen

Option A — Python 3.12, Paket-Manager `uv`

Python als Single-Language-Stack für Agents, Backend, Daten-Layer und CLI. uv als Paket-Manager und Runner (Astral, Rust-basiert).

Reifstes Quant-Ökosystem.

LLM-/Agent-Libs nativ.

uv ist 10–100× schneller als pip/poetry, deterministische Lockfiles, Drop-in zu pip.

FastAPI + Pydantic decken Backend & Schema-Validation in einer Toolchain ab.

Performance bei rechenintensiven Loops mittelmäßig — gegen Vektorisierung mit numpy/pandas in der Praxis kein Problem.

Type-System weicher als bei TypeScript/Rust.

Option B — TypeScript (Node, Bun oder Deno)

TypeScript als Single-Language-Stack. Frontend würde davon profitieren.

Starkes Typsystem.

Frontend & Backend in einer Sprache, wenn man SPA fährt.

Quant-/Finance-Ökosystem deutlich schwächer (keine echten Äquivalente zu vectorbt, ta-lib, pdfplumber-Qualität).

Agent-Frameworks vorhanden, aber weniger ausgereift als die Python-Pendants.

Datenanalyse in TS ist umständlich gegenüber pandas.

Option C — Polyglot (Python Backend, TypeScript Frontend)

Python für Agents/Daten, TypeScript für ein SPA-Frontend.

„Best of both."

Zwei Toolchains, zwei Build-Pipelines, doppelte Schema-Definitionen (oder OpenAPI-Codegen).

Für einen Single-Dev erhebliche Mehrarbeit, ohne dass v1 davon profitiert.

Server-rendered Frontend (HTMX, geplant in ADR-0013) macht TS überflüssig.

Entscheidung

Wir wählen Option A: Python 3.12 mit uv als Paket- und Run-Manager.

Konkrete Festlegungen:

Python-Version: 3.12 (stabil, alle relevanten Libs unterstützen es, gute Performance-Verbesserungen gegenüber 3.11).
Paket-Manager: uv. pyproject.toml als Projekt-Definition, uv.lock als deterministischer Lockfile, ins Repo eingecheckt.
Type-Checking: mypy oder pyright (Wahl in einer späteren ADR, voraussichtlich pyright wegen Geschwindigkeit). Pydantic-Modelle für Agent-I/O.
Linter / Formatter: ruff (lint + format in einem Tool, ebenfalls Astral).
Tests: pytest als Standard.
Skript-Runner: uv run <script> für ad-hoc Scripts, kein separater poetry run-Workflow.

Konsequenzen

Positiv

Direkter Zugriff auf das beste Quant- und LLM-Ökosystem.
Schneller Dev-Loop dank uv (Install-Zeiten messbar im Sekundenbereich).
Eine Sprache vom Coordinator bis zur Web-UI (mit Jinja2-Templates) — minimaler kognitiver Switch-Cost.

Negativ

Falls später ein SPA-Frontend nötig wird (sehr interaktiv, Charts mit Real-Time-Updates), kommt TypeScript trotzdem dazu. Akzeptierte Schuld.
Verzicht auf das stärkere Typsystem von TS/Rust. Wird durch Pydantic + pyright/mypy weitgehend ausgeglichen, aber nicht vollständig.