C ist am besten (2025)

(sqlite.org)

7 Punkte von GN⁺ 2026-01-07 | Noch keine Kommentare. | Auf WhatsApp teilen

SQLite ist seit 2000 eine leichtgewichtige Datenbank-Engine, die in C implementiert ist, und es gibt keine Pläne, sie in einer anderen Sprache neu zu schreiben
C wird für SQLite als die am besten geeignete Sprache in Bezug auf Leistung, Kompatibilität, minimale Abhängigkeiten und Stabilität angesehen
Objektorientierte Sprachen (C++, Java usw.) haben große Einschränkungen bei sprachübergreifenden Aufrufen, während ein prozeduraler Ansatz sogar einfacher und schneller sein kann
„Sichere Sprachen“ wie Rust oder Go sind noch nicht ausgereift und passen nicht zu der Qualitätsstrategie von SQLite (z. B. 100% Branch-Tests, OOM-Wiederherstellung)
Die Möglichkeit einer zukünftigen Portierung nach Rust bleibt offen, aber dafür müssten verschiedene Bedingungen wie Reifegrad, Kompatibilität, Leistung und Tool-Unterstützung erfüllt sein

1. Warum C die beste Wahl ist

SQLite wurde am 29. Mai 2000 von Anfang an in standardkonformem C implementiert, und bis heute gibt es keine Pläne, auf eine andere Sprache umzusteigen
Als Gründe, warum C für die Implementierung von SQLite geeignet ist, werden Leistung, Kompatibilität, geringe Abhängigkeiten und Stabilität genannt

SQLite ist eine intensiv genutzte Low-Level-Bibliothek, für die hohe Geschwindigkeit essenziell ist
- Als Beispiele wird die Leistung in den Dokumenten „Internal Versus External BLOBs“ und „35% Faster Than The Filesystem“ belegt
C wird oft als „portable Assemblersprache“ bezeichnet, weil es hardwarenahe Kontrolle bietet und zugleich Portabilität zwischen Plattformen wahrt
Andere Sprachen behaupten zwar, „so schnell wie C“ zu sein, aber keine Sprache behauptet, schneller als C zu sein

Nahezu jedes System bietet die Möglichkeit, in C geschriebene Bibliotheken aufzurufen
Android kann SQLite beispielsweise aus Java-Anwendungen über einen Adapter aufrufen
Wäre SQLite in Java geschrieben worden, wäre es in Objective-C- oder Swift-basierten iPhone-Apps nicht nutzbar gewesen

In C geschriebene Bibliotheken haben sehr wenige Laufzeitabhängigkeiten
In der Minimal-Konfiguration benötigt SQLite nur die folgenden Funktionen aus der Standard-C-Bibliothek
- memcmp(), memcpy(), memmove(), memset(), strcmp(), strlen(), strncmp()
Selbst beim vollständigen Build werden im Wesentlichen nur malloc(), free() und Datei-E/A verwendet
Moderne Sprachen dagegen verlangen oft Laufzeitumgebungen von mehreren MB Größe und Tausende von Schnittstellen

C ist eine alte Sprache mit wenigen Veränderungen, die klares und vorhersehbares Verhalten bietet
Bei der Entwicklung einer kleinen, schnellen und zuverlässigen Datenbank-Engine wie SQLite ist es wichtig, dass sich die Sprachspezifikation nicht ständig ändert

Manche Entwickler glauben, komplexe Systeme ließen sich nur in objektorientierten Sprachen implementieren, aber für SQLite trifft das nicht zu
In C++ oder Java geschriebene Bibliotheken können in der Regel nur von Anwendungen verwendet werden, die in derselben Sprache geschrieben sind
- C-Bibliotheken dagegen lassen sich aus fast jeder Sprache aufrufen
Objektorientierung ist ein Designmuster und nicht die Sprache selbst; auch in C lassen sich objektorientierte Strukturen umsetzen
Objektorientierung ist nicht immer die beste Wahl, und prozeduraler Code kann einfacher sowie bei Wartbarkeit und Leistung vorteilhafter sein
In der Frühphase der SQLite-Entwicklung (Anfang der 2000er) war Java noch unreif, und bei C++ gab es schwere Kompatibilitätsprobleme zwischen Compilern
- Damals war C eindeutig die bessere Wahl, und auch heute gibt es kaum Vorteile einer Neuschreibung

In jüngerer Zeit haben „sichere Sprachen“ wie Rust und Go viel Aufmerksamkeit bekommen, doch SQLite bleibt weiterhin bei C

In den ersten zehn Jahren von SQLite gab es noch keine sicheren Sprachen
- Eine Neuschreibung in Go oder Rust wäre zwar möglich, würde aber das Risiko neuer Bugs und geringerer Geschwindigkeit mit sich bringen
Sichere Sprachen fügen zusätzliche Branches wie Array-Grenzprüfungen ein
- In korrektem Code werden diese Branches nicht ausgeführt, wodurch 100% Branch-Tests unmöglich werden
Die meisten sicheren Sprachen beenden Programme bei Speichermangel (OOM)
- SQLite ist jedoch so entworfen, dass es sich auch bei OOM korrekt erholt, was mit diesem Verhalten kollidiert
Bestehende sichere Sprachen sind allesamt neu und befinden sich in schneller Veränderung
- SQLite bevorzugt alte und stabile Sprachen

Es besteht die Möglichkeit, SQLite in Rust neu zu schreiben, aber eine Portierung nach Go ist nahezu unmöglich
- Grund: Go mag assert() nicht
Voraussetzungen für eine Portierung nach Rust
1. Rust müsste reifer werden und sich langsamer verändern, um zu einer „alten und stabilen Sprache“ zu werden
2. Rust müsste universell nutzbare Bibliotheken erzeugen können, die aus allen Sprachen aufrufbar sind
3. Rust müsste Objektcode erzeugen können, der auch auf Embedded-Geräten ohne Betriebssystem läuft
4. Es müsste ein Tooling-Ökosystem geben, das Tests mit 100% Branch-Coverage unterstützt
5. Rust müsste Mechanismen zur OOM-Wiederherstellung bereitstellen
6. Es müsste nachgewiesen werden, dass eine Implementierung ohne Leistungsverlust auf C-Niveau möglich ist
Entwickler, die glauben, dass Rust diese Bedingungen erfüllt, können das SQLite-Team direkt kontaktieren und darüber diskutieren

SQLite ist eine kleine, schnelle und zuverlässige Datenbank-Engine, und die Eigenschaften der Sprache C passen zu diesem Ziel
Ein Wechsel zu einer objektorientierten oder sicheren Sprache bringt hinsichtlich Kompatibilität, Leistung und Qualitätskontrolle keinen praktischen Nutzen
Die Einfachheit und Stabilität von C tragen die langfristige Wartbarkeit und Zuverlässigkeit von SQLite