1. C лучший

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

Начиная с его начала 2000-05-29, SQLite был осуществлен в универсальном C. C был и продолжает быть лучшим языком для осуществления такой библиотеки программного обеспечения, как SQLite. Нет никаких планов повторно написать SQLite на любом другом языке программирования.

Причины, почему C это лучший язык, чтобы осуществить SQLite, включают:

• Производительность.
• Совместимость.
• Независимость.
• Стабильность.

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

Библиотека низкого уровня, которой интенсивно пользуются, должна быть быстрой. И SQLite быстр, посмотрите здесь и тут для примеров.

C это большой язык для написания быстрого кода. C иногда описывается как "портативный ассемблер". Это позволяет разработчикам закодировать максимально близко к используемому оборудованию, все еще оставаясь портативным через платформы.

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

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

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

Так, например, приложения Android, написанные на Яве, в состоянии вызвать 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++ или Яве, могут вообще пользоваться только приложения, написанные на том же самом языке. Трудно написать приложение на Haskell или Java, чтобы вызвать библиотеку, написанную на C++. С другой стороны, библиотеки, написанные на C, вызываются из любого языка программирования.

li>

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

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

3. Когда SQLite сначала развивался, Ява была молодым и незрелым языком. C++ был более старым, но подвергался такой болезни роста, что было трудно найти любые два компилятора C++ которые работали бы одинаково. Таким образом, C был определенно лучшим выбором, когда SQLite начал развиваться. Ситуация менее абсолютная теперь, но нет пользы в перекодировании SQLite в этом пункте.

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

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

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

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

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

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

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