Un kernel de sistema operativo construido desde cero, con un subconjunto funcional de Lisp en 500 líneas y un subconjunto de C en 1300 líneas. Total: unas 800 líneas de código. Dieciséis meses de trabajo iterativo. Ninguna dependencia externa. Y una pregunta que plantea directamente: ¿cuánta complejidad de las herramientas que usas es necesaria, y cuánta es simplemente acumulación sin decisión?
Eso es GDSL, el proyecto de firthemouse que apareció recientemente en Hacker News y que merece más atención de la que suele recibir un proyecto con “800 líneas” en el titular.
¿Qué es GDSL exactamente?
GDSL no es un toy project ni un ejercicio académico en el sentido de “aprende a hacer un intérprete de Lisp en un fin de semana”. Es un kernel operativo funcional que integra dos componentes deliberadamente acoplados: un núcleo en C que actúa como base de arranque (bootstrapping), sobre el cual se levanta un intérprete de Lisp. El C maneja las capas de bajo nivel —gestión de memoria, abstracción de hardware—; el Lisp provee la lógica de alto nivel y la capacidad de introspección y extensión del propio sistema.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀La dualidad no es accidental: es el modelo clásico de los kernels elegantes. Lo que diferencia a GDSL de otros proyectos minimalistas —como tinylisp (99 líneas, 21 primitivas, GC y REPL) o MiniLisp (menos de 1.000 líneas, closures, macros y GC de copia)— es que no busca ser solo un intérprete aislado. Es un sistema cohesivo donde ambos componentes se necesitan mutuamente para existir.
El resultado práctico: cualquier desarrollador competente puede leer, entender y modificar el sistema completo en una tarde. Eso, en el contexto actual de toolchains que ningún individuo puede dominar en su totalidad, es una declaración de principios.
Bootstrapping: cuando el compilador se compila a sí mismo
Uno de los conceptos más elegantes de la computación es el bootstrapping de compiladores: la capacidad de un compilador de compilarse a sí mismo. En GDSL, el flujo conceptual es el siguiente: el núcleo en C sirve como compilador huésped inicial; una vez activo, el subconjunto Lisp puede extender y redefinir partes del sistema; el kernel resultante puede, en teoría, recompilarse usando sus propias herramientas.
Este proceso es desafiante, especialmente por la sensibilidad del recolector de basura a las optimizaciones del compilador. Proyectos históricos como Corman Lisp en Windows enfrentaron exactamente este problema, al punto de necesitar deshabilitar optimizaciones del compilador para no interferir con el GC. Que GDSL lo aborde es una señal de que su autor está trabajando en el nivel correcto de seriedad.
Por qué importa para founders tech
La pregunta obvia es: ¿quién necesita construir un kernel? La respuesta más honesta: probablemente pocos. Pero las razones por las que estudiar uno importan son más amplias:
Portabilidad extrema. Un kernel de 800 líneas puede ejecutarse en entornos embebidos, dispositivos IoT o arquitecturas exóticas donde LLVM o GCC son impensables. Para startups de hardware en LATAM, este tipo de runtime ultraligero es directamente útil.
Superficie de ataque reducida. Menos código significa menos vectores de vulnerabilidad. En productos donde la seguridad es crítica —fintech, healthtech, infraestructura industrial— esto no es un detalle menor.
Velocidad de compilación. Los tiempos de build impactan directamente en la velocidad de iteración. Un compilador que se reconstruye en segundos cambia el ciclo de desarrollo.
DSLs para productos verticales. Startups que necesitan lenguajes de configuración propietarios —fintech con reglas de negocio complejas, legaltech con lógica contractual, healthtech con protocolos clínicos— pueden tomar GDSL como base para construir su propio DSL en semanas, no meses. Este uso conecta con el mismo principio que documentamos al explorar por qué XML sigue siendo una opción válida para lógica declarativa: cuando tienes reglas de negocio complejas, un lenguaje específico para el dominio bate a la prosa de código general.
Comprensión profunda del toolchain. Los mejores ingenieros de sistemas entienden su entorno de extremo a extremo. Proyectos como GDSL son el camino más directo a ese nivel.
El contexto del minimalismo en sistemas
GDSL no existe en el vacío. Hay una tradición activa de implementaciones minimalistas: tinylisp, MiniLisp, stutter (Lisp educativo en C99 sin dependencias externas, con GC mark-sweep), cmacro (macros al estilo Lisp para C). Lo que los une es la convicción de que entender cómo funciona algo desde sus primeros principios —no usar un framework que lo abstrae— produce ingenieros distintos.
En un ecosistema donde las herramientas de desarrollo crecen en complejidad de forma casi incontrolable, hay algo estratégico en tomar proyectos como este en serio. No para reescribir tu stack. Para entender qué parte de la complejidad de tu stack es inevitable, y qué parte es simplemente inercia.
Como señalamos al revisar la crisis del open source y el cierre de Jazzband, el ecosistema de proyectos de código abierto está bajo presión creciente. GDSL es exactamente el tipo de proyecto que lo sostiene desde abajo: trabajo profundo, sin sponsors corporativos, construido por el placer de entender cómo funcionan las cosas.
