Los lenguajes de programación más populares de 2025

(spectrum.ieee.org)

16 puntos por GN⁺ 2025-09-29 | 8 comentarios | Compartir por WhatsApp

Python > Java > C++ > SQL > C# > JavaScript > TypeScript > C > Shell > Go > R > PHP > Kotlin > Rust > Dart > Swift
Según una encuesta de IEEE Spectrum, Python volvió a ocupar el primer lugar este año, mientras que JavaScript cayó del 3.º al 6.º puesto
Se analiza que este cambio está relacionado con la tendencia a reemplazar JavaScript, muy usado en desarrollo web, por la programación asistida por IA (por ejemplo, vibe coding)
Los indicadores tradicionales como la cantidad de preguntas en Stack Exchange y la actividad en GitHub han caído bruscamente desde la adopción de la IA, lo que muestra que los métodos tradicionales para medir la popularidad de los lenguajes están perdiendo solidez
A medida que la generación de código con IA se vuelve común, disminuye la importancia de las diferencias de sintaxis y estructura entre lenguajes, y se vuelve más clara la tendencia de no aferrarse a un lenguaje específico
Esto dificulta la aparición de nuevos lenguajes y la expansión de sus ecosistemas, y muestra incluso la posibilidad de que desaparezca el propio concepto de popularidad de los lenguajes de programación

Resumen

IEEE Spectrum publicó un análisis integral de los principales lenguajes de programación y sus tendencias en 2025
Este ranking refleja distintas perspectivas, como el mercado laboral, el ecosistema open source y el uso en la academia y la industria
También ofrece información sobre las características de los principales lenguajes, las razones detrás de su crecimiento y los lenguajes especializados por área tecnológica

Ranking de lenguajes de este año

En el ranking base de Spectrum de 2025, Python mantuvo el primer lugar y JavaScript cayó al 6.º puesto
En el ranking de Jobs, Python también subió al primer lugar, y SQL sigue manteniendo una fuerte competitividad en el mercado de contratación
La cantidad total de preguntas relacionadas con lenguajes en Stack Exchange cayó a 22% del nivel de 2024

Criterios para calcular el ranking

Popularidad: se calcula usando diversos foros en línea, repositorios de software, datos de empleo y tendencias de búsqueda
Uso en el trabajo real: se analizan los lenguajes más usados en el mercado tomando como base ofertas laborales de empresas y participación en proyectos open source
Análisis por área: se reflejan criterios para destacar lenguajes sobresalientes en áreas específicas como IA, embebidos, web y móvil
Para medir la popularidad se usaron diversos indicadores, como volumen de búsquedas en Google, preguntas en Stack Exchange, actividad en GitHub y menciones en artículos académicos
Sin embargo, a medida que los desarrolladores resuelven problemas mediante conversaciones con LLMs (ChatGPT, Claude, etc.), disminuyen las señales de datos públicas
Gracias a herramientas de IA como Cursor, incluso la cantidad de preguntas ha bajado, debilitando la validez de los indicadores existentes

La IA y el difuminado de las fronteras entre lenguajes

Desde desarrolladores experimentados hasta principiantes, al depender de la IA se presta menos atención a la sintaxis y las estructuras de control de los lenguajes
Si tiene suficientes datos de entrenamiento, la IA puede generar código en cualquier lenguaje
En consecuencia, la elección del lenguaje podría pasar a ser un factor secundario, como las diferencias entre conjuntos de instrucciones de CPU en el hardware
En el futuro, el debate sobre la popularidad de los lenguajes podría quedar relegado a un tema marginal, al nivel de comparar anchos de vía ferroviaria

Será aún más difícil que aparezcan nuevos lenguajes

En el pasado, el ecosistema de un lenguaje podía expandirse solo con libros, demos y código de ejemplo (por ejemplo, The C Programming Language)
Pero la IA requiere grandes volúmenes de datos de entrenamiento, por lo que los lenguajes emergentes quedan en desventaja de soporte
De hecho, se ha reportado el fenómeno de que la IA produce peores resultados en lenguajes menos usados
Esto puede crear un entorno en el que sea difícil para los nuevos lenguajes alcanzar masa crítica

El futuro de la programación

Los lenguajes modernos cumplen esencialmente dos funciones: la abstracción para el procesamiento de datos y la prevención de errores del desarrollador
Sin embargo, el avance de la IA hace posible un nuevo flujo de trabajo de prompt → lenguaje intermedio → ejecución, más allá de la estructura del lenguaje
En ese caso, podría consolidarse un enfoque en el que, en lugar de mantener y modificar código fuente, se regenere ajustando el prompt
Se espera que el rol del programador del futuro se concentre menos en la gramática del lenguaje y más en capacidades como diseño de arquitectura, selección de algoritmos e integración de sistemas

Conclusión y perspectivas

La programación está entrando en su mayor etapa de transformación desde la aparición de los compiladores en los años 50
Incluso si parte de la burbuja de la IA se desinfla, es muy probable que continúe el uso de LLMs para ayudar a escribir código
Por lo tanto, después de 2026, el propio concepto de “lenguaje popular” podría perder sentido, y serán necesarios nuevos indicadores para medir la popularidad

8 comentarios

skrevolve 2025-10-09

Python sí va en bajada.

shakespeares 2025-10-01

Hasta ahora, el ecosistema de JavaScript sigue siendo mucho más amplio, pero creo que por la IA existe la posibilidad de que se tienda hacia lenguajes de bajo nivel como Rust.

GN⁺ 2025-09-29

Opiniones de Hacker News

Con la ayuda de la IA, los programadores cada vez se preocupan menos por un lenguaje específico o por los detalles, pero al final siempre están condenados a volver a profundizar cuando un problema pequeño se conecta con toda clase de complejidades. No todos buscan el nivel ensamblador como un code golfer de ffmpeg, pero debe haber una razón por la que los lenguajes de tercera generación siguen manteniendo su presencia. Al final, es un equilibrio entre expresividad y precisión, entre en qué queremos enfocarnos y qué detalles queremos delegar. Si sacrificas los lentes (la transparencia) por resultados más rápidos, necesitas una sonda alternativa sólida para poder verificar qué está pasando después.
- Hay que tomar en cuenta que este artículo viene de IEEE. El público objetivo de IEEE son más los científicos que los programadores. Desde la perspectiva de un científico, el código es un medio para expresar sus ideas, y mientras puedan expresarlas lo más rápido posible, no les importa demasiado si el código queda desordenado o si es reutilizable. Por ejemplo, los científicos mencionan Arduino como si fuera un lenguaje, y para ellos eso es algo natural. Los científicos que usan Arduino no necesariamente saben C++, pero sí se sienten orgullosos de poder programar en “Arduino”.
- Son claramente dos casos muy distintos. Si un compilador produce un resultado incorrecto para una arquitectura específica, puedes reportar el bug y quizá obtener ayuda de la comunidad o de terceros. En la práctica, eso es raro en lenguajes o librerías populares, y si ya estás cruzando ese nivel de complejidad, probablemente tienes la capacidad de lidiar con esos edge cases. Pero si una IA te da un resultado incorrecto, tienes que averiguarlo todo por tu cuenta. No puedes ir a reclamarle a OpenAI o Anthropic preguntando “¿por qué hace esto?”. En el primer caso a veces se puede tolerar no saber, pero en el segundo jamás.
- Si de verdad a la mayoría de los desarrolladores no les importaran el conjunto de instrucciones del CPU o las rarezas del hardware, entonces ni siquiera habrían generado sintaxis de lenguaje y habrían pasado directo a generar código máquina para la arquitectura del chip. Incluso podrían simplemente mandar un prompt y dejar que una AI VM genere el código máquina objetivo. Tal vez algún día pase, pero hoy estamos lejísimos de eso.
- Usar IA en un área que no conoces bien es realmente peligroso, y no creo que deba fomentarse.
- Lo único que hicieron fue ensanchar la ‘tabla ancha sobre el abismo’.
Es muy difícil encontrar buenas fuentes para este tipo de datos. StackOverflow también va a la baja, y la metodología de IEEE por lo menos es relativamente realista, pero todas las fuentes de datos que usa tienen sus propios defectos. El número de resultados en Google es la señal indirecta más volátil. Los resultados de búsqueda incluyen casi todo lo que mencione esa consulta, y no hay garantía de que realmente representen 2025. Además, la gente que usa un lenguaje normalmente no dice explícitamente “lenguaje de programación X”. Contar toda esa exposición mediática como exposición de “top language” es forzado. TIOBE también usa este método y, para colmo, muestra la popularidad con dos decimales. Si ves datos antiguos, la popularidad de C se redujo a la mitad en solo dos años y al año siguiente se duplicó, pero en el mercado real no cambió absolutamente nada. El margen de error de este método es de ±50%.
- Para medir la demanda real de un lenguaje, los datos de ofertas de empleo son lo más práctico y útil. No muestran directamente la cantidad real de código que corre en las empresas, pero en la mayoría de los casos sí dan la visión más intuitiva del uso real, la demanda y las tendencias de la industria. Si existe una organización enorme como un banco con COBOL y casi no hay rotación, eso podría no aparecer en los datos, pero aun así no hay una fuente mejor que esa.
- Estas fuentes suelen ser autorreforzantes y autorreferenciales. Pienso que conviene usar la mejor herramienta, la que mejor conozco, o la que el cliente quiere o deja más ingresos. Ada, COBOL, FORTH y Lua también encajan en ese contexto. Al final, salvo para SEO, las métricas de popularidad no significan mucho.
- Este año Perl apareció de golpe en el Top 10 de TIOBE, pero no he visto nuevos desarrolladores Perl. Con Ada pasa igual. Me pregunto dónde están todos esos desarrolladores Ada.
- Lo que más me gusta de estas estadísticas es la estadística de lenguajes por repositorio público de GitHub. Da conteos de repos públicos y PR por lenguaje desde 2012.
- Tal vez en este momento las estadísticas de consultas a LLM sean la mejor fuente posible. El artículo original también habla bastante de eso.
Pensé que JavaScript iba a estar en segundo lugar, pero parece que TypeScript le quitó el puesto. Personalmente veo JavaScript y TypeScript casi como de la misma familia, así que creo que tendría sentido sumar sus puntajes.
- En este tipo de agregados, si los juntas entonces sí serían el verdadero segundo lugar.
- Sí, habría que combinarlos, y de paso tampoco entiendo qué hace Arduino en esa lista.
- También estoy de acuerdo; hay varios ítems que deberían agruparse, y los lenguajes basados en BEAM también convendría unirlos en una sola categoría.
- Si también juntamos Java & Kotlin y C & C++, entonces quizá JS & TS ya no queden en segundo lugar.
A quienes les sorprende ver a Java tan arriba, ¿será que en toda su carrera solo han trabajado en backends Node.js de startups de 10 personas? ¿Nunca han trabajado en grandes empresas, especialmente en software empresarial?
- Java ya es el nuevo COBOL. Gran parte de las industrias financiera, aseguradora y de salud se subieron a Java hace décadas, y siguen migrando código COBOL legado a Java.
- También hay algo curioso. Trabajé más de 5 años en Google y ya sabía por estadísticas que había muchísimo código Java, pero personalmente solo habré mirado código Java unas tres veces. Da la impresión de que Java sí se usa mucho, pero en zonas aisladas dentro de las empresas, como si estuviera confinado a cierta parte específica de la cadena de valor económica.
- A quienes les sorprende que Java esté tan alto probablemente no vienen de finanzas. Claro, el mundo enterprise no usa solo Java; en grandes empresas fuera de finanzas también hay lugares donde dominan Microsoft, .NET y C#.
Trabajo como desarrollador backend en fintech y se me hace difícil encontrar un lenguaje objetivo al cual moverme. Usé Node y Ruby, pero cada vez extraño más la ausencia de un sistema de tipos estático. TypeScript también tiene limitaciones con cosas como la opción non strict. Lenguajes como Java/.Net o Go me parecen anticuados. Rust suena divertido, pero no encaja con mi background. Me pregunto si alguien tendría alguna recomendación.
- Si piensas seguir en fintech, fuera de Java, C#, C++, TypeScript no hay mucho más. Aun así, a veces hay empresas que usan Haskell, F# o Scala. Estos lenguajes suelen usarse sobre todo para DSL de workflows. Si te interesan los lenguajes de arreglos, finanzas es uno de los pocos sectores donde todavía sobreviven, aunque esas posiciones son difíciles de encontrar. También valdría la pena revisar Dyalog (APL), J, BQN y Kdb+ (Q). Recursos de Arraycast
- Scala es el mejor lenguaje que he usado. Combina las ventajas de TypeScript con las fortalezas de Java y Rust, y fintech es uno de los pocos nichos que quedan donde todavía puedes conseguir trabajo con Scala.
- Rust es un lenguaje de propósito general, así que puedes hacer prácticamente cualquier cosa con él. Pero siempre importa usar la herramienta adecuada. El ecosistema es clave; depende de qué planeas construir.
- Yo también estoy en la misma búsqueda y siento que Gleam es lo que mejor encaja. Tiene tanto la simplicidad de Go como la comodidad de Kotlin.
- Java es lento, pero su sintaxis ha ido mejorando y sigue siendo la columna vertebral de muchas empresas medianas y grandes. En empresas pequeñas suele ser más fácil encontrar JS/Ruby/Python, probablemente porque priorizan más la productividad y el costo de ingeniería. Por eso se da el fenómeno de que los lenguajes interpretados se usan más que los enterprise o de alto rendimiento.
El resultado de que haya más gente usando PHP y Ruby que HTML, y además que HTML figure como lenguaje de programación, me parece cuestionable. También me sorprende que Elixir esté por debajo de OCaml. Sí he visto empresas grandes con Elixir, pero hace tiempo que no veo OCaml.
- Puede que esto haya pasado porque muy poca gente elige HTML cuando responde “el lenguaje de programación que uso”.
- Unos compañeros Java de mi primer trabajo estaban tomando en un parque cuando la policía les preguntó a qué se dedicaban, y respondieron “programadores”. El policía contestó: “ah, HTML entonces”.
- Sobre si PHP y Ruby tienen más usuarios que HTML, en mi experiencia había muchísimos más desarrolladores backend/sistemas que frontend (entre 3:1 y 20:1). Depende del tamaño de la empresa, pero si haces solo backend puede que casi nunca toques HTML. Incluso en servicios centrados en web, en realidad hay mucha gente que no toca HTML.
- HTML técnicamente sí es un lenguaje, pero casi nunca se usa por sí solo, así que incluirlo como categoría independiente en una lista es medio inútil.
- Cada quien vive en su propia burbuja; yo todavía pienso que Scala es un lenguaje popular.
Me alegra que Haskell al menos siga apareciendo en el ranking, aunque esté al nivel de LabView, lo cual es un poco impactante. Pero el contenido del artículo en sí no estuvo muy interesante.
- Haskell al menos sí es un lenguaje interesante. También me alegra que Julia, al que le tengo cariño, haya entrado en la lista este año. Eso me da esperanza de que todavía queda espacio para lenguajes divertidos. Después de la colaboración SoC entre Intel y NVIDIA, parece que Python y C++ van a seguir dominando esta lista por mucho tiempo.
- Comparar Haskell con LabView sí se siente bastante injusto.
Me pregunto qué significa “Arduino”. Si estamos hablando del Arduino DIY que todos conocemos, entonces no es un “lenguaje”, sino simplemente C++.
- La documentación de Arduino sí lo llama “Arduino programming language”, pero en la práctica es poco más que C++ con algunos typedef añadidos. No tengo muy claro por qué.
- Es la misma lógica con la que HTML y CSS se clasifican como lenguajes, o con la que librerías de C/Fortran son llamadas librerías de “Python”.
- Esa distinción es rara y le quita credibilidad a la gráfica. Si van a clasificarlo así, entonces habría que sumarle esos puntos a C++.
Yo también me hice una pregunta parecida: si los asistentes LLM (modelos grandes de lenguaje) terminarán fijando los lenguajes de programación actuales. Por lo que he probado, mientras más popular es un lenguaje, mejor se desempeñan los LLM con él, probablemente por la cantidad de datos de entrenamiento. Eso podría hacer todavía más difícil introducir lenguajes nuevos. Si los LLM se hubieran entrenado solo con código orientado a objetos, quizá otros paradigmas ni siquiera habrían tenido oportunidad de desarrollarse como lo hicieron.
- Hace poco estuve trabajando con Hare, que es un lenguaje poco conocido, y Claude me ayudó mejor que un buscador tradicional, aunque también dijo tonterías. Eso me hace pensar que quizá los LLM no vayan a influir tanto en la fijación de lenguajes como uno imaginaría.
- En mi experiencia, los LLM responden mejor para lenguajes populares, pero además repiten innecesariamente respuestas usando lenguajes o herramientas famosas. Y si se lo señalas, corrigen con algo tipo “tienes razón, no es estrictamente necesario. Te daré un ejemplo más claro y apropiado…”. Ojalá hicieran eso desde el inicio, porque el código a menudo queda innecesariamente complejo. Si no eres un desarrollador con experiencia, es difícil filtrar esas cosas, y así ese código raro termina en un repo de git o en producción. A veces hasta da la impresión de que una gran empresa empujó su plugin o su código para que aparezca en la primera respuesta. La estructura misma de esto podría volverse un problema muy serio a futuro. A la industria publicitaria le va a encantar esta tendencia; si empiezan a mezclar anuncios dentro de los modelos LLM, el problema va a ser todavía mayor.
  - Ojalá se vuelvan modelos abiertos, con datos de entrenamiento y pesos claramente publicados, y que se puedan personalizar con un sistema de reproducible build al estilo de Nix.
  - Hace falta una forma de depurar el modelo durante la inferencia, por ejemplo con elementos transparentes como tags.
  - Me pregunto si existe alguna forma de verificación formal para la inferencia del modelo.
- La barrera de entrada para adoptar lenguajes nuevos sí va a subir, pero incluso hoy las razones para usar un lenguaje de nicho suelen ser:
  1. existencia de código base y librerías previas
  2. que se junten especialistas de cierto dominio, nada más. Que un LLM sea fuerte en Java no significa que todo el mundo vaya a usar Java. (La diversión o ponerlo en el CV es otra cosa.)
- Elegir un lenguaje popular siempre ha sido ventajoso para contratar gente y cosas así. Apostar por un lenguaje menos popular siempre fue un riesgo, y eso no ha cambiado.
Me frustra un poco ver a Python en primer lugar. En mi experiencia, fuera de scripts o de armar un PoC por tu cuenta, no me dan ganas de usar Python para mucho más. No me imagino usando Python para código que pase de 1,000 líneas, que lo mantengan varias personas, o que tarde más de unos segundos en ejecutarse. Como Python se volvió el lenguaje base para enseñar a no especialistas en universidades de EE. UU., mucha gente muy capaz contribuye a su ecosistema, y ojalá ese esfuerzo se estuviera yendo a otros lenguajes o a lenguajes compilados más robustos. Recomiendo un lenguaje compilado, con tipado estático y soporte multihilo.
- Totalmente de acuerdo. Yo lo uso solo para scripts. El año pasado intenté meterme en ML, pero odié tanto Python que lo dejé al mes. No entiendo por qué Ruby no es más popular. Como Python se volvió el primer lenguaje por defecto para mucha gente —yo incluido—, de hecho me dan ganas de recomendar Ruby.
- Coincido; Python se siente “blandito”. Los lenguajes compilados con tipado estático que conozco son Rust, C y C++, y todos tienen sus propios defectos. Ojalá existiera un C con el tooling de Rust y un sistema de módulos bien resuelto.
- Hasta la sintaxis me parece floja. No sé si funcione bien, pero no es un lenguaje divertido.

3ae3ae 2025-09-29

JS y TS son casi el mismo lenguaje, así que creo que tendría sentido combinarlos.

beoks 2025-09-29

Es raro que HTML esté incluido en el ranking.

jjpark78 2025-09-29

No puedo creer que Java esté en segundo lugar.

passerby 2025-09-29

Java y C# han sido, antes y ahora, el estándar en los entornos empresariales de servidores web.