Limbo - SQLite completamente reescrito en Rust

• Limbo es un proyecto experimental que reimplementa SQLite en Rust, ofreciendo seguridad de memoria
  • Les gusta la naturaleza embebida de SQLite, pero querían un modelo de desarrollo más abierto, por lo que iniciaron el proyecto libSQL
• Razón para hacer un fork de SQLite: se pueden integrar nuevas funciones con facilidad y mantener la compatibilidad con el código existente
  • Desventaja: la suite de pruebas de SQLite es propietaria y está escrita en C, lo que dificulta la evolución del código
• Nuevo enfoque
  • Experimentaron las limitaciones de SQLite al agregar capacidades de búsqueda vectorial
  • Exploran la posibilidad de reescribir SQLite desde cero para mantener la compatibilidad y, al mismo tiempo, permitir una incorporación más agresiva de nuevas funciones
• Próximos pasos
  • Convertir Limbo en un proyecto oficial de Turso
  • El objetivo es construir una nueva arquitectura que mantenga la misma confiabilidad de SQLite y, a la vez, ofrezca seguridad de memoria
• Desafiando la confiabilidad de SQLite
  • Logran un alto nivel de confiabilidad mediante pruebas de simulación determinista (DST)
  • Usan un framework de DST a nivel sistema en colaboración con Antithesis
• Estado actual
  • I/O completamente asíncrono: Limbo tiene un diseño totalmente asíncrono, resolviendo los problemas de la interfaz síncrona de SQLite
  • Diseñado para WASM: pensado para su uso en entornos WASM
  • Rendimiento: en muchas tareas ofrece un rendimiento igual o superior al de SQLite
  • Simplicidad: ofrece una mejor experiencia de usuario al eliminar funciones menos importantes en entornos modernos
• Información adicional
  • Limbo está disponible en GitHub bajo licencia MIT
  • Invitan a quienes estén interesados en construir bases de datos embebidas que lleven la promesa de SQLite al siguiente nivel

[seonwoo960000]

Qué curioso ver en Hacker News un proyecto al que estaba contribuyendo jaja

[GN⁺]

Comentarios en Hacker News

• SQLite parece ser un proyecto que no necesita reescribirse debido a la calidad de su código y sus pruebas rigurosas

  • Hay quienes opinan que sería mejor reescribir primero otros códigos en C

• La discusión de que SQLite no acepta "contribuciones abiertas" pasa por alto que recibir contribuciones no siempre significa aceptarlas

  • SQLite tiene un proceso para contribuir y funciona implementando las funciones propuestas
  • Otros proyectos del ecosistema de SQLite, como Litestream y LiteFS, también tienen políticas de contribución similares

• Hubo una postura negativa ante el anuncio inicial del fork de SQLite3 hacia LibSQL

  • Se pensaba que el fork probablemente fracasaría porque la suite de pruebas de SQLite3 es propietaria
  • Sin embargo, si hay un producto importante, como una reescritura en un lenguaje con seguridad de memoria, entonces el fork sí tendría sentido

• Para obtener el máximo rendimiento, se debería elegir el modo WAL y desactivar los bloqueos consultivos POSIX

  • Hay quien se pregunta si el modo "wal2" está en el radar del proyecto

• Hay comentarios de personas que recién se enteraron de que la suite de pruebas de SQLite es propietaria

  • Android fue construido de una forma parecida, pero ese es otro tema

• No convence la lógica de la sección sobre "async IO"

  • Se considera que no hace falta reescribir SQLite para añadirle una interfaz asíncrona
  • El problema de la interfaz síncrona de SQLite es que el hilo queda inactivo mientras espera el IO
  • SQLite está diseñado para ejecutarse muy cerca del almacenamiento, por lo que el bloqueo de IO puede ser muy breve o inexistente

• Hay opiniones de que es un proyecto en una etapa temprana

  • Se ofrece un ejemplo de código usando Python y Limbo

• Si se compila con Fil-C, se puede obtener un SQLite con seguridad de memoria

  • Solo requiere algunos cambios menores y casi pasa toda la suite de pruebas

• SQLite está compuesto por aproximadamente 156,000 líneas de código y 92,000 líneas de código de prueba

• Se asume que no se está considerando una certificación DO-178B para la variante en Rust

• El nombre "Limbo" también se usó en el lenguaje post-C/UNIX del sistema operativo Inferno de AT&T

[aer0700]

SQLite parece un proyecto que no necesita ser reescrito gracias a la calidad de su código y a sus pruebas rigurosas -> la verdad, esa clase de valoración sobre sqlite me parece realmente envidiable y genial.

[regentag]

Dicen que sigue el proceso DO-178B y que alcanzó 100% de cobertura de código MC/DC.
La historia desconocida de SQLite