Julia es rápida. Simplemente no es Python.

La conferencia del Premio Turing suele ser una mierda. Formal, banal, seguro. Excepto cuando los gigantes de CS deciden romper el guión. John Backus usó el suyo para lanzar la programación funcional. Ken Thompson nos advirtió que nuestros compiladores podrían estar mintiéndonos. Edsger Dijkstra nos dijo que seamos humildes ante nuestro propio cerebro.

Kenneth Iverson hizo algo diferente.

En 1979, nos presentó “La notación como herramienta de pensamiento”. Sostuvo que la forma en que escribimos código cambia nuestra forma de pensar. Una buena notación libera al cerebro de un trabajo innecesario. Iverson creó APL para esto. APL parece espeluznante, lleno de símbolos que parecen letras griegas sobre ácido. Pero permitió a los matemáticos pensar en ecuaciones, no en bucles. No más traducir cálculos mentales al torpe Fortran. Funcionó. No fue adoptado en todas partes. No importó. Demostró el punto: dos idiomas pueden convertirse en uno.

Ahora, sesenta años después, tenemos el problema de las dos lenguas.

Reglas de Python. A todos les encanta. Es el amigo de la fiesta que te cuenta todo pero conduce fatal. Python es lento. Brutalmente. Los defensores agitan las manos. No ayuda.

Los investigadores crean prototipos en Python porque es amigable. Luego, cuando el rendimiento importa, reescriben las secciones críticas en C++ o Rust. Lo hacen dos veces. Los agentes codificadores de IA no pueden solucionarlo. La optimización tiene un piso. Si el piso es lento, el edificio se mantiene lento.

Piense en la construcción. La madera es fácil de cortar. Puedes armar un cobertizo un sábado. El acero es difícil de trabajar. Pero no se construyen rascacielos con una sierra. ¿Qué pasaría si tuvieras madera que fuera fuerte como el acero? ¿O un lenguaje ergonómico como Python pero rápido como C?

Somos codiciosos.

Cuatro informáticos escribieron esas palabras en 2012. Eran usuarios de Matlab. Lisp piratas informáticos. Pythonistas. Rubíistas. Adictos a Perl. Odiaban que cada herramienta que amaban fuera perfecta para algo y terrible para otra cosa. Lo querían todo. Código abierto. Sencillo para principiantes. Lo suficientemente potente para los hackers más duros. La llamaron Julia.

Conocí a Julia en 2017. Fue una casualidad. Estaba escuchando a Sebastian Seung, un neurocientífico que mapea los conectomas cerebrales. El nombre en sí parecía una disculpa por el resto del campo. Olvídese de C++ o MUMPS. O incluso Haskell. Julia era atractiva. Simple.

También fue cuidadosamente diseñado.

Los creadores habían visto fracasar otros lenguajes. Tomaron las buenas ideas, dejaron el equipaje. Para 2026, la comunidad de Julia será extrañamente madura. Sin dramatismo. No hay guerras apasionadas por la sintaxis. Atrae a científicos, no sólo a codificadores. No están interesados ​​en el juego intelectual. Quieren resultados. En JuliaCon, la gente se jacta de haber reescrito código MATLAB y de haber visto pruebas comparativas de aceleración 60 veces mayor. Diez mil veces más rápido que Python, dicen algunos.

Entonces, ¿por qué no está en todas partes?

¿Por qué no le encanta a Stack Overflow? ¿Por qué ganó Python?

Ecosistema. Python tiene bibliotecas para todo. ¿Necesitas hacer algo oscuro? Hay un paquete Python para ello. Julia no tiene ese peso.

Patrocinio corporativo. Objective-C montó el abrigo de Apple. Kotlin montó el de Google. Julia no obtuvo nada de los gigantes de las grandes tecnologías. Creció por sí solo.

O tal vez nada salió mal en absoluto.

Julia es un nicho. Pequeño. Amado. Maneja las grandes máquinas del CERN y la NASA. Ayuda a diseñar medicamentos. Está haciendo el trabajo.

¿Crees que algún idioma eventualmente resolverá el problema de los dos idiomas?

Dudo. La división es inherente al software. Los juegos utilizan motores C++ y scripts Lua. Los backends del servidor combinan la lógica de Python con el rendimiento de Rust. El desarrollo frontend falla cada vez que intenta adoptar Rust o Go.

Seguimos queriendo la solución mágica. Madera que no se pudre. Python que no se detiene.

Construimos con lo que funciona. Cambiamos de herramientas cuando no es así. Eso no es un error.

Es el trabajo.