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

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

С момента своего создания 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. Написать небольшой, быстрый и надежный механизм базы данных достаточно сложно, даже если язык реализации не будет меняться с каждым обновлением спецификации языка реализации.

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

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

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

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

4. Когда SQLite только разрабатывался, Java был молодым и незрелым языком. C++ был старше, но переживал такие трудности роста, что было трудно найти два компилятора C++, которые работали бы одинаково. Так что C определенно был лучшим выбором, когда SQLite только разрабатывался. Сейчас ситуация менее острая, но на данном этапе перекодирование 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, без значительного снижения скорости.

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

Последний раз эта страница обновлялась 9 мая 2025 г., 15:56:17Z.