LOOK: un lenguaje de backend de un solo binario para olvidarse del stack web
El proyecto integra HTTP, bases de datos, colas y autenticación en un único binario escrito en C++23 para simplificar el despliegue y reducir la complejidad de dependencias.
Desarrollar un endpoint REST moderno suele implicar arrastrar una torre de dependencias: el lenguaje, un framework web, el gestor de paquetes, drivers de base de datos, librerías de caché, sistemas de colas y configuración de servidor. LOOK parte de la premisa de que ese stack es innecesariamente pesado y ofrece una alternativa construida desde cero en C++23: un lenguaje y runtime diseñados exclusivamente para backend web que integran todas esas capas en un mismo binario.
La propuesta arquitectónica elimina la necesidad de instalar frameworks adicionales. El propio entorno de ejecución proporciona el servidor HTTP, el enrutamiento, soporte para WebSocket y Server-Sent Events (SSE), además de sistemas de sesiones, autenticación, validación, caché y colas de mensajes. La intención no es crear otro lenguaje de scripting genérico, sino reducir radicalmente la superficie de ataque operativa y la complejidad de despliegue al consolidar componentes que tradicionalmente se gestionan por separado.
Bajo el capó, LOOK utiliza una máquina virtual basada en bytecode. Según los propios benchmarks del proyecto, esta implementación ofrece una mejora de rendimiento de unas 41 veces sobre una ejecución directa tipo tree-walking (visita de árboles) en cargas de trabajo de CLI. Aunque esta cifra compara dos modos de ejecución del mismo runtime y no sirve como referencia universal frente a otros lenguajes, ilustra el beneficio de la compilación previa a bytecode. El sistema también incluye un módulo explícito que obliga a declarar dependencias visibles, evitando comportamientos ocultos a nivel global.
El modelo de despliegue es el punto fuerte para quien administra infraestructura. Al ser un binario portable, LOOK permite copiar el ejecutable y funcionar en entornos Linux, Windows o Docker sin configurar largas cadenas de instalación. Soporta tanto el sirviente HTTP nativo como integraciones vía CGI o FastCGI. Esta última opción es clave para entornos de producción, ya que permite mantener el runtime en memoria con workers persistentes. De este modo, las conexiones a base de datos y las estructuras de runtime se reutilizan mediante pooling, eliminando el coste de arranque por petición que suele penalizar a los lenguajes interpretados tradicionales.
La conectividad nativa abarca MySQL, MariaDB, PostgreSQL, SQLite y Redis (protocolo RESP2). Al manejar las implementaciones de protocolo directamente dentro del runtime, el proyecto gana control sobre la gestión de conexiones, el manejo de errores y el rendimiento, en lugar de depender de paquetes externos. La API de base de datos es directa, permitiendo consultas parametrizadas y transacciones sin wrappers adicionales.
El proyecto se presenta como una opción para reducir la fricción operativa en aplicaciones web de mediano y gran tráfico, especialmente en servidores donde la simplicidad del despliegue y el control sobre el entorno de ejecución son prioritarios. No pretende sustituir a lenguajes de propósito general, sino optimizar el stack específico para el trabajo de backend.
