Durante más de cuatro décadas, los lenguajes C y C++ han sido la columna vertebral del software moderno. Sistemas operativos, bases de datos, navegadores web y plataformas en la nube se han construido sobre millones de líneas de código escritas en estos lenguajes, valorados por su cercanía al hardware y su rendimiento, pero también temidos por su complejidad y fragilidad.

En ese contexto, la idea de abandonar progresivamente C y C++ (promovida incluso por la Casa Blanca) no es solo una decisión técnica: es un cuestionamiento directo a los cimientos mismos de la industria del software.

Sin embargo, ese cuestionamiento ya no es teórico. En Microsoft, una de las empresas con mayor volumen de código legado en C y C++ del planeta, comienza a consolidarse una apuesta clara por un reemplazo generacional: Rust.

El lenguaje, relativamente joven en comparación con sus predecesores, ha ganado prestigio por ofrecer un equilibrio difícil de lograr: rendimiento de bajo nivel comparable al de C/C++, pero con garantías de seguridad de memoria y concurrencia integradas en el propio diseño del lenguaje.

Y todo la polémica deriva de una publicación en LinkedIn de Galen Hunt, ingeniero distinguido de Microsoft y veterano con casi tres décadas en la empresa:

"Mi objetivo es eliminar cada línea de C y C++ de Microsoft para 2030".

Así de directo fue Hunt en su publicación, donde además anunciaba la búsqueda de un ingeniero principal especializado en Rust para su equipo. La estrategia planteada combina dos elementos clave:

1. Algoritmos de análisis de código a gran escala, capaces de construir grafos complejos que representen dependencias, flujos y estructuras de enormes bases de código.
2. Agentes de IA, guiados por esos algoritmos, que puedan comprender, transformar y reescribir código de manera automatizada.

En Genbeta

Un ascensor roto cambió para siempre el mundo de la programación de software. Sus efectos han llegado hasta la Casa Blanca

Rust como lenguaje del futuro de Microsoft

La elección de Rust no es casual. En los últimos años, Microsoft ha promovido activamente el uso de lenguajes con seguridad de memoria como alternativa al histórico dominio de C y C++. La motivación es clara: décadas de vulnerabilidades críticas (desbordamientos de búfer, uso de memoria liberada, errores de concurrencia) están directamente relacionadas con las libertades (y peligros) de esos lenguajes.

Desde controladores en Windows hasta componentes críticos de Azure, su adopción ha ido en aumento, respaldada públicamente por figuras clave como Mark Russinovich, CTO de Azure, quien ha declarado que la compañía está 'a tope' con Rust.

¿Visión corporativa o ambición personal?

Uno de los puntos más debatidos es si esta iniciativa representa un plan corporativo formal o la visión —ambiciosa, pero individual— de un único equipo de desarrollo dentro de Microsoft. Ciertamente, no existe, por ahora, un anuncio oficial que comprometa a toda la empresa a reescribir todo su código heredado.

Aun así, muchas ideas que nacieron como proyectos de investigación en Microsoft acabaron materializándose en productos reales: en ese sentido, la frontera entre 'proyecto experimental' y 'futura hoja de ruta' resulta deliberadamente difusa. En cualquier caso, la oferta de trabajo publicada por Hunt es para trabajar presencialmente en Redmond, en las propias oficinas de Microsoft.

El desafío de décadas de historia

La magnitud del reto es notable: Microsoft mantiene algunos de los mayores y más antiguos repositorios de código del mundo. Componentes como el kernel de Windows, Office o SQL Server contienen millones de líneas de C y C++ refinadas durante décadas, con comportamientos que, en muchos casos, ya forman parte de la compatibilidad esperada por aplicaciones y usuarios.

Reescribir ese legado plantea riesgos evidentes, desde unos costes de validación y pruebas potencialmente astronómicos, hasta tener que lidiar con complejidades técnicas difíciles de expresar en Rust 'seguro', especialmente en estructuras de datos de bajo nivel comunes en sistemas operativos.

En Genbeta

La "guerra civil" entre desarrolladores de Linux por el enfrentamiento C vs. Rust por fin tiene un (inesperado) ganador: Rust

¿Ingeniería asistida por IA o mero 'vibe coding' a escala?

Otro eje del debate gira en torno al papel real de la inteligencia artificial. Mientras Microsoft presume de revisar cientos de miles de pull requests mensuales con ayuda de IA, muchos desarrolladores dudan de que los modelos actuales estén listos para reescribir sistemas críticos sin supervisión humana exhaustiva.

La IA, señalan los más cautos, puede ser extraordinariamente útil para comprender código heredado, documentarlo y sugerir refactorizaciones. Pero delegarle la reescritura masiva de sistemas complejos sigue pareciendo, para muchos, un experimento de alto riesgo.

Más allá de Microsoft: una señal para la industria

Independientemente de si el objetivo de "cero C/C++ en 2030" se cumple o no, el mensaje es potente. Microsoft está señalando una dirección: menos tolerancia al riesgo estructural del software tradicional y más inversión en lenguajes, herramientas y procesos que integren seguridad desde el diseño.

Para la industria en general, la iniciativa funciona como un laboratorio a gran escala: si una empresa del tamaño de Microsoft logra traducir con éxito partes significativas de su legado a Rust apoyándose en IA, el impacto podría redefinir cómo se aborda la deuda técnica en todo el sector.

Imagen | Marcos Merino mediante IA

En Genbeta | El creador del 'Hola, mundo' y gurú de C ha probado a programar en Rust: "En otro lenguaje serían 5 minutos, con Rust me costó días" 

A sus 83 años, Brian Kernighan —leyenda viva de la informática por su papel fundamental en la creación de Unix en los laboratorios Bell y coautor, junto a Dennis Ritchie, del célebre manual The C Programming Language (1978)— sigue impartiendo clases en Princeton y participando en conferencias donde comparte recuerdos, opiniones y advertencias sobre el mundo del software.

Una de sus intervenciones más recientes ha girado en torno a dos temas muy relacionados con sus creaciones: la conflictiva relación entre los lenguajes C y Rust, además de sobre los cambios experimentados en el ecosistema Unix en las últimas décadas.

Rust frente a C: ¿relevo generacional o hype pasajero?

Uno de los temas más recurrentes en las entrevistas y charlas con Kernighan es la creciente popularidad de Rust, lenguaje diseñado con la seguridad en memoria como bandera y que algunos plantean como sustituto natural de C. Sin embargo, su experiencia personal con Rust dista de ser positiva.

En una sesión de preguntas y respuestas durante el festival Vintage Computer East, Kernighan confesó haber escrito un único programa en Rust… y haberlo vivido como una auténtica tortura.

"Oohhh, Rust. [...] No pude comprender los mecanismos que se requerían para garantizar la seguridad de la memoria, en un programa donde la memoria ni siquiera era un problema".

Según afirma, lo que en C u otros lenguajes le habría tomado cinco minutos, en Rust se convirtió en días de trabajo. Sus críticas fueron claras:

• Complejidad innecesaria: los mecanismos de propiedad, préstamo y tiempos de vida le resultaron confusos e injustificados en contextos donde la memoria no era un problema.
• Rendimiento decepcionante: el compilador era lento, el código generado también y la infraestructura de paquetes le pareció "incomprensiblemente grande y pesada".
• Evolución inestable: se encontró con que la sintaxis había cambiado respecto a la última documentación publicada.

En Genbeta

Qué fue de Brian Kernighan, pionero de la fórmula 'Hola, Mundo!' y leyenda de los primeros tiempos de Unix

Aunque reconoce su escasa práctica con Rust y admite cierto 'cinismo' por su parte, se muestra convencido de que este lenguaje no sustituirá a C en el corto plazo. La razón, explica, es doble: C sigue siendo una herramienta madura con décadas de evolución, y Rust aún necesita consolidarse.

Unix, Linux y el mundo de las distribuciones

Por si no lo habías deducido de su exploración de Rust, Kernighan no se ha quedado anclado en la nostalgia. Si bien en sus charlas recuerda con cariño el ambiente cooperativo y creativo de Bell Labs, pero también reconoce que Microsoft ganó a Unix la batalla durante los años 80 y 90.

Hoy, sin embargo, observa con cierta ironía cómo Unix vive oculto en casi todos los dispositivos modernos: desde macOS e iOS hasta Android. Lo que le resulta frustrante es que, a diferencia de los viejos tiempos, esos sistemas ya no están tan abiertos al usuario técnico:

> “Me irrita que debajo de mi teléfono haya un sistema con el que podría hacer cosas… ¡pero no tengo acceso a él!”

No fue el único tema sobre el que opinó: en lo que respecta las distribuciones de Linux, reconoce usarlas de forma indirecta en su trabajo en Princeton, aunque confiesa no tener una favorita.

Cuando le preguntaron por NixOS (una popular 'distribución inmutable' de Linux) o sobre HolyC (una variante exótica de C creada por el sorprendente Terry Davis), su respuesta fue honesta: simplemente no tiene ni idea de qué son.

Una visión crítica del software actual

Pero si bien no es fan de la nostalgia, tampoco cae en el vicio contrario y, lejos de la reverencia al progreso, Kernighan no duda en ofrecer una visión escéptica sobre el estado del software contemporáneo. Ante la petición de resumir en diez palabras o menos su opinión sobre la industria, no duda en soltar un

> "Mucho de esto apesta".

En Genbeta

El creador del lenguaje C++ terminó siendo programador "por error". Pero tiene varios consejos para los jóvenes del sector

Señala el exceso de complejidad, la falta de estabilidad y la orientación excesiva hacia productos de consumo, alejados del espíritu abierto y experimental que marcó los orígenes de Unix. Y aunque valora avances como Linux o las nuevas herramientas que han ido surgiendo, mantiene que la comercialización ha diluido parte de la esencia colaborativa de la informática.

Entre la IA y los consejos a nuevas generaciones

Otro de los temas que surgió en su charla fue el papel de los modelos de lenguaje y la inteligencia artificial en la programación. Kernighan reconoció, con ironía, que sus pruebas con IA no fueron del todo satisfactorias y que invalidaban un principio que él mismo defendía, que "los programas que escriben programas suelen hacerlo mejor que los humanos".

Aun así, lejos de caer en el pesimismo, ofreció un consejo alentador a los jóvenes programadores:

• La informática seguirá siendo fundamental durante mucho tiempo.
• Lo importante es dedicarse a lo que resulte intrigante y divertido, porque esa motivación asegura tanto aprendizaje como empleabilidad.
• El entusiasmo, más que la moda de un lenguaje, es lo que garantiza una carrera plena.

Imagen | Marcos Merino mediante IA + Wikimedia

En Genbeta | La Casa Blanca pidió a la industria que no programara en C++. Su creador ha respondido de forma tajante 

Hace un par de años, repasábamos quién era Bjarne Stroustrup. Si no te apetece hacer clic (hazlo, está muy interesante) te lo resumimos en pocas palabras: se trata del creador del lenguaje C++, uno de los más usados del mundo desde su lanzamiento en 1985.

Por esas mismas fechas, en una mini (muy mini) vídeoentrevista concedida a la plataforma europea de empleo tecnológico Honeypot.io, desvelaba algo curioso sobre su vocación profesional: que terminó dedicándose a la programación "básicamente por un error".

Y es que, tras hacer la Selectividad, y tener que decidir en qué carrera matricularse, decidió que una de sus materias favoritas —Historia— era "una carrera pésima", aunque podía ser "un buen pasatiempo".

"Entonces elegí matemáticas. Pero mientras estudiaba matemáticas quería hacer algo práctico, algo que tuviera algún atractivo más allá de las matemáticas puras. Y me inscribí en lo que en Dinamarca se llamaba "matemáticas con datalogi". "Datalogi" es la palabra danesa para informática, pero yo entonces no lo sabía [Stroustrup entró en la universidad a finales de los 60], pensaba que era una rama de las matemáticas aplicadas".

"Así que me inscribí en esa asignatura y con el tiempo descubrí dos cosas: una, que no era tan bueno en matemáticas como pensaba, cosa que les sucede a la mayoría de los estudiantes de matemáticas, y que la programación era muy divertida […]. Así que todo comenzó cuando un estudiante ignorante escogió algo que no sabía qué era".

Llegó por error, se quedó porque sabía lo que hacía

Pero, como decíamos, por muy fortuita que fuera su llegada a este campo profesional, ha disfrutado de una larga, productiva y exitosa carrera… así que hace unos meses, en otra (igualmente breve) entrevista para Honeypot.io, Stroustrup aprovechaba para resumir sus consejos, tanto laborales como, en general, para la vida de los aspirantes a programador.

Empieza de manera contundente:

"No te especialices demasiado, no estés demasiado seguro de conocer el futuro".

Ambas frases están, claro, directamente relacionadas. Stroustrup explica a continuación que ha visto a demasiados jóvenes especializarse mucho en un campo y comprobar luego, un par de años más tarde, que quizá no lo habían hecho en el campo correcto… incluso si, efectivamente, sí era el correcto cuando empezaron a estudiar para el mismo.

Y es que la tecnología evoluciona que es una barbaridad. Así que, dicho con otras palabras:

"Sé flexible y recuerda que las carreras y los trabajos son algo a largo plazo".

Porque esos jóvenes que Stroustrup ha visto equivocarse apostando por la especialización "se terminan quemando en el proceso".

Y es que la formación de un programador no sólo ser amplia dentro de su campo…

"Mi propia educación fue bastante amplia: he trabajado con compiladores, con múltiples lenguajes —creo que he llegado a conocer dos docenas de ellos—, con arquitectura de máquinas, con sistemas operativos… y todo ese conjunto de habilidades resultó ser útil".

Pero también debe ser amplia fuera del mismo:

"Me encuentro con un montón de 'geeks junior' que piensan que lo único que importa es la especialidad de la informática: la programación o la inteligencia artificial o los gráficos o algo así. Y, bueno, no es así…".

"Nunca me arrepentí del tiempo que le dediqué a la historia y a las matemáticas. Las matemáticas te agudizan la mente, la historia te da una idea de tus limitaciones y de lo que pasa en el mundo".

En Genbeta

Bill Gates cuenta cómo consiguió convertirse en un gran desarrollador: este es su principal consejo

Y es que, según Stroustrup, cuando te formas básicamente lo que estás construyendo es una 'cartera de aptitudes', y por eso nos interesa que esa cartera tiene que ser lo más amplia posible, para ser capaces de reconocer y aprovechar las muchas oportunidades que se nos presentes.

En Genbeta

Más de 300.000 alumnos han estudiado este curso de Python de pago. Su creador decidió regalarlo y podemos hacerlo gratis

Pero ni siquiera se trata de poder aprovechar opciones laborales fuera de la propia programación, porque, incluso si encuentras el trabajo que buscabas en dicho campo, limitarte a codificar no te permitirá tener impacto en el mundo tecnológico, algo que "muchos nerds caricaturescos olvidan siempre".

"Piensan que si pueden escribir el mejor código, cambiarán el mundo. Pero tienes que ser capaz de escuchar. Tienes que ser capaz de comunicarte con tus futuros usuarios y aprender de ellos. Y tienes que ser capaz de comunicarles tus ideas".

Pero más allá de todo eso, nuestro protagonista cree que, a veces, los que se queman lo hacen sencillamente

"Porque no han pasado suficiente tiempo haciendo amistades y teniendo una vida fuera de la informática. […] Tómate tiempo para tener una vida equilibrada".

Haced caso a Stroustrup, gente. Que sabe de lo que habla.

Una versión anterior de este artículo se publicó en 2024.

Imagen | Marcos Merino mediante IA

En Genbeta | La Casa Blanca pidió a la industria que dejara de usar C/C++. Y están de acuerdo con Google en el lenguaje que debe sustituirlos

En un mundo digitalizado donde la tecnología ya no es una opción, sino el núcleo de la estrategia empresarial, saber programar ha dejado de una habilidad de nicho para convertirse en una competencia fundamental. Según el informe "Estado del Mercado Laboral en España" realizado por Infojobs y Esade, las vacantes en el sector de la informática y las telecomunicaciones se mantienen como las más difíciles de cubrir. Esto obliga a que la formación en esta competencia sea muy importante.

Esta situación se ve reforzada por análisis como el de Randstad, que en su informe sobre tendencias del mercado laboral sitúa a los perfiles tecnológicos y en especial a los desarrolladores de software entre los más buscados y mejor remunerados del país. Y es que hay hueco tanto en las empresas tecnológicas como en otras como la banca, sanidad, industria y más.

Si nos vamos al ámbito internacional, el Foro Económico Mundial en su informe sobre el futuro del empleo, el pensamiento analítico y la alfabetización tecnológica son dos de las competencias más importantes para los trabajadores en los próximos años. Esto hace muy importante que tengamos formación en programación en diferentes lenguajes. Para ello, hay diferentes cursos que se desarrollan online o presencialmente que sentarán las bases en esta disciplina tecnológica.

Aprende las bases de Python

Dentro de los lenguajes más populares de este 2025, el que ocupa el primer puesto es Python, que aumenta su popularidad con respecto a los datos del año pasado. Esto lo convierte en una de las mejores opciones en materia de competitividad para empezar a formarse.

• Curso online de Programador Python: gestionado por Tokio School, esta formación ofrece clases telepresenciales para sentarse las bases de este lenguaje con una duración de 400 horas. El temario se centra primero en las características básicas, para luego centrarse en la programación de objetos, manipulación de datos o POO y métodos aplicados. Tanto el precio como la fecha de inicio se debe consultar con la propia plataforma. Lo encontrarás en Donde Estudiar.

• Curso programación Python de MasterD Davante: una formación que sienta las bases de este lenguaje de programación con cinco módulos online que cubren las bases, las funciones básicas, la programación web, el análisis de datos y también su aplicación en IA. Tiene una duración de 375 horas y el precio se debe consultar con la plataforma. Lo encontrarás en Donde Estudiar.
• Introducción a la programación en Python I: con una duración de 17 horas, este curso de la Universidad Católica de Chile trata de dar un repaso muy superficial por Python. Cuenta con seis módulos como las instrucciones básicas, el control de flujo, las funciones o las listas. El precio es gratuito, con inscripción inmediata (aunque para obtener el título sí que se deberá abonar una pequeña cuota). Lo encontrarás en Coursera.

Cursos de C++

Si seguimos el mismo ránking al que hemos hecho referencia antes, encontramos a C++ como el segundo lenguaje de programación más usado.

• Codificación para todos: C y C++. Con una duración de cuarenta horas, este curso de la UC Santa Cruz permite adquirir los conocimientos básicos tanto de C como C++ y comprender los algoritmos. Cuenta con cinco módulos diferentes que empieza escribiendo un programa sencillo, usar construcciones sencillas, convertir programas C a C++... La inscripción es gratuita (el título si se debe abonar) y te puedes inscribir desde hoy mismo. Lo encontrarás en Coursera.
• Programming in C++: A Hands-on Introduction. Pese a estar en inglés, este curso sienta unas buenas bases para empezar a programar con estructuras básicas de C++ (vectores, punteros, cadenas...), conceptos básicos (funciones, objetos...) y también da una pasada por C++ orientado a objetos. La inscripción es gratuita (el título si se debe abonar) y te puedes inscribir desde hoy mismo. Lo encontrarás en Coursera.
• C, Go y C++: una introducción completa a la programación. Este curso aglutina diferentes lenguajes de programación en seis módulos diferentes y 80 horas de formación. Hay dos módulos por cada uno de los lenguajes, donde se hace una introducción a cómo escribir código básico. La inscripción es completamente gratuita. Lo encontrarás en Coursera.

En Genbeta

El curso gratis online más famoso para aprender a programar acaba de empezar y aún puedes apuntarte: de Harvard y con certificado

Cursos centrados en Java

Java es uno de los lenguajes más clásicos en este sector, y también el tercero más popular entre los programadores. Además, también es un lenguaje fácil de aprender y manejable a la hora de escribir, compilar y depurar código.

• Curso de Java: formación gestionada por SEAS y con una duración de 150 horas completamente online. Para ello se divide en tres módulos diferentes, que empieza con una introducción donde se recogen las funciones, estructuras de control, paquetes... Sigue con un paso por la programación orientada a objetos y termina con un repaso a las interfaces gráficas. Tanto el precio como el inicio del curso se deben consultar a la organización. Lo encontrarás en Donde Estudiar.
• Programación con Java Certificación OCP: confeccionado por Tokio School, este curso tiene una duración de 400 horas y es completamente online. Cuenta con 10 módulos diferentes que se centran en los conceptos básicos, uso de interfaces, arquitectura MVC, desarrollo de proyectos, APIs, depuración de error y entorno de red. El precio se tendrá que consultar en el momento de la matrícula. Lo encontrarás en Donde Estudiar.
• Web Coding con JavaScript: con el título "aprende el lenguaje de programación web más versátil", esta formación cuenta con una duración de tres semanas a 20 minutos por día. Las diferentes sesiones se centran en los fundamentos, los controles de flujos y arrays, las funciones y DOM. Detallan que es importante contar con conocimientos de HTML y CSS para seguir el curso. Tiene un precio de 149 euros y empieza el 21 de julio de 2025. Lo encontrarás en The Valley.

Cursos centrados en programación web

En lugar de centrarse en cada uno de los lenguajes por separado, hay opciones de formación que son mucho más generales y que en su mayoría son considerados como máster en programación. Una serie de estos son:

• Máster en Full Stack Developer: este es un título propio de UNIR que promete convertirte en un experto en proyectos web en solo seis meses. Cuenta con una duración de 1.500 horas online, lo que corresponde a 60 ECTS. Hace un repaso por todo lo necesario para crear una web como Vanilla JS, MySQL, CSS, HTML y más. El precio y el inicio del curso se tiene que consultar directamente con UNIR. Lo encontrarás en Donde Estudiar.
• Máster en Desarrollo de Aplicaciones y Servicios Web: un título ofrecido por la VIU con un plan de estudios centrado en el perfil de ingeniero Web Full Stack con una duración de 1.500 horas con clases en directo. Se hará un repaso de bases de datos web, seguridad, análisis de datos, gestión de proyectos o la programación en dispositivos móviles. El precio y la fecha de inicio se deberá consultar con la universidad. Lo encontrarás en Donde Estudiar.
• Máster de Desarrollo de Sitios y Aplicaciones Web: gestionado por la UOC, este título cuenta con 1.500 horas de formación y un precio de 3.184 euros. Se ofrece formación en HTML, CSS, diseño de interfaces o JavaScript. Lo encontrarás en Donde Estudiar.
• Web Coding Básico: este es un curso más liviano para poder aprender a crear páginas web con HTML y CSS desde cero y 100% online. Tiene una duración de tres semanas con un desempeño de 20 minutos por día. Arranca el próximo 21 de julio y tiene un precio de 149 euros. Lo encontrarás en The Valley.

Imágenes | Florian Olivo James Harrison

En Genbeta | Esta es la guía definitiva para aprender a programar gratis: ofrece miles de libros en español y en inglés

En el último mes, coincidiendo con el retorno de Donald Trump, la Casa Blanca ha dado un giro en muchas de sus políticas de los últimos cuatro años... pero hay una, relativa al ámbito tecnológico, de la que no hemos oído por ahora que tengan intención de rectificar...

...hablamos del muy comentado llamamiento a la industria tecnológica para abandonar el uso de los históricos lenguajes de programación C/C++ en favor de nuevos 'lenguajes seguros'.

El documento, publicado por la Administración de Seguridad Cibernética y de Infraestructura de Estados Unidos (CISA) hace ya más de un año, no concretaba a qué lenguajes seguros se refería... con una única excepción 'a título de ejemplo': el popular (pero cada vez más polémico) Rust.

La joven estrella contra la vieja guardia

Desde su creación, C y C++ han sido los pilares de la industria del software, formando la base de sistemas operativos, así como de infraestructura crítica y aplicaciones de alto rendimiento (es decir, de software que el usuario doméstico nunca llegará a utilizar, pero cuyas vulnerabilidades sí terminará sufriendo).

Sin embargo, su flexibilidad y potencia han venido acompañadas de una serie de riesgos de seguridad difíciles de mitigar, especialmente en lo que respecta a errores de gestión de memoria, como desbordamientos de búfer y 'uso de memoria después de liberación'.

En Genbeta

La Casa Blanca pidió a la industria que no programara en C++. Su creador ha respondido de forma tajante

Por otro lado, desde su creación en 2010 (el lenguaje C data de 1972), Rust ha ganado notoriedad por su capacidad de ofrecer seguridad en la gestión de memoria sin sacrificar el rendimiento.

Diseñado desde sus inicios con un enfoque en la seguridad y la concurrencia, Rust utiliza un mecanismo que previene errores comunes de memoria en tiempo de compilación, eliminando así una gran cantidad de vulnerabilidades explotables.

Grandes corporaciones tecnológicas como Microsoft, Google y Amazon llevan ya un tiempo experimentando con Rust en diversos proyectos, y reconocen haber experimentado mejoras significativas en seguridad y estabilidad.

Incluso el equipo desarrollador del kernel de Linux comenzó hace un tiempo a integrar soporte para Rust de manera experimental, lo que hizo que muchos se lanzasen a anunciar un cambio de paradigma en la programación de bajo nivel.

Un anuncio algo apresurado, viendo lo que ha pasado después.

Linux: sólo la punta del iceberg del futuro de la industria

Decía Antonio Gramsci que las crisis políticas consisten en que "lo viejo está muriendo y lo nuevo no termina de nacer". Thomas Kuhn, sobre las 'verdades científicas', decía que "no triunfan  convenciendo a sus oponentes y haciéndoles ver la luz, sino esperando a que mueran y a que llegue una nueva generación" favorable a la nueva 'verdad'.

Bueno, pues con Linux está pasando un poco eso: aunque nominalmente hay en marcha un celebrado proyecto para integrar soporte para Rust, dentro de la comunidad de desarrolladores, ha surgido una división entre los entusiastas (pero minoritarios) defensores de Rust y los 'tradicionalistas' que consideran que C sigue siendo la mejor opción para el núcleo del sistema operativo.

En Genbeta

El kernel de Linux lleva desarrollándose 34 años. Un debate sobre lenguajes de programación está logrando intoxicar el proyecto

Linus Torvalds, creador de Linux, ha mostrado una actitud ante este debate que ha ido deslizándose desde lo cauteloso (reconociendo que ve potencial en el lenguaje, pero que la transición debe ser gradual) hacia lo sesgado (criticando con duras palabras a desarrolladores que denunciaban el sabotaje interno a Rust).

Y es que la adopción de Rust ha generado tal polémica dentro de la comunidad que algunos desarrolladores terminaron llevando el debate a las redes sociales. La reprimenda de Torvalds ya se ha traducido en una dimisión muy sonada en el bando pro-Rust, dentro del cual cunde la sensación de que su batalla está perdida dentro del equipo del kernel.

¿Qué significa esto para la industria del software?

El llamamiento de la Casa Blanca no fue una mera sugerencia: afectará (aunque no a corto plazo) a su política de contratación de proveedores y es, en general, es una señal clara de que la seguridad en la infraestructura digital es una prioridad a nivel gubernamental. Es muy poco probable que C y C++ se conviertan en minoritarios a corto plazo, pero la presión por adoptar Rust y otros lenguajes seguros va a seguir creciendo de manera constante.

Imagen | Marcos Merino mediante IA

En Genbeta | Usar Rust en Linux está siendo muy polémico. En Android ya se han demostrado sus grandes virtudes reduciendo bugs

En el mundo del desarrollo de software, las vulnerabilidades de memoria siguen siendo una de las principales amenazas para la seguridad informática. A pesar de los avances en la creación de lenguajes de programación más seguros, gran parte del software crítico aún depende de tecnologías con décadas de antigüedad, como C y C++.

Pero, aunque éstos han sido la columna vertebral de muchos sistemas informáticos modernos, su gestión manual de memoria los hace propensos a errores que pueden ser aprovechados por atacantes.

Debido a estos peligros, los Estados Unidos se han tomado la programación es una cuestión de seguridad nacional: hace un año, la Oficina del Director Nacional de Ciberseguridad (ONCD) de los EE.UU. emitía un informe instando a los programadores a migrar hacia 'lenguajes de programación seguros en memoria' con el objetivo de evitar vulnerabilidades que pudieran comprometer datos sensibles y afectar infraestructuras nacionales.

Sin embargo, la adopción de estos 'lenguajes seguros' se enfrenta obstáculos importantes: la realidad es que una gran cantidad de software crítico ya está escrito en C y C++, y su migración completa a lenguajes seguros no es siempre viable a corto plazo.

En Genbeta

La Casa Blanca pidió a la industria que no programara en C++. Su creador ha respondido de forma tajante

El desafío de reemplazar C y C++ con Rust

Rust ha sido promocionado como una solución para reducir la 'superficie de ataque' del software crítico. Sin embargo, la transición no es sencilla: la mayoría de los sistemas operativos, compiladores, servidores DNS, proxies inversos y software criptográfico siguen estando escritos en C/C++.

Además, está el problema de la falta de formación: empresas y universidades continúan formando a programadores en estos lenguajes, ya que dominar C/C++ sigue siendo una habilidad altamente demandada en la industria...

...y la mayoría de los desarrolladores que han trabajado con C y C++ durante años no están dispuestos a aprender un nuevo lenguaje desde cero, ya que esto implica una curva de aprendizaje significativa.

Por otra parte, el debate sobre Rust ha recordado a muchos expertos la advertencia de Joel Spolsky, fundador de Stack Overflow, sobre que reescribir un código base desde cero es una de las peores decisiones que puede tomar una empresa: perder años de optimización y corrección de errores para empezar desde cero con una nueva tecnología puede resultar contraproducente.

Pasito a paso

Ante este panorama, la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos (CISA) ha actualizado hace un par de semanas sus recomendaciones sobre prácticas inseguras en el desarrollo de software, estableciendo un nuevo enfoque gradual para la migración a lenguajes más seguros.

CISA reconoce que la transición hacia lenguajes seguros no es una tarea sencilla: reconoce explícitamente que muchas compañías han construido sus productos en lenguajes como C y C++ durante décadas, y reescribir millones de líneas de código de un día para otro es prácticamente imposible.

Por ello, la agencia ha propuesto un modelo de migración progresiva, que permite a los fabricantes mejorar la seguridad de sus productos sin comprometer su estabilidad o funcionalidad. Este enfoque consta de tres fases clave:

1. A corto plazo: Implementar controles en hardware o compiladores para reducir los errores de gestión de memoria sin necesidad de modificar el código existente, y aplicar técnicas para mitigar vulnerabilidades de memoria en tiempo de ejecución.
2. A medio plazo: Asegurar que todo nuevo código se desarrolle en lenguajes seguros, como Rust o Go, y mejorar las prácticas de codificación en lenguajes inseguros, minimizando el uso de funciones propensas a errores como 'strcpy' o 'malloc' sin verificaciones adecuadas.
3. A largo plazo: Reescribir progresivamente módulos críticos en lenguajes seguros para la memoria, y priorizar la conversión de componentes altamente expuestos a ataques, como aquellos responsables de comunicaciones en red, autenticación y cifrado.

En Genbeta

Usar Rust en Linux está siendo muy polémico. En Android ya se han demostrado sus grandes virtudes reduciendo bugs

Hojas de ruta

Uno de los cambios más relevantes en las recomendaciones de CISA es la exigencia de que los proveedores de software publiquen una hoja de ruta clara y accesible sobre cómo planean abordar los riesgos de seguridad de memoria en sus productos. Este documento debe incluir:

• Un plan de mitigación de vulnerabilidades en componentes críticos del código, como aquellos expuestos a redes o responsables de operaciones criptográficas.
• Una estrategia de eliminación progresiva del uso de lenguajes inseguros, asegurando que nuevos desarrollos se realicen en entornos más seguros.
• Pruebas de compromiso con la seguridad, demostrando que la empresa está implementando medidas concretas para reducir estos riesgos.

CISA ha establecido que los fabricantes que no cuenten con esta hoja de ruta antes de 2026 estarán incurriendo en una práctica de seguridad inaceptable. No obstante, la agencia ha aclarado que esta obligación no se aplicará a productos cuyo soporte finalice antes de 2030, permitiendo que la industria haga la transición de manera ordenada y sin afectar el mantenimiento de productos en fase final de vida útil.

Imagen | Marcos Merino mediante IA

En Genbeta | El kernel de Linux lleva desarrollándose 34 años. Un debate sobre lenguajes de programación está logrando intoxicar el proyecto

El desarrollo del kernel de Linux ha sido, históricamente, un ecosistema en constante cambio, en el que Linus Torvalds (creador, y líder de su equipo de desarrolladores) ha ido tomando decisiones que han permitido que el sistema operativo fuera progresando hasta su estado actual.

Sin embargo, ahora las cosas parecen haberse 'gripado' un poco en el kernel de Linux. De todas las cosas que se habían tocado en el mismo, el lenguaje en el que está escrito nunca había estado en la lista.

Pero ahora, la (supuestamente aprobada, aunque nadie lo diría) propuesta de integrar Rust como un segundo lenguaje de desarrollo, no sólo ha generado un profundo debate entre desarrolladores, sino que parece haberlo sembrado de minas.

Desde su propuesta en 2021 por Miguel Ojeda hasta las recientes dimisiones de ingenieros clave, la controversia en torno a Rust ha alcanzado un punto crítico tras la dimisión de Héctor Martín, desarrollador de Asahi Linux. Ya os hablamos hace un par de días del propio Martín, pero ¿cómo le está afectando todo esto al ecosistema Linux?

¿De dónde venimos?

Rust es un lenguaje de programación diseñado para evitar errores de memoria y mejorar la seguridad en la concurrencia. Estas características suelen ser altamente valoradas en el desarrollo de sistemas críticos (como lo es el kernel de Linux), donde los errores de memoria pueden generar vulnerabilidades explotables.

En abril de 2021, Miguel Ojeda propuso un RFC (Request for Comments) para integrar Rust en el kernel. La idea central era que Rust se utilizara, al menos inicialmente, en el desarrollo de drivers, sin que eso supusiera reemplazar el código base en C.

En Genbeta

Máxima tensión entre desarrolladores de Linux por el enfrentamiento C vs. Rust: Linus Torvalds ve un "tono casi religioso" en el debate

Sin embargo, la propuesta también encontró resistencia por diversas razones:

• Curva de aprendizaje: Los mantenedores de código tendrían que aprender Rust para poder mantener y depurar el código.
• Impacto en el rendimiento: Los "wrappers" necesarios para la interoperabilidad con C podrían afectar el rendimiento.
• Carga de mantenimiento: La coexistencia de dos lenguajes dentro del kernel podría generar problemas a largo plazo.
• Compatibilidad con el modelo de memoria de Linux: Rust utiliza el modelo C11 de LLVM, diferente al del kernel de Linux, lo que plantea problemas de integración.

A cara de perro

A medida que avanzaban los debates, la comunidad de desarrolladores se dividió en dos grupos:

1. Los defensores de Rust, entre ellos empresas tecnológicas como Google y Microsoft, que argumentan que la adopción de Rust mejorará la seguridad del kernel.
2. Los opositores a Rust, encabezados por mantenedores clave, quienes ven la introducción de un segundo lenguaje como un obstáculo para la estabilidad y mantenimiento del código.

Uno de los puntos más problemáticos ha sido la aparente resistencia de algunos desarrolladores a aceptar código escrito en Rust, incluso después de que se diera oficialmente luz verde a la integración en el kernel de este nuevo lenguaje.

Así, se han reportado casos de ignorancia deliberada de parches, lentitud extrema en las revisiones y críticas agresivas a los desarrolladores de Rust. Un ejemplo notable es el de Christoph Hellwig, quien ha rechazado rotundamente la inclusión de Rust en su área de desarrollo, refiriéndose a este como "un cáncer que no debe propagarse al 'core' del kernel".

Esta actitud ha sido vista por algunos como una demostración de cierto sesgo por parte de Torvalds y el resto de líderes del proyecto, sobre todo teniendo en cuenta que, mientras otros desarrolladores han sido sancionados por "lenguaje inapropiado", Hellwig no ha recibido reprimenda alguna.

Un espectáculo lamentable

Uno de los acontecimientos más significativos de esta crisis ha sido la dimisión de Wedson Almeida Filho, ingeniero de Microsoft y uno de los principales impulsores de Rust en el kernel. Wedson renunció hace cinco meses, tras años de esfuerzo por integrar Rust, afirmando que el problema no era técnico, sino humano. Su salida fue seguida por declaraciones de apoyo de Lina, VRtuber y desarrolladora de Asahi Linux, que afirmó sentirse igual de frustrada por la actitud hostil de la comunidad.

Otros desarrolladores, como Greg Wettstein, también han expresado su descontento con la falta de liderazgo en el tema: describió el conflicto como "un espectáculo lamentable" y criticó la pasividad de Linus Torvalds a la hora de gestionar este problema.

En Genbeta

Usar Rust en Linux está siendo muy polémico. En Android ya se han demostrado sus grandes virtudes reduciendo bugs

La (no) respuesta de Linus Torvalds

Y es que Linus Torvalds, creador de Linux y máxima autoridad en su desarrollo, ha mantenido una postura ambigua respecto a Rust: su comentario "on the whole I don't hate it" ("en general, no lo odio") ha sido interpretado de maneras muy distintas a ambos lados del debate.

Torvalds se encuentra en una encrucijada: si apoya Rust, podría poner en su contra a veteranos mantenedores de código que se oponen firmemente a la idea; si lo rechaza, decepcionará a las empresas y desarrolladores que han invertido tiempo y recursos en la iniciativa.

Esta indecisión ha generado incertidumbre, permitiendo que el conflicto escale sin una resolución definitiva y contribuido a la salida de varios desarrolladores. En definitiva, ha generado un ambiente de innecesaria tensión dentro de la comunidad.

Ya sabemos de dónde venimos. ¿Y ahora? ¿A dónde vamos?

La controversia ha demostrado que la integración de nuevas tecnologías en un proyecto tan grande y antiguo como Linux no es un proceso sencillo. Sin un liderazgo claro y una resolución firme, la comunidad se arriesga a seguir perdiendo talento.

Si bien Rust ofrece beneficios en términos de seguridad, la forma en que se ha manejado su adopción ha dejado mucho que desear. La falta de un consenso claro y la resistencia de algunos sectores (llegados a este punto, nadie parece muy dispuesto a transigir) podrían traducirse en el fracaso de esta iniciativa.

Una cosa es segura: lo que ocurra en los próximos meses podría definir no solo el futuro del uso de Rust en el kernel, sino también la cultura de desarrollo de uno de los proyectos de software libre más importantes del mundo.

Imagen  | Marcos Merino mediante IA

En Genbeta | Rust parecía el lenguaje ideal para programar videojuegos. Este estudio acabó abandonándolo tras tres años centrados en él

George Hotz, conocido mundialmente por ser el hacker que desbloqueó el iPhone a los 17 años y que más tarde descifró la seguridad de la PlayStation 3, es también un prolífico desarrollador y empresario. Sus opiniones sobre programación y el funcionamiento de los sistemas informáticos no pasa desapercibida, y en un reciente vídeo, Hotz compartió una contundente:

"Todo el mundo debería aprender ensamblador y C", afirma Hotz. Su argumento central es que, sin un conocimiento básico del lenguaje ensamblador, no es posible comprender cómo funcionan realmente los ordenadores:

"No necesitas ser un experto en ensamblador, pero debes saber programar con él".

El ensamblador, según Hotz, proporciona una visión directa de lo que sucede en el hardware, mientras que C, como lenguaje de programación de bajo nivel, permite valorar todas las abstracciones que ofrecen lenguajes más modernos como Python.

Hotz explica que el ensamblador enseña los fundamentos de la memoria y las instrucciones que operan en el hardware, mientras que C enseña a gestionar la memoria y trabajar con un compilador.

"C hace que te hagas una idea sobre cómo funciona un compilador y cómo asigna los registros".

En Genbeta

Hay quien opina que C ya no es un lenguaje de programación (otros se conforman con decir que no es un lenguaje de bajo nivel)

Pero el camino no termina en C. Hotz sostiene que después de aprender C, es necesario aprender Python, porque sólo así se pueden apreciar las ventajas de un lenguaje de programación de alto nivel (si bien esta opinión es bastante menos impopular que lo afirmado antes):

"Ensamblador, C y Python están apilados uno sobre otro".

Aprender otros paradigmas: funcional, hardware y machine learning

George Hotz no se limita a recomendar ensamblador, C y Python. También sugiere explorar otros paradigmas de programación que son esenciales para convertirse en un programador completo.

1. Paradigma funcional: Hotz recomienda aprender Haskell, un lenguaje de programación funcional, y llegar hasta lenguajes con tipos dependientes, como Coq: "Es importante aprender estos lenguajes porque son muy teóricos y permiten desarrollar una comprensión profunda de la teoría de lenguajes de programación".
2. Hardware y Verilog: Otro paradigma que Hotz destaca es el que se relaciona con el diseño de hardware. Aquí menciona Verilog, un lenguaje de descripción de hardware (HDL), que se diferencia fundamentalmente de los lenguajes secuenciales. "En Verilog, todas las instrucciones se ejecutan al mismo tiempo", explica. Aprender Verilog, según Hotz, permite entender cómo funciona el hardware a nivel básico, algo que ni siquiera el ensamblador puede mostrar completamente.
3. Machine Learning y PyTorch: Finalmente, Hotz menciona un cuarto paradigma emergente, el de la programación impulsada por datos. En este campo, recomienda aprender PyTorch en lugar de TensorFlow. Hotz sugiere que el aprendizaje de máquina requiere un conjunto de habilidades completamente nuevo, que se aleja de los paradigmas tradicionales de la programación.

En Genbeta

El creador del lenguaje C++ terminó siendo programador "por error". Pero tiene varios consejos para los jóvenes del sector

La conclusión de George Hotz es clara: para entender verdaderamente la computación, es imprescindible comenzar desde el nivel más bajo y avanzar hacia lo más abstracto. Para él, el futuro de la programación no consiste en dominar un único lenguaje o paradigma, sino en combinar las fortalezas de todos ellos.

George Hotz y su paso por Twitter

La opinión de George Hotz tiene un peso significativo en la industria tecnológica. No es casualidad que Elon Musk le contratase para colaborar en la solución de problemas críticos en Twitter (ahora X). Hotz trabajó brevemente en la plataforma, enfocándose en optimizar funciones y solventar problemas técnicos complejos, una tarea que, según muchos, sólo alguien con su nivel de conocimientos podría abordar.

Imagen | Marcos Merino mediante IA

En Genbeta | No sabía cómo funcionan por dentro las CPU, así que este programador simuló una usando sólo código

Uno de los debates más candentes ahora mismo en el mundo del desarrollo de software gira en torno a los dos lenguajes que permiten dar forma al kernel de Linux: el venerable C y el prometedor Rust. Por supuesto, el enfrentamiento entre ambos no ha surgido en el seno del famoso proyecto de software libre... pero está empezando a pasarle factura a este último.

Por ello, Linus Torvalds, creador de Linux y responsable del mantenimiento de su kernel, quiso abordar el asunto hace unos días y definió la creciente tensión entre los desarrolladores de C y Rust como una controversia "casi con tonos de guerra religiosa".

Pero, ¿por qué se ha planteado realmente en este debate? ¿Es solo una cuestión técnica, o hay factores culturales más profundos que alimentan esta disputa?

El origen del conflicto

La inclusión de Rust como lenguaje de desarrollo en el kernel de Linux fue una iniciativa que se puso en marcha hace más de tres años, impulsada por los apoyos con que contaba este nuevo lenguaje a causa de sus ventajas en términos de seguridad de memoria. Sin embargo, lo que comenzó como un debate técnico rápidamente se transformó en un choque cultural.

Torvalds ha comparado este conflicto con las antiguas "guerras de editores" entre Vi y Emacs, donde las preferencias por herramientas se convirtieron en cuestiones casi de 'nacionalismo de software' (mis palabras, no las de Linus) para los desarrolladores.

"Creo que realmente lo disfruto. Disfruto de las discusiones. Creo que una de las cosas buenas de Rust ha sido cómo ha animado algunas de las discusiones, y algunas de las discusiones se vuelvan desagradables... creo que es una demostración cuánto le importa el tema a la gente. Por otra parte, no estoy muy seguro de por qué Rust ha sido un asunto tan polémico [...] por alguna razón, toda la discusión de Rust versus C ha tomado connotaciones casi religiosas en ciertas áreas".

En Genbeta

La Casa Blanca pidió a la industria que no programara en C++. Su creador ha respondido de forma tajante

El conflicto reciente estalló hace unos días, cuando uno de los mantenedores del kernel abandonó el proyecto tras varias discusiones relacionadas con la adaptación de un complemento de C para Rust. El español Miguel Ojeda era el máximo responsable de la integración de Rust en Linux, y su dimisión no hace sino resaltar el impacto de este debate. Se despedía con un e-mail que venía a decir cosas como esta:

"Me retiro del proyecto. Después de casi cuatro años, me falta la energía y el entusiasmo que tenía antes para responder a ciertas tonterías no-técnicas, así que es mejor dejarlo en manos de quienes aún lo tienen".

"Al equipo de Rust para Linux: gracias, sois geniales. Fue un placer trabajar con todos vosotros; los momentos que pasamos discutiendo cuestiones técnicas, buscando formas de solucionar problemas de solidez, etc., fueron algo que siempre disfruté y esperé con ansias. Me considero afortunado de haber colaborado con un grupo tan talentoso y amistoso".

"Deseo mucho éxito al proyecto. Creo sinceramente que el futuro de los núcleos está en los lenguajes que protegen la memoria. No soy ningún visionario, pero si Linux no lo internaliza, me temo que algún otro núcleo le hará lo mismo que le hizo a Unix".

Es decir, lo barrerá del mapa convirtiéndose en su heredero. Ya hay gente intentándolo.

Las razones de ambos bandos

A nivel técnico, las diferencias entre C y Rust son sustanciales. C, desarrollado en la década de 1970, es un lenguaje que ha sido fundamental para el desarrollo de sistemas operativos debido a su control total sobre los recursos de la máquina. No obstante, esa simplicidad también hace que se lo considere propenso a errores peligrosos como desbordamientos de memoria y fallos de seguridad que pueden ser explotados.

Por otro lado, Rust ha sido diseñado desde sus cimientos para prevenir estos problemas a través de su modelo de seguridad de memoria, lo que lo convierte en un fuerte candidato para sustituir a C en algunas áreas críticas del kernel de Linux. 

Sin embargo, Rust también ofrece una barrera de entrada más alta: es más difícil de aprender y dominar en comparación con C, lo que ha generado resistencia entre los desarrolladores que llevan décadas trabajando con C. Muchos desarrolladores de este lenguaje sienten que su territorio está siendo invadido por un lenguaje que, aunque más seguro, aún no ha demostrado completamente su capacidad para reemplazar a C en sistemas operativos de misión crítica.

A pesar de las claras ventajas de Rust en cuanto a seguridad, Torvalds ha dejado claro que esto no son suficientes para convertirlo automáticamente en el lenguaje dominante dentro del desarrollo del kernel. Sin embargo, y a pesar de las resistencias, Torvalds sigue siendo optimista en lo que respecta a la integración de Rust en el kernel de Linux, y afirma que incluso si la experimentación con Rust no tuviera éxito, es una oportunidad de aprendizaje valiosa.

Vía | The New Stack

Imagen | Marcos Merino mediante IA

En Genbeta | Hay quien opina que C ya no es un lenguaje de programación (otros se conforman con decir que no es un lenguaje de bajo nivel)

Aria Beingessner fue en su momento integrante de los equipos responsables de implementar los lenguajes Rust y Swift, de modo que su opinión sobre el desarrollo de software no es una que podamos descartar sin más miramientos, ni siquiera cuando sostiene en su blog una teoría tan controvertida como la de que "el lenguaje C ya no es un lenguaje de programación".

En primer lugar, acusa a C de fragmentación ("C está en realidad horriblemente mal definido debido a sus mil millones de implementaciones") y de tener "una jerarquía de enteros totalmente fallida"; esto último se refiere a que, según el modelo de datos usado —LP32 para Win16, ILP32 para Win32 y Unix 32 bits, LLP64 para Win64 o LP64 para Unix 64 bits— el valor de enteros varía, pudiendo traducirse en datos 'int' de 16 o 32 bits, datos 'long' de 32 o 64 bits, equivalencias entre int y long o entre long y pointer, etc).

Sin embargo, para Beingessner ambos detalles son meramente accesorios: no es en eso donde reside su principal preocupación…

Una 'lingua franca' que limita a las nativas

"Mi problema es que, como C ha sido elevado a una posición de prestigio, su reinado ha resultado ser tan absoluto y eterno que ha terminado distorsionando por completo la forma en que nos hablamos entre nosotros. Rust y Swift no pueden limitarse a usar sus lenguajes, nativos y cómodas… sino que deben envolverse en un grotesco disfraz de la piel de C y hacer que su carne ondule de la misma manera que éste lo hace".

A lo que Beingessner se refiere aquí, en su florido lenguaje, es al hecho de que C no es un mero lenguaje de programación porque se ha convertido en algo más que eso: en un "protocolo", uno que "todo lenguaje de programación de propósito general necesita hablar".

En Genbeta

Nueve webs y canales de YouTube para aprender C desde cero hasta nivel experto

Es decir, cualquier lenguaje que desee acceder a la entrada de datos del usuario, escribir en la salida del sistema, manipular ficheros, etc… necesita interactuar con la interfaz de su sistema operativo. Y para ello, dado que la mayoría de sistemas operativos está desarrollado en C, cada lenguaje se ve forzado a llamar a las API de C a través de las interfaces de funciones foráneas.

En definitiva, que incluso si nunca jamás en nuestra vida llegamos a escribir código C, un desarrollador deberá manejar variables C, hacer coincidir estructuras y diseños de datos con los de C, etc. Y no sólo al comunicar el software con el sistema operativo: también al intentar comunicar dos programas entre sí.

"C es la 'lingua franca' de la programación".

En realidad, este papel de C visto como 'API' del resto de lenguajes de programación está muy relacionado con declaraciones recientes de Bjarne Stroustrup (creador de C++) sobre cómo los 'lenguajes de programación seguros' que buscan sustituir a C/C++... en realidad siguen dependiendo de ellos.

Y aunque fuera un lenguaje de programación, no sería de bajo nivel

Además, si somos precisos, aunque no coincidamos con la opinión de Beingessner, tampoco podemos considerar a C un lenguaje de programación de bajo nivel, que es como se le ha categorizado toda la vida.

Un lenguaje de bajo nivel es aquel que está 'cerca del hardware', en el que sus instrucciones vienen condicionadas por la estructura física de los computadores que lo ejecutan. Pero C se desarrolló en los años 70 con la mente puesta en las gigantescas computadoras PDP-11, no en nuestros pequeños equipos Intel o ARM.

Tal y como recoge este paper de 2018 publicado por la Association for Computing Machinery (titulado, precisamente, "C no es un lenguaje de programación de bajo nivel"),

"La causa originaria de las vulnerabilidades Spectre y Meltdown radica en que los arquitectos de procesadores no estaban tratando de construir procesadores rápidos, sino procesadores rápidos que exponen la misma máquina abstracta que un PDP-11. Esto es esencial porque permite a los programadores de C seguir creyendo que su lenguaje está cerca del hardware subyacente".

"[…] Tal vez sea hora de dejar de intentar que el código C se ejecute rápido, y en su lugar pensar en cómo se podrían ser los modelos de programación de un procesador diseñado para ser rápido".

Una versión anterior de este artículo fue publicada en 2022.

Imagen | Pixabay

En Genbeta | Presentan el lenguaje Hare, "ideal para crear sistemas operativos": sus creadores buscan sustituir a C simplificándolo