Empecé Ori pensando en un problema relativamente pequeño: quería un lenguaje donde leer código fuera tan natural como leer una especificación. Pero a medida que dibujaba las primeras piezas, quedó claro que la decisión tocaba algo mucho más grande — sintaxis, sistema de tipos, tooling e incluso cómo los agentes de IA leen el código.

Hay una pregunta que me incomoda desde hace tiempo, y es simple: ¿por qué la mayoría de los lenguajes optimiza para quien escribe, si pasamos mucho más tiempo leyendo? Cada atajo sintáctico parece inofensivo por separado. Pero cuando un proyecto acumula cientos de ellos, leer se convierte en decodificar — sobre todo para quien llega ahora, sea una persona o un code agent.

Lo que intentaba resolver

Quiero un lenguaje de sistemas más simple que Rust en la superficie, sin renunciar a tipos explícitos ni a compilación nativa (AOT). “Simple” aquí no significa limitado: significa que lo básico debe ser obvio, y la complejidad aparece progresivamente, solo donde tiene sentido.

Dónde empieza a fallar la solución obvia

El camino más obvio sería tomar una sintaxis existente e ir ajustándola. Rust tiene el ecosistema, Go tiene la simplicidad, Python tiene la legibilidad. Pero cada uno carga una filosofía que no es la que quiero: Rust exige mucho a quien empieza, Go esconde demasiado poder en nombre de la simplicidad, Python empuja los errores a runtime. Ninguno fue diseñado pensando en “¿cómo entiende un agente este módulo sin cargar todo el repositorio?”.

Las alternativas que tienen sentido

En el diseño actual, tres fuerzas tiran en direcciones distintas:

• Ergonomía de lectura: sintaxis explícita, poca magia, nombres que dicen lo que hacen. Cuesta verbosidad.
• Rendimiento nativo: AOT con un backend serio. Cuesta tiempo de implementación — cada feature debe sobrevivir al codegen.
• Tooling desde el día uno: LSP, buenos diagnósticos, ejemplos ejecutables. Cuesta velocidad, porque la documentación y los errores amables dan tanto trabajo como el compilador.

La opción que más me interesa hoy

En este momento, mantener el compilador en Rust con AOT me parece la combinación más coherente: control de bajo nivel, ecosistema creciente de tooling y un core independiente de la interfaz. La sintaxis sigue legible por defecto, y cualquier azúcar sintáctico debe justificar su existencia mostrando que no perjudica la lectura.

Eso no significa que la decisión esté cerrada. Solo significa que, hoy, paga su propio costo.

Lo que aún me preocupa

Dos cosas. Primero: ¿hasta dónde se puede simplificar sin convertir el lenguaje en un juguete? Segundo: los diagnósticos. Un lenguaje reading-first que devuelve errores crípticos traiciona su propia propuesta — y un buen error es caro de construir.

Próximos pasos

La prueba real es compilar ejemplos no triviales, medir y ver dónde la sintaxis empieza a doler. Si el dolor aparece siempre en el mismo lugar, ahí vive la próxima decisión. El estado actual está en el repositorio — especificación, ejemplos y changelog abiertos.