Por qué existen tantos lenguajes de programación
Publicado el 2026-09-12 por frfrand
Cada uno optimiza algo distinto y lo paga en otro lado. Compilado o interpretado, tipado o no, con recolector de basura o sin él: los tres ejes que explican casi todas las diferencias.

Existen miles de lenguajes de programación. La pregunta razonable es por qué, si todos terminan haciendo que un procesador ejecute instrucciones.
La respuesta es que cada uno optimiza algo distinto, y lo paga en otro lado. Casi todas las diferencias se explican con tres ejes.
Eje 1: cuándo se traduce el código
Compilado. Se traduce a código de máquina antes de ejecutar. C, Rust, Go.
Ganás velocidad en ejecución y detección temprana de errores: el compilador te rechaza el programa antes de que llegue a un usuario. Perdés inmediatez, porque entre cambiar algo y verlo hay un paso de compilación.
Interpretado. Se traduce mientras corre. Python, JavaScript, Ruby.
Ganás velocidad de desarrollo: cambiás y ves. Perdés rendimiento y detección temprana; muchos errores aparecen recién cuando esa línea se ejecuta.
En el medio. Java y C# compilan a un formato intermedio que una máquina virtual traduce a código nativo mientras corre. Eso permite optimizaciones que un compilador estático no puede hacer, porque conoce el comportamiento real del programa.
Eje 2: cuándo se verifican los tipos
Tipado estático. Los tipos se comprueban al compilar. Si pasás un texto donde va un número, no compila.
Tipado dinámico. Se comprueban al ejecutar. Más flexible, y el error aparece en producción.
La discusión sobre cuál es mejor lleva décadas y la síntesis práctica es bastante clara: en proyectos chicos y de vida corta, el tipado dinámico va más rápido; en proyectos grandes y de vida larga, el estático ahorra mucho más de lo que cuesta.
Eso explica una tendencia de los últimos años: TypeScript sobre JavaScript, anotaciones de tipos en Python. Empezar flexible y agregar verificación cuando el proyecto crece.
Eje 3: quién libera la memoria
Este eje es el que más diferencias profundas produce.
Vos. En C, reservás y liberás a mano. Control total, y una categoría de errores (usar memoria liberada, desbordar un búfer) que causó una parte enorme de las vulnerabilidades de las últimas décadas.
Un recolector de basura. Java, Go, Python, JavaScript. Un proceso automático libera lo que ya no se usa. Eliminás esa clase de errores, a cambio de pausas impredecibles y más consumo de memoria.
El compilador lo demuestra. Es el aporte de Rust: un sistema de propiedad y préstamos que permite al compilador verificar en tiempo de compilación que la memoria se libera correctamente. Sin recolector, sin pausas, y con una curva de aprendizaje considerable.
Por qué siguen apareciendo
Cada lenguaje nuevo nace de una insatisfacción concreta:
- Go nació en Google por los tiempos de compilación y la complejidad de C++, apostando a un lenguaje deliberadamente simple con buena concurrencia.
- Rust nació en Mozilla por los errores de memoria en navegadores.
- TypeScript nació porque JavaScript creció más allá de lo que su falta de tipos podía sostener.
- Swift y Kotlin nacieron para reemplazar lenguajes viejos en plataformas donde no había alternativa.
Ninguno "reemplazó" al anterior. Se sumaron, porque cada uno resolvió bien un caso distinto.
Cómo elegir, honestamente
En la práctica, el lenguaje rara vez decide el éxito de un proyecto. Cuatro criterios importan más que la elegancia de la sintaxis:
Qué tiene el ecosistema. Las bibliotecas disponibles ahorran más tiempo que cualquier característica del lenguaje.
Qué sabe el equipo. Un equipo que domina una herramienta le gana a una herramienta mejor que nadie conoce.
Qué restricciones reales hay. Tiempo real, memoria muy limitada, una plataforma que impone la elección.
Cómo se va a mantener. Dentro de dos años, con otras personas leyendo ese código.

