En este episodio del podcast "Hablemos de Rust", los tres anfitriones discuten de forma informal y didáctica la historia y evolución del lenguaje de programación Rust. Comienzan explicando el concepto de BDFL (Benevolent Dictator for Life) y citan ejemplos como Guido van Rossum (Python) y Linus Torvalds (Linux). Se centra en Graydon Hoare, creador de Rust, y su motivación surgida en 2006 mientras trabajaba en Mozilla, donde un fallo de gestión de memoria en un ascensor lo impulsó a diseñar un lenguaje que evitara esos errores. Se describen los primeros años del proyecto, los cambios drásticos de versiones pre‑1.0 (modificaciones de tipos, eliminación de recolección de basura, etc.) y la confusión que provocaron en la comunidad. Los anfitriones explican el versionado semántico (mayor, menor, parche) y cómo Rust a veces rompía compatibilidad incluso en versiones menores. Se menciona la publicación de la versión estable 1.0 en 2015 y la influencia de un artículo de Andrew Binstock que posicionó a Rust como competidor de C++. Después, se relata la creación de la Rust Foundation en 2020 tras los recortes de Mozilla, con apoyo de grandes empresas (AWS, Google, Microsoft, Huawei). Finalmente, comparan Rust con Go, discuten su adopción en proyectos como Linux y Firefox/Servo, y reflexionan sobre si Rust podrá sustituir a C++ en el futuro. El episodio incluye llamadas a la audiencia para suscribirse y apoyar el canal.
Chapters
¿Sabías que el creador de Rust es un dictador?
¿Cómo que un dictador?
Sí, pero no del tipo de dictadores que estáis pensando.
Hmm, explícate.
En muchos proyectos de software libre, el creador suele ostentar el título de dictador benevolente de por vida, o por sus siglas en inglés, BDFL: Benevolent Dictator for Life.
¿Hay muchos dictadores aparte del creador de Rust?
Claro, está Guido van Rossum, de Python, que fue el primero que inventó el término.
Larry Wall de Perl creo que también lo ostenta.
Sí, además de Linus Torvalds, con referencia al kernel de Linux.
Y Rasmus Lerdorf de PHP también.
Vale, queda claro qué significa. Me había quedado ahí leyendo un artículo de Graydon Hoare sobre el hecho de si Rust pudo o no haber sido mejor.
¿Hoare? ¿No tiene nada que ver con Tony Hoare, quien desarrolló Quicksort?
No, esa duda surgió en Reddit y parece que alguien le preguntó directamente y su respuesta fue que no están emparentados. A menos que él sepa. Se conocieron una vez, pero eso es todo.
Hubiese sido genial.
Has comentado algo de un artículo. ¿Qué decía?
Ah, pues que Graydon dijo que él tenía una visión diferente de lo que sería Rust.
¿Pero no era un dictador en su proyecto?
Sí, pero muy benevolente.
Entonces... ¿él consideraba que si Rust hubiese seguido la línea que él quería hubiese sido mejor?
En verdad dijo que si Rust hubiese seguido sus deseos no habría tenido futuro.
¡Vaya! ¡Este hombre no se valora lo suficiente!
A día de hoy, Rust se perfila como un digno sucesor de lenguajes menos seguros como C o C++, al menos según el comunicado que emitió no hace mucho la Casa Blanca.
Sí, no obstante, tal y como comentábamos en nuestro capítulo sobre JavaScript—
¡Nuestro infame capítulo!
Sí, ahí decíamos que la gente no lo tomaba como una opción por la cantidad de cambios que tuvo en sus primeras versiones antes del lanzamiento de su versión estable. Pero es normal, ¿no?
El problema fue su rápida adopción por cantidad de entusiastas antes de ser completamente estable, lo que hace imposible realizar cambios estructurales sin romper nada.
Y hay gente que aún así se queja de que van despacio implementando cambios.
Nunca llueve a gusto de todos.
Pero estamos diciendo muchas cosas, vayamos por partes. ¿Cómo surge Rust?
Antes de continuar, Un inciso: ¿Te gustaría apoyar a nuestro canal?
No te olvides de darle a me gusta y, si no lo estás, suscribirte para no perderte futuro contenido. También puedes apoyarnos si quieres uniéndote al canal o enviándonos un gracias aquí abajo en el botoncito. Nosotros te lo agradeceremos igualmente y os avisaremos de ofertas y promociones del canal.
Y además también podemos acompañarte desde tu plataforma de podcast favorita.
Ahora sí, continúa.
El origen de Rust. En 2006, Graydon era un programador de 29 años dentro de Mozilla.
¿Estaba en la comunidad de Mozilla o es una empresa y estaba contratado?
Mozilla es una fundación establecida en California.
Parece que California es el sitio elegido por muchas fundaciones.
No entremos en eso, lo importante es que Graydon estaba contratado por la fundación Mozilla.
Exacto. Pues uno de sus días de trabajo el ascensor estaba estropeado.
Vaya, ¿tuvo que subir por las escaleras? ¿Estaba en forma?
No, se fijó en el fallo. Parece que fue un error de software.
¡Qué curioso! ¿Y el programador, al igual que muchos de sus compañeros, lo solucionó?
Se interesó por el tipo de error de software. Parece que tuvo que ver con la gestión de memoria.
¡Vaya! Justo lo que señalaba el comunicado de la Casa Blanca.
No me digas, ¿estaba en C o C++?
Seguramente. El pensamiento de Graydon fue: ¿Es que no podemos hacer un software que pueda hacer que un ascensor funcione sin romperse?
¿Fue el momento de la epifanía?
Sí, al parecer buscó información acerca de ese fallo y encontró que el 70% del software tiene errores relacionados con la gestión de memoria.
Al parecer trabajaba en un piso 21, por lo que si tuvo que subir las escaleras, seguro que sería suficiente motivación para pensar y enfadarse acerca de la situación.
Pues ese mismo día abrió su portátil y comenzó a elaborar y diseñar un nuevo lenguaje de programación. Uno que pudiese escribir código pequeño, rápido y sin fallos de memoria.
Suena bien, pero ¿de verdad no había ningún lenguaje que ya hiciera esto?
A ver, era 2006. Podríamos enumerar lenguajes como Python o Ruby, pero no entran dentro de la categoría de pequeños y rápidos.
Bueno, ¿Cig, Nim o Cristal?
Cig es de 2016, Nim de 2008.
Casi.
Y Cristal de 2014.
Vale, parece que no había solución.
No, desde entonces han surgido muchas más opciones, pero el enfoque de Rust no está incluido en ninguna de ellas.
¿Y Julia?
¡Ya estamos!
El nombre de Rust fue en honor a un grupo de hongos notablemente resistentes y, según sus propias palabras, que estaban sobrediseñados para sobrevivir. Primeros pasos y caídas de Rust.
Un momento, ¿caídas?
Sí, uno de los principales problemas de las nuevas versiones de Rust hasta llegar a la versión 1.0 fue la cantidad de cambios que hicieron.
¿Rompían mucho lo ya establecido?
Muchísimo. Algo tan fundamental como el sistema de tipos de datos fue cambiado en la versión 0.2, 0.3 y 0.4. Para que nos hagamos una idea, la versión 0.2 tenía clases y en la versión 0.4 ya no. Esto fue reemplazado por tipos estructurados, al igual que las interfaces que fueron combinadas con los traits para posteriormente ser eliminadas. A eso hay que agregar que al principio tenía recolector de basura y después fue eliminado.
Son cambios muy grandes.
Sí, pero el problema radica en que pueden sucederse cambios bastante grandes sin necesidad de que haya un cambio de versión mayor en el lenguaje.
¿Un cambio de versión mayor?
Sí, normalmente los programadores recurren a un sistema llamado versionado semántico, que son 3 números separados por un punto.
Recuerdo haber visto esos números en muchos programas. ¿Qué significan?
Tienen un nombre según su posición: el primero es mayor, el segundo es menor y el último es parche.
¿Un parche? ¿Eso quiere decir que no tiene importancia?
No. Parche en sentido de que arregla algo sin alterar su funcionalidad, como el parche que se coloca en una rueda cuando se pincha. No has cambiado nada, solo has parcheado el problema.
Duck Tape al rescate.
Entonces el último número puede cambiar y no debería romperse nada, ¿cierto?
Exacto. Un cambio de parche suele ser para corregir un error sin que ello conduzca a un cambio en las funcionalidades.
Vamos, que si actualizamos el software y solo cambia ese único número, debería funcionar exactamente igual, pero más estable por haber corregido ese problema.
Exacto. El segundo número suele indicar que se agregan características, pero igualmente no se rompe nada, solo se agrega nueva funcionalidad.
Vale, entonces en software que sigan este sistema cambiando el último número o el del medio, no hay problema, se corrige o se agrega nueva funcionalidad y Y todo va como cabe esperar.
Entonces, ¿qué significa el primer número? ¿Que todo se rompe?
Más o menos. El primer número indica que se cambia la arquitectura. Hay un cambio mayor que agrega incompatibilidades con lo anterior.
Pero Linux cambia ese número cada año. ¿Quiere decir esto que rompe compatibilidad?
No, Torvalds lo cambia porque no le gusta que el número menor crezca tanto.
Vale, entonces no todos siguen esta convención.
No, y Rust parece que tampoco. En cambios menores y parches se pueden introducir cambios que rompen algo, y de hecho ha pasado.
Vaya, supongo que esto frustró a los programadores de Rust.
No, porque ya lo saben, pero a los nuevos que se adentran en el lenguaje y de repente ven que hay código que funciona y otro que no, pues les llama la atención y se llenan sitios como Stack Overflow y Quora de preguntas.
Vale, pero aún así el lenguaje fue tomando posiciones. ¿Qué fue lo que hizo que comenzara a ser considerado después de sus primeras versiones donde todo se rompía?
Fueron dos eventos.
¿Tuvo que ver que se publicase su versión estable en 2015?
Sí, esa fue una, pero un año antes hubo otro evento que hizo a todos fijarse en este nuevo lenguaje: un artículo en Dr. Dubs por Andrew Binstock donde mencionaba algunos lenguajes como D, Go, y Nimrod.
¿Nimrod? ¿No habrás querido decir Nim?
No, inicialmente y en esas fechas el lenguaje fue publicado como Nimrod, por el personaje bíblico. Después cambió a Nim, pero de eso hablaremos en otro momento.
¿Solo por ser mencionado en una publicación?
No solo por eso. Binstock enalteció a Rust y lo posicionó en el artículo como un competidor de C++.
¡Vaya! Entonces Mozilla destinaría recursos al lenguaje, ¿no? Porque tal y como dijimos en el capítulo de JavaScript, el navegador servo desarrollado en Rust y cuya parte del código terminó en Firefox sentarían las bases para una propagación y soporte del lenguaje dentro de la fundación.
Sí, pero... ¡Uy, un pero! Algo no tan bueno pasó.
La Fundación Rust. Sí, llegó 2020.
El año del... ¡No lo digas!
¿Qué quieres, que nos tiren para atrás el capítulo?
Vale, vale, vale, tienes razón. Bueno, pues pasó algo que todos sabéis bien que nos confinó en casa.
Y llevó a Mozilla a despedir a 250 de sus 1000 empleados y, por lo que observo, fue abandonado y arrojó dudas acerca del futuro de Rust.
Pero, ¿por qué? ¡Si el lenguaje estaba despegando!
Recuerda que Mozilla basa su acción en el desarrollo de la tecnología de Netscape. Presente en Firefox. El lenguaje es una herramienta, pero no la base de su cometido.
¿Qué hicieron entonces los partidarios de Rust?
Crear una nueva fundación. Se aseguraron de poder llevarse legalmente todas las marcas registradas y los nombres de dominio y comenzaron a buscar financiación.
¿Quiénes apoyaron el esfuerzo inicial?
Pues fueron muchas empresas, pero las más notables fueron AWS, Huawei, Google, Microsoft, y Mozilla.
Pues no terminaron tan a malas.
Conclusiones.
¿Qué? ¿Ya acabamos?
Llevamos bastante hablando de Rust.
¿Y más qué nos queda? No hemos dicho nada de Linux.
Cierto, uno de los grandes desarrollos que ha conseguido incluir código Rust, aunque de momento muy superficialmente en algunos módulos. Sin embargo, si demuestra su valía, de seguro irá tomando más y más código dentro del proyecto.
Es un buen lenguaje y sus ideas de diseño, aunque no hayan sido las que su creador quería desde un inicio, han sido las acertadas en cada momento para hacer de Rust lo que es hoy en día.
Entonces, que se rompiese tanto inicialmente no fue sino una forma de alcanzar una buena base.
Ciertamente hay mucha controversia acerca de ese aspecto. Por un lado tenemos a Rust, que cambió mucho para intentar alcanzar un buen diseño, y por otro lado Go, que no cambió nada y promete no romper nada.
Es que Go ya tiene un buen diseño desde sus inicios.
Discutible.
¿Y vosotros qué opináis? ¿Llegará a sustituir a C++ como muchos dicen?
¿Lo habéis usado ya? Y si es así, ¿qué os costó más aprender o usar?
