Durante años, cualquier artículo sobre Python empezaba diciendo que era el lenguaje más usado del mundo. Ese argumento ya no se sostiene: en agosto de 2025 TypeScript adelantó a Python como lenguaje más utilizado en GitHub, el mayor vuelco del ranking en más de una década.
Es un buen momento para hacerse la pregunta en serio, sin el runrún de siempre: si Python ha perdido el primer puesto, ¿por qué sigue siendo una de las mejores inversiones que puede hacer un profesional técnico?
El dato incómodo, y por qué mide otra cosa
El informe Octoverse 2025 de GitHub explica el adelantamiento con una tesis clara: los equipos se desplazan hacia lenguajes tipados porque la asistencia de la IA al programar es más fiable cuando el compilador puede verificar lo que la máquina propone. Y casi todos los frameworks de frontend generan TypeScript por defecto, lo que empuja el ranking hacia arriba de forma casi mecánica.
Dicho de otro modo: el número mide cuánta gente toca cada lenguaje, no dónde es la herramienta correcta. Y en el mismo informe está la otra mitad de la historia: Python sumó más de 850.000 contribuyentes nuevos y aparece en casi la mitad de todos los repositorios de IA creados.
Perdió el titular. No perdió el territorio.
Dónde Python no tiene rival
El aprendizaje automático no se escribe en Python por costumbre. Se escribe en Python porque las bibliotecas que importan —PyTorch, el ecosistema de Hugging Face, todo el stack científico— exponen su interfaz en Python, y desplazarlo exigiría reescribir una década de trabajo acumulado.
Aquí conviene entender algo que casi nadie dice en voz alta, y que explica la paradoja entera.
Python es lento, y da igual
Python no es un lenguaje rápido. Lo que es, es la interfaz de cosas que sí lo son.
Cuando entrenas un modelo, el código Python apenas orquesta: el trabajo real ocurre en C++ y en CUDA, dentro de la GPU. Python es la capa donde decides qué se hace, no la capa donde se hace.
import torch
# Estas tres líneas son Python. El trabajo que describen, no:
# baja a kernels de CUDA compilados y se ejecuta entero en la GPU.
a = torch.randn(8192, 8192, device="cuda")
b = torch.randn(8192, 8192, device="cuda")
c = a @ b # El intérprete solo ha despachado la orden.Por eso la lentitud del intérprete es una crítica que suena demoledora y en la práctica casi nunca lo es: en las cargas donde Python domina, el intérprete no está en el camino crítico. Cuando sí lo está —un bucle numérico cerrado, un servicio con latencia estricta—, Python es efectivamente la herramienta equivocada, y más vale saberlo antes de empezar.
El GIL, su defecto histórico, está cayendo
La objeción de verdad seria contra Python nunca fue la velocidad, sino el GIL: el bloqueo global que impedía que dos hilos ejecutasen código Python a la vez. Durante treinta años, aprovechar los núcleos de una máquina obligó a irse a procesos separados —con su coste de memoria y su serialización— o a bajar a C.
Eso está cambiando de verdad. Python 3.13 introdujo un build experimental sin GIL y, en Python 3.14 (octubre de 2025), el modo free-threaded pasó a estar oficialmente soportado (PEP 779). La penalización sobre código de un solo hilo, severa en la fase experimental, ha bajado a un 5-10 % según plataforma y compilador.
No es el final del camino: el build sigue siendo opcional y el GIL sigue activo por defecto. Pero por primera vez su eliminación tiene un calendario creíble en lugar de ser una promesa perpetua.
La otra queja legítima ya tiene respuesta
La segunda crítica razonable era el empaquetado: un ecosistema de herramientas solapadas donde reproducir el entorno de otra persona era un ejercicio de arqueología. Herramientas como uv y ruff han reordenado ese terreno con una diferencia de velocidad tan grande que la adopción ha sido casi inmediata.
Y en el propio lenguaje, Python 3.14 trae la
evaluación diferida de anotaciones, que resuelve por fin las referencias adelantadas sin
importaciones mágicas, y las template strings (t"..."), pensadas para interceptar y sanear una
cadena antes de construirla: un mecanismo dirigido justo a la clase de vulnerabilidad que las
f-strings facilitan al interpolar sin control.
Dónde NO deberías elegir Python
Un artículo que solo enumera virtudes es publicidad. Estos son los casos en que elegir Python es equivocarse:
- Frontend web. No es su terreno, y no hay discusión.
- Latencia estricta y predecible. El recolector de basura y el intérprete introducen una varianza que no siempre puedes permitirte.
- Bucles numéricos en Python puro. Si el cálculo no baja a una biblioteca nativa, la penalización es real y se nota.
- Distribución de binarios. Empaquetar una aplicación Python sigue siendo más incómodo que compilar un único ejecutable en Go o Rust.
Saber dónde no usar una herramienta es lo que distingue a un profesional de un entusiasta.
Qué significa esto para ti
Que Python haya perdido el primer puesto de GitHub no cambia nada sobre si deberías aprenderlo. El ranking responde a la pregunta «¿qué toca más gente?». La que te importa es otra: ¿dónde está el trabajo que quiero hacer?
Si ese trabajo tiene que ver con datos, con modelos, con automatización o con pegar sistemas que no se hablaban entre ellos, la respuesta sigue siendo la misma que hace diez años. Y ahora, además, con un lenguaje que por fin está resolviendo sus dos defectos históricos.