Cada vez que alguien aprende a programar, empieza memorizando palabras en inglés. if, return, function, print. Lo damos tan por sentado que ni lo cuestionamos. Un desarrollador coreano llamado xodn348 sí lo hizo, y construyó Han: un compilador funcional, de tipado estático y rendimiento nativo en el que todo el código se escribe en Hangul.
No es un transpilador ni un wrapper simbólico. Es Rust bajo el capó, LLVM como backend, y palabras clave como 함수 (función), 만약 (si), 반환 (retornar) y 출력 (imprimir). La pregunta que dispara —y que afecta directamente al ecosistema tech de habla hispana— es sencilla y algo incómoda: ¿por qué asumimos que el código debe parecerse al inglés?
¿Qué hace Han técnicamente?
Han no es un experimento de sintaxis bonita. Su arquitectura comparte ADN con lenguajes de sistemas:
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 🚀- Tipado estático en tiempo de compilación: el compilador detecta errores de tipo antes de ejecutar, igual que Rust o Go.
- Compilación a binarios nativos vía LLVM: el mismo backend que usa Rust, Clang o Swift. Rendimiento comparable a C.
- Estructuras, cierres y manejo de errores explícito: no es solo un intérprete básico; soporta patrones modernos de diseño.
- I/O de archivos y modo REPL: operaciones prácticas que lo acercan a usos reales, no solo a demos.
Lo que distingue a Han de proyectos anteriores en este espacio es precisamente esa combinación: sintaxis en lengua natural no inglesa + cadena de compilación de nivel productivo. Wenyan (chino clásico) compila a JavaScript. Qalb (árabe) es funcional pero experimental. 易语言 es popular en China pero limitado a escritorio. Han apunta más alto: binarios nativos optimizados por LLVM, con una arquitectura que podría, en teoría, competir en rendimiento con cualquier lenguaje compilado moderno.
El inglés en el código no es una ley de la física
Hay una razón histórica para que los lenguajes de programación sean anglófonos: los primeros computadores se diseñaron en EE.UU. y el ecosistema tecnológico global se construyó en inglés. Pero esa razón histórica no es técnica. No hay nada en LLVM, en los compiladores ni en la teoría de lenguajes que exija que las palabras clave sean inglesas.
Lo que Han hace al construirse con Rust y LLVM es separar esas dos cosas: demuestra que un compilador moderno puede funcionar perfectamente con cualquier sistema de escritura. El motor de optimización no sabe ni le importa si la fuente dice if o 만약. Solo ve el árbol sintáctico abstracto.
Esto tiene implicaciones concretas para el mundo hispanohablante. Hay más de 500 millones de hablantes nativos de español. Una fracción pequeña de esa población programa. Parte de esa barrera es económica y de acceso. Pero otra parte —difícil de cuantificar, fácil de subestimar— es cognitiva: aprender a programar implica, simultáneamente, aprender el vocabulario técnico de otro idioma. Para alguien que no maneja el inglés fluidamente, esa doble carga es real.
¿Por qué importa esto más allá de la curiosidad técnica?
Si lo miramos solo como objeto de estudio técnico, Han es fascinante: un proyecto individual que implementa un compilador completo con features no triviales. Pero el valor de largo plazo está en otro lado.
Proyectos como Han acortan la distancia entre “se puede hacer” y “alguien lo hará”. Cada vez que un desarrollador demuestra que X es técnicamente posible, otro empieza a construir sobre esa base. En el ecosistema español/portugués de LATAM, hay oportunidades reales sin explorar:
- Plataformas educativas de programación en español real, no solo con nombres de variables en español pero sintaxis en inglés. Scratch localizado existe, pero es para niños; no hay equivalente para adultos que quieren aprender a programar seriamente.
- Herramientas de documentación y tooling pensadas para comunidades no anglófonas: el problema no es solo el lenguaje de programación, sino toda la infraestructura alrededor (docs, tutoriales, error messages, foros).
- APIs y DSLs sectoriales en español: en industrias como salud, derecho o finanzas latinoamericanas, hay espacio para lenguajes de dominio específico que hablen el idioma del sector.
Esto conecta con un debate más amplio sobre quién construye software en la era de la IA y cómo se redistribuye la capacidad técnica globalmente. Si los agentes de IA pueden generar código en cualquier lenguaje de programación, ¿importa menos la barrera del inglés? Quizás. Pero la infraestructura de pensamiento —conceptos, metáforas, lógica de sistemas— sigue filtrándose a través del idioma en que aprendimos a pensar.
El estado del proyecto y la recepción
Han fue publicado en Hacker News bajo “Show HN” y generó la respuesta típica de esa comunidad: interés genuino por el rigor técnico mezclado con escepticismo pragmático sobre adopción en equipos globales donde el inglés sigue siendo la lingua franca del código colaborativo. Es una tensión válida.
El repositorio incluye guía de instalación, ejemplos de código y el REPL interactivo. Para alguien con curiosidad por arquitectura de compiladores —independientemente de si habla coreano— es un caso de estudio valioso: ver cómo se implementa un sistema de tipos estático o cómo se genera código LLVM desde un AST propio siempre tiene valor pedagógico. El hecho de que las palabras clave sean en Hangul es casi un detalle.
Vale la pena contrastar esto con la tendencia que apunta TypeScript migrando su compilador a Go: los lenguajes de programación evolucionan, cambian de runtime, se reescriben. No son monumentos inamovibles. La pregunta de qué idioma humano usan sus palabras clave es apenas una dimensión más de ese diseño.
Por qué importa
Han no va a reemplazar Python ni Rust en producción. Ese no es el punto. Su valor está en hacer la pregunta en voz alta con código funcionando: ¿la hegemonía del inglés en programación es técnica o cultural? La respuesta, que Han demuestra con cada línea compilada, es que es cultural. Y lo que es cultural puede cambiar.
Para el ecosistema tech hispanohablante, el mensaje más útil no es “deberíamos tener un lenguaje en español” —eso puede ser o no viable dependiendo del contexto— sino que la barrera lingüística en programación es un problema de diseño, no una ley natural. Y los problemas de diseño tienen solución.
