C est le meilleur choix (2025)

(sqlite.org)

7 points par GN⁺ 2026-01-07 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Depuis 2000, SQLite est un moteur de base de données léger implémenté en C, et il n’est pas prévu de le réécrire dans un autre langage
C est considéré comme le langage le plus adapté à SQLite du point de vue des performances, de la compatibilité, de la faible dépendance et de la stabilité
Les langages orientés objet (C++, Java, etc.) présentent de fortes contraintes d’appel interlangage, et une approche procédurale peut au contraire être plus simple et plus rapide
Les « langages sûrs » comme Rust ou Go ne sont pas encore assez matures et ne correspondent pas à la stratégie qualité de SQLite (par ex. tests de branches à 100 %, récupération en cas de OOM)
Un portage futur vers Rust reste envisageable, mais seulement si plusieurs conditions sont remplies en matière de maturité, de compatibilité, de performances et de support des outils

1. Pourquoi C est le meilleur choix

SQLite a été implémenté dès le départ en C standard le 29 mai 2000, et il n’existe toujours aucun projet de migration vers un autre langage
Les raisons avancées en faveur de C pour implémenter SQLite sont les performances, la compatibilité, la faible dépendance et la stabilité

SQLite est une bibliothèque bas niveau utilisée de façon intensive, où la rapidité est indispensable
- Les documents “Internal Versus External BLOBs” et “35% Faster Than The Filesystem” sont cités comme preuves de performance
C fournit un contrôle proche du matériel au point d’être qualifié de « langage assembleur portable », tout en conservant la portabilité entre plateformes
D’autres langages affirment être « aussi rapides que C », mais aucun ne prétend être plus rapide que C

Presque tous les systèmes permettent d’appeler des bibliothèques écrites en C
Par exemple, Android permet à des applications Java d’appeler SQLite via un adaptateur
Si SQLite avait été écrit en Java, il n’aurait pas pu être utilisé dans des applications iPhone basées sur Objective-C ou Swift

Les bibliothèques écrites en C ont très peu de dépendances d’exécution
Dans sa configuration minimale, SQLite n’a besoin que des fonctions suivantes de la bibliothèque C standard
- memcmp(), memcpy(), memmove(), memset(), strcmp(), strlen(), strncmp()
Même dans une build complète, il n’utilise guère plus que malloc(), free() et les entrées/sorties de fichiers
À l’inverse, les langages modernes exigent souvent des runtimes de plusieurs Mo et des milliers d’interfaces

C est un langage ancien qui évolue peu, offrant un comportement clair et prévisible
Lorsqu’on développe un moteur de base de données petit, rapide et fiable comme SQLite, il est important que les spécifications du langage ne changent pas fréquemment

Certains développeurs pensent qu’un système complexe ne peut être implémenté qu’avec un langage orienté objet, mais SQLite montre le contraire
Les bibliothèques écrites en C++ ou en Java ne peuvent généralement être utilisées que par des applications écrites dans le même langage
- À l’inverse, une bibliothèque C peut être appelée depuis presque n’importe quel langage
L’orientation objet est un modèle de conception, pas le langage lui-même ; il est aussi possible d’implémenter une structure orientée objet en C
L’orientation objet n’est pas toujours la meilleure solution, et du code procédural peut être plus simple, plus facile à maintenir et plus performant dans certains cas
Aux débuts de SQLite (début des années 2000), Java était encore immature et C++ souffrait de graves problèmes de compatibilité entre compilateurs
- À l’époque, C était clairement un meilleur choix, et il y a encore aujourd’hui très peu d’intérêt à une réécriture

Ces dernières années, des « langages sûrs » comme Rust et Go ont attiré l’attention, mais SQLite reste en C

Pendant les dix premières années de SQLite, les langages sûrs n’existaient pas
- Une réécriture en Go ou en Rust serait possible, mais elle comporterait un risque de nouveaux bugs et de baisse de performance
Les langages sûrs insèrent souvent des branches supplémentaires comme les vérifications de limites de tableau
- Dans un code correct, ces branches ne sont pas exécutées, ce qui rend impossible d’atteindre 100 % de tests de branches
La plupart des langages sûrs interrompent le programme en cas de manque de mémoire (OOM)
- SQLite est conçu pour se rétablir correctement même en cas de OOM, ce qui entre en conflit avec ce comportement
Tous les langages sûrs existants sont récents et évoluent rapidement
- SQLite préfère un langage ancien et stable

Il existe une possibilité de réécrire SQLite en Rust, mais un portage vers Go est presque impossible
- Raison : Go n’aime pas assert()
Conditions préalables à un portage vers Rust
1. Rust devra gagner en maturité et ralentir son rythme d’évolution pour devenir un “langage ancien et stable”
2. Rust devra pouvoir générer des bibliothèques génériques appelables depuis tous les langages
3. Il devra générer du code objet pouvant fonctionner sur des appareils embarqués sans système d’exploitation
4. Il devra disposer d’un outillage permettant des tests avec 100 % de couverture de branches
5. Il devra fournir un mécanisme de récupération en cas de OOM
6. Il devra démontrer une implémentation sans perte de performance au niveau de C
Les développeurs qui pensent que Rust remplit ces conditions peuvent contacter directement l’équipe SQLite pour en discuter

SQLite est un moteur de base de données petit, rapide et fiable, et les caractéristiques du langage C correspondent à cet objectif
Une transition vers un langage orienté objet ou un langage sûr n’apporterait pas de bénéfice réel en matière de compatibilité, de performances ou de contrôle qualité
La simplicité et la stabilité de C soutiennent la maintenance à long terme et la fiabilité de SQLite