Почему SQLite написан на C

1. C — лучший выбор

Примечание: Разделы 2.0 и 3.0 этой статьи были добавлены в ответ на комментарии на Hacker News и Reddit.

С момента своего создания 29 мая 2000 года SQLite реализован на общем языке C. C был и остаётся лучшим языком для реализации такой библиотеки, как SQLite. В настоящее время нет планов переписывать SQLite на какой-либо другой язык программирования.

Причины, по которым C является лучшим языком для реализации SQLite:

• Производительность
• Совместимость
• Низкая зависимость
• Устойчивость

1.1. Производительность

Интенсивно используемая библиотека низкого уровня, такая как SQLite, должна быть быстрой. (И SQLite быстрая, см., например, Внутренние против внешних BLOB и на 35% быстрее, чем файловая система.)

C — отличный язык для написания быстрого кода. C иногда описывается как «портативный язык ассемблера». Он позволяет разработчикам писать код, максимально приближенный к базовому оборудованию, сохраняя при этом портативность на разных платформах.

Другие языки программирования иногда утверждают, что они «так же быстры, как C». Но ни один другой язык не претендует на скорость, превосходящую скорость C, для программирования общего назначения, так как таковой нет.

1.2. Совместимость

Практически все системы имеют возможность вызывать библиотеки, написанные на C. Это не относится к другим языкам реализации.

Например, приложения Android, написанные на Java, могут вызывать SQLite (через адаптер). Возможно, для Android было бы удобнее, если бы SQLite был написан на Java, поскольку это упростило бы интерфейс. Однако в приложениях iPhone используются Objective-C или Swift, которые не имеют возможности вызывать библиотеки, написанные на Java. Таким образом, SQLite было бы неприменимо в iPhone, если бы оно было написано на Java.

1.3. Низкая зависимость

Библиотеки, написанные на C, не имеют большой зависимости от времени выполнения. В минимальной конфигурации SQLite требует только следующих функций из стандартной библиотеки C:

В более полном варианте сборки SQLite также использует библиотечные функции, такие как malloc() и free(), и интерфейсы операционной системы для открытия, чтения, записи и закрытия файлов. Но даже в этом случае количество зависимостей очень невелико. В отличие от этого, другие «современные» языки часто требуют многомегабайтные среды выполнения, загруженные тысячами и тысячами интерфейсов.

1.4. Устойчивость

Язык C старый и проверенный. Это хорошо известный и понятный язык. Именно это требуется при разработке такого модуля, как SQLite. Написание небольшого, быстрого и надёжного движка базы данных достаточно сложно, без того, чтобы язык реализации менялся под вами с каждым обновлением спецификации языка реализации.

2. Почему SQLite не написан на языке с объектно-ориентированным программированием?

Некоторые программисты не могут представить себе разработку такой сложной системы, как SQLite, на языке, который не является «объектно-ориентированным». Так почему же SQLite не написан на C++ или Java?

1. Библиотеки, написанные на C++ или Java, как правило, могут использоваться только приложениями, написанными на том же языке. Сложно заставить приложение, написанное на Haskell или Java, вызывать библиотеку, написанную на C++. С другой стороны, библиотеки, написанные на C, могут вызываться из любого языка программирования.

2. Объектно-ориентированное программирование — это шаблон проектирования, а не язык программирования. Вы можете применять объектно-ориентированное программирование на любом языке, включая язык ассемблера. Некоторые языки (например, C++ или Java) делают объектно-ориентированное программирование проще. Но вы всё ещё можете применять объектно-ориентированное программирование на языках, таких как C.

3. Объектно-ориентированное программирование — не единственный допустимый шаблон проектирования. Многие программисты были обучены мыслить исключительно в терминах объектов. И, честно говоря, объекты часто являются хорошим способом разложить задачу. Но объекты — не единственный способ, и не всегда лучший способ разложения задачи. Иногда простой процедурный код легче писать, поддерживать и понимать, и быстрее, чем объектно-ориентированный код.

4. Когда SQLite только разрабатывался, Java был молодым и незрелым языком. C++ был старше, но испытывал такие трудности в развитии, что было сложно найти два компилятора C++, которые работали одинаково. Поэтому C был определённо лучшим выбором в то время, когда SQLite только разрабатывался. Сейчас ситуация менее чёткая, но в настоящее время нет никакой выгоды в переписывании SQLite.

3. Почему SQLite не написан на «безопасном» языке?

Последнее время наблюдается повышенный интерес к «безопасным» языкам программирования, таким как Rust или Go, в которых невозможно или, по крайней мере, трудно совершить распространённые ошибки программирования, такие как утечки памяти или выход за пределы массива. Поэтому часто возникает вопрос, почему SQLite не написан на «безопасном» языке.

1. Ни один из безопасных языков программирования не существовал в течение первых 10 лет существования SQLite. SQLite можно переписать на Go или Rust, но это, вероятно, приведёт к большему количеству ошибок, чем исправит, и, по всей видимости, приведёт к более медленному коду.

2. Безопасные языки вставляют дополнительные машинные ветвления для выполнения таких операций, как проверка того, что доступ к массивам находится в пределах границ. В корректном коде эти ветвления никогда не выполняются. Это означает, что машинный код нельзя на 100% проверить на ветвлениях, что является важной составляющей стратегии качества SQLite.

3. Безопасные языки обычно хотят прервать выполнение, если возникает ситуация недостатка памяти (OOM). SQLite разработан для плавного восстановления после ситуации OOM. Неясно, как это можно реализовать в современных безопасных языках.

4. Все существующие безопасные языки являются новыми. Разработчики SQLite приветствуют усилия исследователей компьютерных языков по разработке языков, которые легче использовать безопасно. Мы поощряем продолжение этих усилий. Но сами мы предпочитаем старые и проверенные языки при реализации SQLite.

При этом существует вероятность, что SQLite однажды будет переписано на Rust. Переписывание SQLite на Go маловероятно, так как Go не любит assert(). Но Rust — возможность. Некоторые предварительные условия должны быть выполнены до того, как SQLite будет переписано на Rust:

1. Rust должен немного созреть, прекратить так быстро меняться и стать более старым и проверенным.
2. Rust должен продемонстрировать, что он может использоваться для создания универсальных библиотек, которые вызываются из всех других языков программирования.
3. Rust должен продемонстрировать, что он может генерировать объектный код, работающий на непопулярных встроенных устройствах, включая устройства без операционной системы.
4. Rust должен получить необходимые инструменты, позволяющие выполнить 100% проверку покрытия ветвлений скомпилированных бинарных файлов.
5. Rust должен иметь механизм плавного восстановления после ошибок недостатка памяти (OOM).
6. Rust должен продемонстрировать, что он может выполнять работу, которую C выполняет в SQLite, без значительной потери скорости.

Если вы «rustacean» и считаете, что Rust уже отвечает перечисленным выше предварительным условиям, и что SQLite следует переписать на Rust, то вас приветствуют и поощряют связаться с разработчиками SQLite конфиденциально и отстоять свою позицию.

Эта страница была в последний раз изменена 29 июля 2025 г. 00:41:26 UTC