Rust con Jesús Hernández

Pues buenas tardes, estamos en otro capítulo más de Codeadores. Esta vez me acompaña Jesús Hernández, que es un programador que conozco desde hace tiempo. Creo que fue a raíz de que compraste uno de mis libros de Elixir, y a partir de ahí ya mantuvimos un poco el contacto a través de Telegram, algunos foros y demás. Y como me comentó que había, se había lanzado al mundo de Rust, y como todavía no me entrevistaba nadie que trabaje profesionalmente con Rust. Lo convencí y lo tengo aquí para que nos hable un poquito de este lenguaje que, según tengo entendido, este año incluso ha llegado al número 1 de los lenguajes más deseados. Es decir, que los programadores tienen en su lista como que quieren aprender, que quieren aprender a utilizarlo, trabajar con él. Entonces es un lenguaje muy llamativo. La primera pregunta que suelo hacer y que me gusta hacer es: ¿Qué fue lo que te atrajo al mundo de la programación? Ese momento que te hizo clic y dijiste, quiero dedicarme a esto.

Pues me acuerdo que fue en instituto, con los típicos libros de tecnología que te toca tema de programación de ordenador y todo esto, y me llamó la atención y empecé a probar con eso. Primero probé con Logo, es decir, un lenguaje tipo de que tiene una tortuguita y vas jugando con ella y para dibujar en la pantalla, que es muy didáctico. Y de ahí ya me fui directo a C porque había un manual de C en casa de estos antiguos de mi padre. Y pues me lancé directamente a C, aprendí porque era el lenguaje con el que se hace Linux, con el que se hacen los sistemas. Y digo, pues bueno, pues vamos a aprender esto. Y así empecé.

Y entonces, vamos, fue en el instituto, es bastante temprano. Sí. Empezaste directamente con Logo y de ahí saltaste a C.

Sí, literalmente, en plan de vale, Logo es como de juguete didáctico, con qué se hacen las cosas reales. Ah, qué bien está hecho con C, pues nos vamos a C directo.

Entonces tu primer lenguaje así en el instituto y demás se convirtió en el lenguaje C. Sí. Si seguiste la línea y fuiste a la universidad, supongo que darías también el lenguaje C y ya llegarías con muchos años de trabajo en ese lenguaje.

Y sobre todo porque pasé primero por los FP, es decir, hice el recorrido de pasar por FP medio, superior y después ya me metí en la universidad. Entonces pues ya el propio ciclo ya iba con ventaja. Que lo que estaban ahí todos intentando mirar a ver qué es una función, cómo va el if. Pues claro, yo ya iba con la ventaja de, bueno, yo vengo de C, esto en JavaScript es sencillo.

O sea, directamente en los ciclos formativos dabais JavaScript.

Sí, porque era de sistemas y entonces tienes dentro del ciclo de sistemas una asignatura que va de la parte de web, de lenguaje de marcas y todo esto. Entonces ahí terminas viendo JavaScript para la parte de frontend. Y es como lo más típico. Aunque ya venía yo también de haber tocado JavaScript anteriormente, porque después de ese me dio curiosidad por las páginas web. Entonces me metí con PHP, JavaScript, y viví también el momento en el que salió lo del XHTML, que se supone que iba a ser la novedad, y después pues no pilló muchos rodajes y no terminó triunfando. Entonces terminé tocando muchas cosas antes de empezar con la formación formal.

Entonces, una vez que fuiste a la universidad, asumo terminaste la universidad y aprendiste aún más lenguajes de programación.

Bueno, la tengo todavía pendiente de acabar, la dejé ahí a medias porque ya como estaba trabajando y haciendo universidad y trabajando a la vez, pues ibas haciendo créditos según ibas pudiendo con el tiempo y todo. Es decir, es algo que algún día de estos tengo pendiente de acabarlo, pero tampoco me corría prisa porque era en plan de, bueno, pues 40 horas semanales trabajando, luego tienes que ver las que te quedan para poderle dedicar a los proyectos de la universidad. Universidad y como ya estaba trabajando digo bueno, pues el dinero ya por lo menos entra. Entonces tampoco iba con prisa por ese lado. Pero sí, después de la universidad, pues como yo ya estaba trabajando en ese momento, en plan no la acabé y estaba trabajando, pues fui pasando por diferentes tecnologías. Y yo he pasado tanto por Erlang Elixir, más de por mi cuenta, por hobby todo esto, hasta Python, he tocado PHP también, Rust. Es decir, en ese sentido no he tenido nunca miedo de ir tocando diferentes tecnologías.

¿En qué momento decidiste, es decir, si estabas trabajando y pasando por distintas tecnologías, en qué momento decidiste, bueno, me planto en este lenguaje de programación y voy a hacer principalmente de este lenguaje programación?

Eso fue un momento en el que en la empresa en la que estaba pues se estaba mirando de hacer cambios de una aplicación antigua que ya venía de C y C++, que se quería también llevar para la parte web, que por eso después llega el WebAssembly con Rust. Y entonces en ese momento había que pensar pues con qué tecnología empezar a hacer todo lo nuevo. Y entre que Rust tenía esa parte que me gustaba también de que está orientado para la parte de seguridad, es decir, que intenta que haya menos errores, que sea más seguro y todo, que también permitía irse ya para web y te permitía manejar el escritorio, pues lo vi una buena tecnología, lo fui proponiendo. Y al final terminó calando, es decir, lo terminaron aceptando. Y ahí empezó él a empezar todo lo que era nuevo, de nuevos desarrollos por esa parte, o irle añadiendo cosas a ese software en 365 Plus, que ya se iba haciendo en Rust también.

Entonces, o sea, el inicio en Rust fue con esta empresa y haciendo diferentes, como diría, diferentes soluciones. Porque has comentado de Rust en escritorio, Rust el servidor, React en WebAssembly.

Sí, en este caso era de para llevar algunas funcionalidades que las podía tanto utilizar esta aplicación antigua, porque todavía se tenía que seguir manteniendo en C y C++, pero a la vez que tuviéramos libertad de podérnoslo llevar a web para poder dar solución también en la parte web, porque tenían un editor en web y otro en escritorio separados, y la idea era pues tener solo uno. Entonces pues Rust permitía eso, en plan de igual que con Node, es en plan de pues bueno, igual que estamos haciendo frontend, ahora nos podemos llevar a backend. Con Rust podíamos estar en escritorio, lenguaje compilado, uniéndolo con C y C++, y a la vez esa funcionalidad la coges y te la llevas para la web y la puedes utilizar desde web también.

Entonces hicisteis lo del meme de Ferris que sale con el cuchillo diciendo reescribirlo todo en Rust.

Más o menos, pero no reescritura completa, sino las funcionalidades nuevas que pudieran utilizarse desde ambos entornos. Entonces era más como algo incremental.

¿Mantenía una interoperatividad entre C++ y Rust?

Sí, exacto, sí. Entonces se terminaba compilando el código anterior de C y C++ junto con el código de Rust.

Y desde esa empresa, ¿cuántos otros proyectos o empresas has tenido o te has mantenido dentro de la misma?

No, después de esa empresa ya cambié por mi cuenta, es decir, ahí ya me fui a China y empecé ya a meter RAS también en mis propios proyectos, ya tanto personales como de emprendimiento. Como por ejemplo, pues lo último que he hecho con RAS ha sido de para poder recibir correos electrónicos y después añadirlos a, igual que recibes formularios, pues añadir la información tanto del correo electrónico como el formulario y poderlo unificar todo, pues el día también tendrás. En vez de estar complicándote de que si montas un proceso a ver si automatizas algo, lo mandas a otro sitio. Vi que había un crate en Rust que permitía recibir correos, fue como, vale, pues levanto un pequeño servicio que lo reciba, lo meta en la base de datos. Y lo bueno que va súper rápido porque también es muy bueno Rust para temas de optimización, te da mucha facilidad para optimizar como si estuvieras en C pero con más seguridad. Y de que raramente vaya a fallar, es decir, porque está todo sin unsafe. Entonces ya con el propio compilado comprobando la memoria y todo, te da esa tranquilidad de que es complicado que falle, más toda la facilidad que da para nivel de hacer tests y todo esto, que es muy bueno la forma en la que te permite hacer tests, que puedes hacer tests unitarios dentro de los módulos y de esa forma puedes acceder a las cosas que serían privadas sin tener que estar exponiéndolas o mirando si haces las cosas de otra forma porque no puedes llegar a cierto método para poderlo testear. Entonces te da bastante seguridad en todos los aspectos.

Estabas diciendo que lo que ha hecho es como una especie de automatismo. Y sabiendo otros lenguajes como Python u otros lenguajes en tu haber que tienen esa ventaja que suelen enfatizar mucho de bueno, abres un editor, echas unas cuantas líneas de código y ya tienes tu script ahí preparado. ¿Cómo ves la fricción de lanzarte directamente a Rust y hacerlo en Rust? ¿Es porque ya tienes tanta soltura en Rust que no te cuesta mucho trabajo, o porque realmente es muy fácil hacerlo en Rust?

Es un poco de ambas, porque sí es verdad que ya tengo tanta soltura que al final, este caso por ejemplo, el servidor que recibe emails creo que no llega a las 200 líneas, está a ciento y pocos líneas, por como también se utiliza dependencias y todo. Que también esa es la diferencia de que quizá lenguaje muy antiguo, cuando no estaba, es decir, no sabes, podía hacer algo tipo npm require y añadir cosas. Y en Rust tienes con cargo, que es poco menos como si estuvieras con npm, le puedes añadir dependencias muy fácilmente para que construya. Entonces eso te quita parte de cosas que quizá hubieras hecho a mano o estuvieras complicándote. Espérate, que me tengo que bajar la DLL, ponerla aquí. Y que ya que tanto tiempo utilizando Rust, pues coge uno la soltura y tiene parte de malas famas de que es difícil de aprender y esto, pero realmente lo que tiene complicado es el tema del comprobador de la extensión, es decir, el ownership y todo esto. Pero una vez que llegas a entender el ownership, te hace como ese clic mental, realmente no está complicado porque el resto de sintaxis es muy similar a un lenguaje o a otro. Porque si ya vienes con experiencia de saber programar, no te es tan complicado. La parte complicada es entender y manejarte con el borro, con el ownership.

Y dado que parece que Rust se ha convertido en tu lenguaje de preferencia, ¿qué es lo que más te gusta o qué es lo que te hace elegir a Rust sobre el resto?

Pues depende para qué cosas, pues escojo otros, porque por ejemplo para el desarrollo web a veces he escogido PHP porque ya tiene otras dependencias que me dan un panel ya hecho, tengo ciertas facilidades después el aire y dices, pues tiro por aquí porque me va a ahorrar tiempo por ahí. Flask, por ejemplo, lo que tiene de para hacer servidores web es más tipo API, es decir, no tiene algo pensado como para hacerte un admin de me instalo tal dependencia, ya tengo un admin, no es tan conocido. Pero sin embargo, para cosas que digo, esto quiero que o aguante mucha concurrencia junto con que vaya rápido, que responda bien y cosas así, pues al final es como decir, la alternativa tradicional que hubiese sido irte a algo que esté hecho en C, que vaya rápido, que controle las cosas por evento como hacen Nginx o cosas así. Y ahora tienes Rust y puedes decir, vale, pues este servicio que quiero que me aguante más cosas me lo hago en Rust y el resto me lo hago en otra cosa. Y puedes al final combinar diferentes microservicios para que funcionen entre todos juntos, para lo que cada uno vaya mejor.

Y la pregunta contrapuesta de qué es lo que menos te gusta de Rust. Así es que hay algo.

Lo que menos me guste, sobre todo antes, o que cuando empecé yo, había algunas cosas de Erras que tenías que ir esperando a que las estabilizaran y cosas así. Ahora, por suerte, ya muchas de las cosas te las encuentras ya estabilizadas, y el que llegue ahora encuentra el terreno más llano en ese sentido. Antes mismo, si querías irte a cosas que están instaladas, Assembly, Inline, cosas así, Pues tenías que irte a la rama unstable, cosas de este estilo, es decir, porque todavía no lo tenía. Y ahora realmente no hay así algo que diga que me desagrade, pero porque la mayoría de lenguajes al final los veo como herramientas, no de esto que me terminen, no termino odiando lenguajes como algunos hacen, pero lo que más puede que a veces se ponga punta de raya es el tema del propio ownership, pues que alguna vez te quieres ir rápido a hacer algo y te dice el compilador, no, no, esto no me lo has puesto bien. Está bien, voy a controlar mi labio. Y en plan de vale, ya voy. Y eso entiendo que puede que a veces no gustara a la gente y es normal, porque es como que tú quieres ir rápido y pues te dice no, no, ahora me lo haces bien.

Yo creo que hay gente para todo, ¿no? Porque hay lenguajes, Rust, por ejemplo, y creo que fue Elm el que inició la moda de dar mucha información sobre los errores que van saliendo en pantalla. Se propagó a Rust y hay muchos lenguajes ahora como Elixir, Erlang, Java, todos los lenguajes se van contagiando de estas características porque son buenas. Entonces lo bueno siempre se copia. Y creo que el hecho de que el compilador te dé ese tipo de sugerencias, pero además te fuerce a ello, es algo que muchos lenguajes terminan no siendo bien agradecidos. Y es lo que tú dices, que tienes prisa. En Rust, por ejemplo, te fuerza a que hagas bien la gestión de memoria. Python te fuerza a que intentes bien, y eso también no les gusta a todos.

Sí, es eso. Lo que después, aparte de que no te gusta esto, pero cuando te vas acostumbrando, tienes el lado positivo de que ya vas a cada vez cometer menos errores. Y vas a tener el lado positivo de no tener el perjuicio de quizás haber manejado mal la memoria o que luego el código del otro no lo entienda, en el caso de Python. Y al final tiene sus luces y sus sombras.

También dicen que Rust tiene una curva de aprendizaje bastante alta por la cantidad de estructuras de control que tiene y quizás que sea difícil hacerse con todas ellas, utilizarlas bien, porque realmente entenderlas al final se pueden entender, pero llegar a utilizarlas bien Lo que realmente después no tiene tantas.

Sí, porque si te pones a mirar, muchas están en otros lenguajes. Lo que yo creo que puede frenar más a la gente es el ownership, porque es lo que sí que es diferente. Es decir, no hay otro lenguaje que conozca que te vaya a decir la memoria le pertenece a este, se la has prestado, no se la has prestado. Pero sin embargo, el resto de lo que son estructuras y cosas así es más entendible. Quizás alguien que llegue de cero no, pero pues tampoco va a tener otro lenguaje con el que compararlo. Pero mismo cosas como el match que tienes en Rust, pues algo parecido lo tienes en PHP también, que tienes ahí un match que tiene sus diferencias, pero al final el concepto es similar. O lo puedes también relacionar con el switch que tienes en algunos lenguajes, aunque sea más diferente. El if-else pues lo tienes lo mismo. Es decir, cosas como después los futuros lo puedes asemejar a una promesa de JavaScript, por así decirlo, es decir, conceptualmente, aunque tengan sus diferencias. Entonces no es tan diferente en ese aspecto. Ahí pues hay cosas que ya te van a sonar, otras que tiene alguna pequeña diferencia, como que sí tiene variables constantes y las que son de LED. Pero ya mismo en TypeScript también tienes const y let, es decir, y más el var. Entonces realmente no es tanto que tenga cosas muy diferentes, sino que entre la fama que le han dado, que ya va la gente con ese miedo de pensar va a ser difícil, y que sí que es verdad que El que venga sin mucha experiencia gestionando memoria, pues le va a saltar más el ownership. Ahí es donde yo creo que se pueden frustrar y pensar que es que es totalmente diferente, que no hay forma de entenderlo, que va a ser más difícil. Yo creo que va por ahí.

Entonces, lo que tú marcarías más difícil de Rust sería la parte del ownership, de la gestión de memoria.

Sí, básicamente, porque después, más que estructuras, podría ser de tipos de datos, que eso también a alguna persona le resulta mucho, que tienes que si el string literal, después tienes string, pero que tienes el clone, copy, etcétera. Y ahí cuando quizás se abruman porque ven mucho tipo, pero es lo mismo que, vale, en un lenguaje como Python quizás no te va a forzar tanto a los tipos, pero luego puedes tener errores por no haber manejado los tipos bien, porque como los vas ignorando. O en JavaScript que empiezas a hacer operaciones y de repente te aparece un NaN y tienes que empezar a buscar de dónde ha salido ese NaN, que Va por el tema de tipos también. Rust te va a forzar a que seas muy consciente de los tipos, pero a su vez te va a evitar todos los errores que vendrían de no haber manejado los tipos.

Otra de las cosas que quizás quien aprende pues le puede chocar un poco.

Sí, exacto.

O sea, si alguien dijese quiero aprender Rust, o sea, ¿cómo ves más fácil acercarse a Rust? ¿Sabiendo algún lenguaje previo? ¿Incluso sin saber ningún lenguaje recomendarías su aprendizaje o dirías no, mejor aprende este otro y entonces ya te lanzas a Rust?

Es posible aprender Rust sin tener conocimiento previo porque yo he visto de compañeros que quizás no venían de informática, sino que venían quizás de áreas como matemáticas o cosas así, que no habían programado antes, y era posible enseñarles Rust como primer lenguaje y no tenían problema. Incluso no tenían esa cosa de decir es que es más difícil que este otro, porque como era el primero, pues simplemente estaban aprendiendo a programar y no tenías la comparación de es que este es difícil porque no tiene esto que tiene el otro o esto lo hace diferente. Entonces era como que lo reciben como vale, pues esto es la forma de programar y ya está, no pasa nada.

¿Y qué recomendaciones darías a quien quiera aprenderlo?

Pues por ejemplo, cuando coges el libro oficial de Rust, llegas al capítulo 4, que es el de Runes, lo ves muy largo y quizás dices, bueno, esto me lo miro por encima y paso a lo siguiente, que es donde ya tengo más cosas que puedo hacer así. Y en realidad eso será un error porque es justamente ese capítulo el que te puede ayudar más. Porque con Rust la cosa es hacer el clic mental de pensar, vale, tengo que entender cómo he estado gestionando la memoria, los tipos que son las cosas. Algunos tipos, por ejemplo, como el clone y el copy, que están pensados para darte información como programador cuando estás leyendo el código, de si eso te va a penalizar en cuanto a performance o si eso es fácil copiarlo y entonces no te tienes que preocupar. Y ver esas cosas con calma, porque una vez haces el clic mental en lo que realmente es diferente, un if, una función, una estructura, método y todo esto lo vas a ver similar a algún lenguaje que ya conozcas, con su diferencia sintáctica de cómo se escribe, etcétera, pero conceptualmente lo vas a entender.

¿Y algún recurso, es decir, aparte del libro oficial de Rust, que lo recomendamos, qué otro material podría ser interesante o importante para enfocarse y aprender bien?

Ahora mismo de materiales hay muchas cosas por ahí, pero dependiendo de para qué se vaya a utilizar. Ahora mismo hay también material que ha ido creando la comunidad, pero específico para WebAssembly, si quieres ir por ese lado. O específico de microcontroladores si quieres ir por ahí. Entonces ya toca, dependiendo qué uso le quieras dar, pues entonces coger la documentación que han ido creando para esa finalidad. Y pero mayormente está todo en inglés ahora mismo.

Me llama la atención que WebAssembly, por ejemplo, se está colando en la mayoría de entornos y casi se puede hacer de todo con WebAssembly. Pero, ¿se podría programar para aplicaciones móviles, por ejemplo, utilizando Rust?

Sí, porque ahora mismo tiene Stauri 2.0, que salió este año la versión 2, si no me equivoco, y te permite programar con tecnologías parecidas a las de electrónica. Haces el frontend como web y la parte de backend, en lugar de hacerla en Node, pues la haces en Rust, y te deja ir tanto para escritorio de Windows, Linux, macOS, y puedes irte también para móvil, tanto Android como iOS.

Porque podrías tener escritorio y móvil de una, o sea, con un mismo código directamente tendrías todo.

Sí, y como la parte frontend la has hecho con tecnología web, pues puedes tener la web ya de paso.

Positivo. Entonces le hace un poco la competencia a Flutter en ese aspecto.

Sí, Tauri sí se podría decir que le hace la competencia tanto a Flutter como a Electron, porque al final, si te vas a mirar, Tauri es como un Electron, pero en vez de con Node, con Rust.

Y supongo que de rendimiento andará bien, ¿no?

Sí, porque tienes ya la parte backend que hubieras hecho en Node, pues la tienes en Rust. Tienes control completo del rendimiento, optimizar lo que necesites. Si quieres compilar para la CPU específica en la que estás o cosas del estilo. Y después también de que baja mucho el tamaño del ejecutable. Es decir, lo que haces un hola mundo en Electron y mismo estás ya por encima de los 50 megas. En Taurine, si no recuerdo mal, son como unos 600 y algo kilobytes. Creo que baja bastante.

Está muy bien. Cuando te he preguntado de qué era lo que menos te gustaba del lenguaje, me ha dado a entender, aunque has dicho batallar con el compilador, que a veces pasa. Eso sería lo que cambiaría, pero o sea, lo que menos te gusta. Pero si tuvieses la opción de estar dentro del equipo de desarrollo y te dijese venga, decide un cambio. ¿Qué cambiaría?

Pues seguiría en la línea de unos cambios que ya vienen haciendo, de que cada vez haga menos falta el colocar los lifetimes, que es básicamente cuando el compilador no entiende bien, oye, que esto que estás cogiendo aquí por referencia, ¿qué tiempo de vida tiene? Dame el lifetime, ¿de dónde viene? Antes había que colocar muchos más de estos, que es lo que en Rust se ve como un aspen, comilla y una letra, o en la parte donde estarían los genéricos se ve como una comilla y una letra. Pues con el tiempo ha habido cada vez menos falta de eso, es decir, han ido simplificando de que algunas cosas ya el propio compilador te dice, oye, que aquí me lo estás indicando, lo puedes quitar, que este ya lo entiendo. Seguir mejorando por ahí, porque es una de las cosas que también cuando ven los lifetimes, esto es la parte del ownership, la gente se queda confundida de, pero ¿y por qué le tengo que decir que aquí, como si fuera un genérico, el lifetime? Si llegasen al punto donde el compilador pudiese entender todo sin tener que marcar ninguno, Ahí seguramente le sería más cómodo a la gente y más fácil el introducirse a Rust.

¿Cómo ves a día de hoy el mercado laboral para la gente que está empezando a programar en Rust o incluso programadores de Rust que llevan ya cierto tiempo?

Pero obviamente hay menos trabajo que de cosas tipo web o así, es decir, pero bueno, también la web tiene un mercado muy grande, es decir, hay muchas Tanto gente contratando web, gente haciendo web, pero sí que hay bastantes trabajos de Rust también que van saliendo con regularidad. Mismo yo en LinkedIn estoy en algunos grupos de Rust y en algunos de ellos van pasando ofertas de trabajo y quizás no tienes 100 al día o 20 al día, pero van pasando. Entonces oportunidades hay por ahí.

Y no hay todavía ningún framework web, porque normalmente cuando sale un lenguaje siempre lo asocian con algún framework web y directamente pues se puede desarrollar en backend directamente con ese.

Sí, en Rust tienes varios. Lo que ahora uno de los últimos que ha ganado bastante popularidad es Axum, porque ya lo monta directamente sobre Tokio para manejar todo el tema asíncrono y todo esto. Lo que Axum, digamos que para la gente que venga quizás de Python, sería como un Flask o algo así. Es como más para montar APIs y para montar un backend, pero no te da nada para templates. Te tendrías que buscar otro crate para templates. No te da un ORM, te tienes que irte o a a 10 euros algunos de estos para tener el ORM. Es como que él te da la parte de yo cojo web y respondo, pero todo lo demás te lo tienes que ir montando. Lo que le faltaría sería un framework web pero más completo, algo tipo como Django, Laravel, cosas de estas que digas, vale, yo me lo instalo y ya me permite hacer templates, ya me permite manejar la base de datos. Eso quizás le faltaría para gente que no quiera solamente hacer una API, sino que quisiera hacer algo con más allá de la API, que tuviera su plantilla, que pudiera ver las cosas, etcétera. Pero si lo vas a utilizar para APIs, con Axum lo puedes utilizar sin problemas.

Tenemos una persona que siempre nos pone un comentario en muchos de los vídeos que hacemos en Programando Otra Historia, que siempre nos dice, es decir, en el vídeo de Django, por ejemplo, en el de Ruby on Rails, en todos siempre dice, mejor es Ah, vale.

Sí, Leftovers, si no recuerdo mal, sí es un framework para Rust. Lo que ese no lo he llegado a probar todavía. Es decir, lo vi por encima y lo tengo pendiente, pero sí. Esto que van saliendo cosas en Rust, lo que no tiene todavía tanta trayectoria como quizás otros, pero va, la comunidad aporta mucho. Y el lado positivo que tiene también es ese, de que hay mucha gente aportando. Y para el final es cuestión de que también la gente se lance, lo use, y a base de usarlo e ir dando feedback, pues pasando los años llegará un momento donde tengan además la misma trayectoria que los otros, que también tengan más recorrido. Al final muchas veces pasa esto a mí, que sale quizá una tecnología nueva, es como no, no la voy a usar porque nadie la usa en plantilla. Pero es que si nadie la usa, entonces nadie la va a usar porque no la está usando nadie. Como cuando le pasa a la gente lo de, pero que me piden experiencia para trabajar, pero no la tengo si no trabajo. Esto también pasa en tecnología a veces.

¿Tú crees que, por ejemplo, en una empresa que estén utilizando Rust, ¿Contratarían a algún junior que conociese Rust pero que no tuviese experiencia en Rust profesionalmente?

Aquí es complejo porque depende mucho de la empresa. Lo que al final muchas empresas, incluso cuando insisten en contratar solamente seniors, si ven que no consiguen a nadie, terminan bajando el listón. Por lo que sí que en algún momento terminarían contratando juniors, porque al final, pues si no consigues a alguien con la experiencia que esperas, Pues tampoco pasa nada por coger a alguien que viene con ganas y que ya sabe una base y enseñarle. Al final también es una opción para esas empresas. Pero sí que hay algunas empresas que sí que cogen tanto juniors como incluso en algunos casos gente que, es decir, porque yo estaba en empresas donde llegaba gente que quizás no había programado, pero venía con otro conocimiento que era útil y se les podía enseñar en un par de semanas. Y en un par de semanas ya pueden estar trabajando de forma autónoma sin problemas.

¿Y has trabajado para alguna empresa? O sea, porque nos has contado el caso de la empresa esta que estaba con C y C++ y ha cambiado a Rust. ¿Hay algún otro lenguaje diferente a C++ o C que tocase migrar hacia Rust en tu experiencia?

Que tocase migrar hacia Rust, no. Pero sí que se puede combinar Rust con cualquier otro lenguaje. En ese sentido no tendrían problemas porque cualquier lenguaje que permita interactuar con C, al final puedes interactuar también con Rust. Porque al final Rust viene siendo como el nuevo C, es decir, tiene API para interactuar con C. Entonces él puede, digamos, puedes tratarlo como si fuera C. Expones las cosas como si fueran a ser llamadas de C, Y cualquiera que pueda interactuar con CLI va a poder llamar también.

Yo he conocido algunas experiencias que me contaron de empresas que estaban trabajando en Erlang en EE.UU. y que de repente les dijeron que con Rust tendrían mejor concurrencia, mejor, o sea, menos latencia, que era lo que les interesaba a ellos. Y entonces cambiaron todo el código base a Rust. Y en principio lo que consiguieron fue reducir el número de servidores y reducir la latencia, que era su objetivo. Por eso te decía de si conocías más experiencias de cambiando de un lenguaje a otro y qué beneficios han obtenido.

Sí, no, y ahora haciendo memoria, que me olvidé antes de que el otro lenguaje así en el que no sé tanto migrarlo, pero sí de combinarlo con Python, que tiene Pyro, o creo que se llama Pyro 3 o algo así, o Pyro 3, que te permite hacer módulos nativos de, en Rust para Python, y en Python los utilizas como si fuera cualquier otro paquete de Python y no tendrías problemas. Y después también para Node, que a veces pues toca combinar alguna cosa de Node con Rust, y lo bueno es que tienen frameworks que ya te permiten hacer el el crear el paquete para el otro lenguaje muy fácilmente. Tanto para Node como para Python se pueden hacer muy cómodos.

Yo tengo conocimiento de que en Erlang salió un proyecto que se llama Rustler, que te permite inyectar código en Rust dentro de Erlang. Y todas las experiencias que he oído es que es mucho más seguro que hacerlo con C. Es por eso de que si tienes un fallo dentro de la máquina virtual de Erlang con C directamente todo se cae, mientras que con Rust te controla un poco mejor la memoria y es más difícil que esto pase.

Incluso para cosas que quizás tendrías que decirle al compilador, oye, déjame hacer esto, que sé lo que estoy haciendo con memoria. Lo bueno es que después, si hubiese algún problema, como tienes el unsafe marcando esos puntos donde le pides al compilador más control, pues después lo tendrás que ir a buscar ahí primero, porque pues si tienes un unsafe en Rust y tienes un problema de memoria, el primer candidato va a ser ese, básicamente, porque donde le has dicho al compilador no, no, no me protejas esto, déjame acceder a mí lo que quiero. Entonces también te ayuda por ese lado. O incluso si tienes problemas de rendimiento, por lo que decía antes del clone y el copy, que son dos threads que tiene Rust para diferenciarte si algo lo puedes clonar, en plan de que puedes hacer un duplicado de esa estructura, y eso te lo da como que tiene costes. Si tú tienes que marcar en el momento que estás haciendo clones con un punto clone, se ve muy obvio de que si con un punto punto clone por algún lado y tienes que optimizar esa parte, pues sabes que ese es un candidato de que haya que optimizarlo porque está copiando memoria. Y si algo realmente es barato, lo puedes marcar con un copy, y de esa forma ya no te obliga a poner punto clone. Por lo que te da esas herramientas para poder tanto optimizar como encontrar antes los errores, o incluso evitártelos.

Bueno, entonces has comentado que teníamos ya para hacer tanto extensiones para Python como Con para Node. Para Node. Y creo que hay también para PHP, si no recuerdo mal.

Sí, también hay cosas por PHP que no lo he llegado a probar, pero también se ve interesante. Si puedes hacer al final Moodle for PHP, incluso para cualquier cosa que quizás no haya alguien hecho todavía el framework, lo bueno es de que allí donde se llegue puedes llegar. Y en ese sentido no tendrías problemas. Te tocaría hacer más trabajo, serías tú quien haría el primer framework para ese lenguaje para hacerle módulos, pero bueno. También tienes la oportunidad de que luego alguien use tu paquete y use lo que has hecho.

¿Eres usuario de Linux?

Ahora mismo no, ahora mismo estoy con Mac y con Windows, pero hace tiempo tuve Linux durante mucho tiempo como único sistema. Lo que al final en una de estas, sobre 2016 por ahí, tocó cambiar a Windows porque al final era el sistema que utilizaban los clientes y donde había que probar las cosas. Y pues al final acabé en Windows porque era más cómodo que estar cambiándose, reiniciando PowerDualBot. Y después de eso pues pillé un Mac por también empezar a hacer aplicaciones para Mac y al final me he acostumbrado al Mac porque es como si fuera un Linux pero que no es Linux. Pero por lo menos se le parece porque tiene al final la shell y todo.

Entonces has podido probar Rust en todos los entornos, tanto Linux como Windows como Macintosh.

Sí, exacto.

¿Funciona más o menos bien o tiene alguna característica en alguno que no vaya del todo?

No, funciona muy bien en todo porque de hecho se esfuerzan los propios que mantienen Rust, se esfuerzan en ello. Mismo, lo típico suele ser que quizás en Windows tenga peor soporte, porque entre que la mayoría de desarrollos se van para Linux o algunos quizás se han ido para Mac, te dejaban Windows ahí un poco más abandonado. Y justamente insistieron de que a todos los sistemas había que tratarlos por igual y que todos pudieran utilizarlo, porque en ese sentido no vas a tener problemas ninguno en otro. En Windows lo único que tienes es que tienes que instalar, pero te lo hace el propio instalador de Rasa, las build tools estas de Microsoft y todo esto, pero nada más que en el momento que vas a ejecutar el rasapp te saca las cosas, vas haciendo lo que te dice y lo instalas. Y en otro sistema pues simplemente ejecutas rasapp y ya te lo deja todo listo. Y tienen ese paso extra en el instalador, pero una vez instalado rasapp y tienes cargo y todo funcionando, el resto es igual.

Y está al día de No sé si llamarlo polémica porque tampoco es exactamente cómo va a día de hoy. Cuando en Linux, Linus Torvalds abrió la puerta a que se escribiese código en Rust.

Sí, y que acabó uno diciendo, mira, yo me voy de aquí, que cuando queráis hacer código me avisáis, pero para estar con cosas que no son técnicas me largo. Sí, eso lo vi en su momento. Eso es triste que pase. Pues es triste que pasen estas cosas porque al final termina alguien abandonando esa posición o termina habiendo conflictos por cosas que si fuera por cosas técnicas pues todavía se entiende, es decir, puede haber más debate, pero al final acaba siendo por gustos y cosas de este estilo que a veces habría que dejar un poco más de lado porque es como cuando en equipos o cosas así termina habiendo quizás horas de reunión por si el corchete tiene que ir al lado o debajo, que si ponemos espacios o lo otro, que si este estilo o aquel estilo. Y al final nada de eso te va a aportar al usuario nada, es que no le cambia a él cómo lo usa. Y es algo que dices, mira, coger uno cualquiera, ya está. Y lo que pasó en Linux fue, por lo que estuve viendo de la polémica, más de entre ellos que hay un problema técnico. Entonces, como, hostia, pues poneros un poco de acuerdo en plan de, vale, el que no quiera tocar esto pues no lo pongáis en esto, el que sí quiera pues ponerlo, pero no hay necesidad de estar quemando a la gente por cosas que Encima no son que no funcionen o que haya un problema técnico. En plan, a veces la gente se ofusca mucho con cosas que no son tan importantes y terminan metiendo cosas personales que no deberían. Pero bueno, una pena por ahí que quemen a la gente. De hecho, creo que no ha sido solamente con Rust y con lo de Linus lo que ha pasado. Es decir, ha habido también más proyectos open source que estando alguien solo manteniéndolo de gratis como podía, buenamente, sin ninguna aportación, le han insistido y ha terminado también, o creo que hubo uno que borró el repositorio o algo así, o lo archivó y que también tuvo problemas. Entonces, al final esto es más un problema de relaciones sociales, de soft skills y de trato con las personas, que lo suyo sería que ya viniéramos todos de casa con eso aprendido. Pero bueno, se ve que todavía hay algunos que no.

Está claro que la mayoría de proyectos donde se ha utilizado de siempre C y C++, siempre se aboga por intentar cambiar a un lenguaje más moderno, más seguro en este caso cuando se habla de Rust. Y recuerdo también la conversación del C++Conf de hace unos 3 o 4 años, que salieron los de Google haciendo su propuesta a C++, de vamos a modernizarlo, vamos a hacerlo más como Rust, y ellos se negaron rotundamente. Querían su lenguaje tal y como estaba y con sus mejoras a su ritmo y sin vamos, sin saturar. Si se tienen que hacer mejoras, se van a ir haciendo a medida que la comunidad las vaya aceptando, y si no se aceptan, pues no se integran. Entonces esto lo vio Google y creo que pusieron sobre la mesa hacer los cambios de, bueno, imagínate, el motor de búsqueda de Google pasarlo todo a Rust, que son millones y millones de líneas de código. Pues directamente dijeron no. Lo que no entiendo es por qué uno de los motivos por los cuales decían que el cambio a Rust no era posible era porque eran dos ecosistemas muy diferentes. No entiendo en sí esto porque, tal y como tú has comentado, la interoperabilidad está muy bien, pero por otro lado también habría que ver lo que tienen ellos hecho en la parte de de ecosistema con C.

Claro, y que la mejor interoperabilidad la tienes con C. Con C++ también tienes cosas, pero quizás con alguna cosa concreta de C++ pues tiene quizás un poco más trabajo, que tengas que hacer alguna interfaz más o algún apaño. Es decir, pero sí que la parte de C al menos es básicamente como si fueran primo hermano, en plan de no tienen problemas entre C y Rust. Como no sea por la parte de C++, que quizás le diese más miedo el meterse y luego quizás que se les complicase o así. Pero aún así no deberían de tener tanto problema porque ya ha habido proyectos grandes de estos open source que han mezclado cosas de C++ con Rust y no han tenido tanto problema, en plan de les ha llevado su trabajo, lo que sea, pero que han podido. Es decir, que también se pueden ver como ejemplo de cómo hacerlo, si esa es la preocupación.

¿Te acuerdas de alguno de esos proyectos?

Así de memoria, si no recuerdo mal, había algo de, creo que era de Chromium, que la operativa pelea hicieron solo en uno de los sentidos. Y era en plan de, vale, pues que este pueda llamar a las cosas de este y lo demos en un solo sentido para simplificarlo al máximo. Que no sé si al final terminarían sacando adelante algo de eso, pero efectivamente me equivoco, pero creo que era Chromium que hizo las pruebas. Y porque poder se puede. Bueno, y en el caso mío de que era una mezcla de C y C++ y se podía comunicar sin problemas.

Y algún proyecto así grande, porque a mí me dejó marcada una frase de Richard Stallman, que cuando le preguntamos cómo ser mejores programadores, él nos dijo, sois escritores de código y los grandes escritores tienen que leer mucho. Así que leer mucho código para poder aprender. Y claro, eso me deja marcado, y cada vez que me adentro en un lenguaje nuevo siempre busco ese proyecto de referencia que todo el mundo dice, este proyecto es el que mejor ilustra cómo se programa en este lenguaje. ¿Hay algún proyecto así en Rust?

Pues esta es una pregunta difícil porque no he pensado en uno que digas, mira, esto es muy grande o conocido y que sirva así como de ejemplo, pero diría que, por ejemplo, Crates como los de Tokio o Tauri y toda esta gente, o incluso la propia librería estándar de Rust, suelen ser buenas referencias porque vas a encontrar muchas cosas comunes entre ellos, alguna que quizás estén diferentes, pero muchas cosas van a tener comunes. Y lo bueno es que también la propia gente de Rust y en sus propios libros, referencias y todo, dan también consejos de pues cómo tratar ciertas cosas, de qué forma, mismo para el semversion, dan sus recomendaciones. Porque por ahí se puede tirar. Lo bueno es que tiene mucha documentación Rust y facilita mucho tanto la documentación, testeo y todo esto. Son cosas donde le han prestado atención de principio. Mismo en otro lenguaje quizás, de tú si ya pones un ejemplo en el README o cosas así, pues te tienes que luego ir acordando a ver si eso sigue funcionando. En Rust tienes ya cosas preparadas para decirle, mira, me metes el README como parte de la documentación Rust del crate Y cuando ejecute los tests vas a ejecutar también los ejemplos del README. Y de esa forma nunca se te van a quedar desactualizados. Si se quedan desactualizados, se rompen los tests.

Teniendo en cuenta los sectores, me da la sensación de que tal y de donde surge Rust, con el tema de los microcontroladores, es donde más debería de brillar. Pero tú también has comentado otros, y aparte con la aparición de WebAssembly y Tauri, parece que puede brillar en muchos otros sitios. ¿Dónde consideras tú que puede brillar más a día de hoy Rust si decides utilizarlo?

De tener más brillo, diría que en servicios que necesitas que tengan muy baja latencia o que vayan muy bien, es decir, mismo cosas en tiempo real, cosas como algún juego que quieres hacer y que la comunicación tenga que ir muy rápida, o alguna aplicación que se quiera comunicar muy rápido, pues vas a tener ahí mucha facilidad para optimizar con Rust, que la latencia sea muy baja. Después, el tema de, por ejemplo, microcontrolador y todo esto, sucede un poco lo que decías con C/C++ de que la gente ahí quizás también te encuentras el sector más conservador, aunque después también hay gente que te hace sus manuales y sus cosas de cómo hacerlo. Es decir, puedes llevarte de verdad fácilmente incluso a un Arduino porque se han montado la gente para poder compilar para VR y todo. Pero los sitios donde vas a encontrarlo como más amistoso, en plan de que vas a encontrar más documentación, más cosas hechas y más comunidad, va a ser por el de hacer servicios, hacer cosas de escritorio, e incluso llevártelo a WebAssembly. También hay bastante comunidad por la parte de WebAssembly, que al final te permite cosas del estilo de me quiero hacer tal cosa para la parte de backend y que hay una parte de código, quizás hacer unas validaciones o alguna otra tarea que la podrías aprovechar aparte, llevártela al frontend para que primero le comprueben el frontend y luego le comprueben en el servidor, porque Al final es un entorno más seguro el servidor, no puedes solamente validar las cosas en el frontend, pero le estás quitando la latencia de hacer la petición. Pues normalmente tendrías que hacerte esa validación o lo que sea en JavaScript y en el lenguaje que tengas de backend. Con Rust podrías fácilmente eso, separártelo en su propio crate o lo que sea, utilizarlo en el backend y llevártelo con WebAssembly al frontend, y lo estarías reutilizando en los dos lados. Sí, también está útil para reutilizar cuando tienes cosas grandes que no quieres estar manteniendo en la lógica por dos lados, que al final alguien se olvida y tengas deteniendo una lógica en un sitio, espérate, que nos olvidamos actualizarla en el otro, o cosas del estilo. Y también para lo mismo con Tauri, para tener aplicación de escritorio y móvil. De esto dices quiero tener solo una y me lo quiero llevar a todos sitios, pues también brillaría mucho ahí Tauri.

Esto podría facilitar, por ejemplo, que se pudiera hacer un videojuego y tanto el servidor del videojuego como el propio videojuego poder hacerlo todo en Rust.

Sí, porque mismo también tienes, es decir, esto está más atrasado con respecto, por ejemplo, Unity, Unreal, de no tienes un editor gráfico así, pero tienes Bevy, por ejemplo, que si dices la parte de quizás del este del el cliente lo que se va a ver visual y todo esto, pues te lo haces quizás en Unity, Unreal o Godot porque te vaya a ser más cómodo con el editor, arrastrar nodos y cositas de estas. Pero podrías utilizar con Rust la lógica quizás del servidor, porque el servidor dices, pues en el servidor quiero algo que vaya muy rápido, que quizás necesitas hacer algo propio porque lo quieras hacer distribuido o cosas del estilo. Y dices, bueno, pues ahí tienes cierta lógica y algo quizás te lo quieras llevar para el otro, pues Con Daz puedes hacer el mismo plugin de Godot y todo esto, y podrías estar reaprovechando esa lógica entre ambos lados. Pues sí que es verdad que hay gente que se hace con Baby sus jueguitos y cosas así, pero entiendo que a nivel profesional, pues claro, no va a ser lo mismo alguien que se meta totalmente a código que el que ya tiene el editor y puede arrastrar, puede jugar con el editor, modelar y todo esto.

Es cuestión de ir haciendo mejores frameworks en caso de que se use.

Sí, no, y de que vayan avanzando, porque también hay que pensar de que pues Unreal, Unity, Godot llevan muchos años. Entonces, normal que tengan su editor y tengan tantas herramientas. Los de Bevy en cierto modo pues empezaron ayer, como quien dice. Es decir, hay que darles tiempo de que pues algún día lleguen a tener su editor o cosas de este estilo. Pero tiene también cosas interesantes Bevy por el tema de optimización. Si vas a hacer algo, quizás vas a manejar muchas instancias o cosas del estilo, y que puedes llegar a ver que quizás no se te quede un poco lento por el otro lado porque son más de lógica que de gráficos. Bevy orientó las cosas al esto, al ECC, de Entity Component System, y en principio eso optimiza mucho los rendimientos. Por lo que quizás alguien que diga es que yo el problema que lo tengo, el cuello botella en el procesamiento que hago de tantas entidades que tengo, que no de la parte gráfica, Puedes decir, pues mira, esto como encima lo voy a tener en servidor, pues quizás ahí metes WebV y dices aprovecho esto que vaya más optimizado. Y es cuestión de ir probando porque tampoco se puede ir así a decir, bueno, esto me han dicho que es más rápido, lo utilizo. Hay que luego ver cada caso concreto y medir, pero al final son más herramientas que tenemos en la caja de herramientas.

Bueno, hablando de herramientas, sé por ejemplo que lenguajes como el Dixie, el Go y demás No solo tienen el compilador, sino también tienen formateador, analizador sintáctico, herramientas para, en caso de Go, incluso de control de condiciones de carrera y otra serie de características. Ya con el compilador de Rust ya tenemos la parte de control de memoria, como bien has dicho varias veces, pero tiene algunas herramientas, tiene algunas herramientas más en su ecosistema.

Sí, tiene un linter para además irte avisando de otras cosas, tiene también formateador para dejar pásate el código formateado. Y lo bueno es que te viene ya de serie, es decir, tú simplemente te instalas Rust y ya tienes el cargo fmtm, es decir, el cargo fmtm, sí, el cargo keepy. Y con eso ya puedes tanto formatear como pasarle un linter extra para que te vaya diciendo más cosas. Bien, tío, se lo han montado muy cómodo de que sea simplemente, vale, te instalas Rust y mira, tienes estas herramientas ya listas.

Te viene ya el ecosistema con las pilas incluidas.

Sí, sí, prácticamente.

Otra cosa en tema de editores, recuerdo que hace poco, no hace poco, hace ya creo que un año o dos, salió, sabes, yo soy de los que intenta utilizar los nuevos editores que van saliendo y me voy desencantando cada vez que veo otra vez lo mismo pero mal, ¿no? Y recuerdo que cuando salió el Zed que es un editor que está construido 100% en Rust. Venía con las promesas de ser como Visual Studio pero consumir menos recursos y tener todas las características. Yo lo utilicé en una etapa muy temprana, pero la verdad es que me maravilló que tomando tan poca memoria era súper rápido y tenía prácticamente lo mismo que Visual Studio Code. ¿Tú utilizas este editor?

No, este de hecho no lo conocía, con lo que más acabas de descubrir algo con lo que ir a juguetear luego. Pero porque está súper interesante, yo normalmente utilizaba el Rust Robert, pero que vi que lo sacaron en alfa y todo esto para hacer PEB, digo, pues vamos a probar a ver qué tal va eso. Y también con VS Code también he programado en Rust con eso, y en principio van bien. Es decir, en serio, no le va a pasar a nadie de decir, ostras, que para programar en Rust el editor no me reconoce nada, voy a ciegas. Os utilicé bastantes editores con los que poder trabajar sin problemas y que están ya bien establecidos. Y después, si digo, pues van saliendo como este que comentas, pues mejor todavía. Si pueden mejorarnos la memoria y todo, estaría bastante bien. Porque una de las que suele pasar con los editores y los IDEs, sobre todo como Rust y todo esto, que llega un punto donde todas las memorias se les hace pocas y al final dices, pues bueno, reinicio o cierro todo y vuelvo a abrir a ver si ahora ya quiere volver a ir como cuando lo abriste.

Me parece que tienen algunos leaks de memoria.

Sí, no, y a veces se vuelven lentos con el uso. Esto que al principio va todo muy rápido, luego das una tecla y esperas medio segundo y la ves salir y dices, vale, voy reiniciando.

En este caso yo, vamos, me quedé con la espinita porque cuando empecé a utilizar Visual Studio Code tenía muchas extensiones Es decir, muchos ejemplos que te facilitan el crearte tu propia extensión. Y Zed, si no me equivoco, porque esa parte la tengo un poco cogida con pinzas, te permite hacer las extensiones tanto en JavaScript como en Rust, o simplemente en Rust, o depende de cómo haya ido progresando, ¿no? Pero creo que te lo permite en Rust. Así que vamos, si tienes soltura con Rust, yo creo que te puede ser más fácil personalizarte O hacerte ciertas extensiones que necesites para automatizar.

Bueno, eso está interesante. Si necesitas extensiones que requieran rendimiento o así, pues lo bueno es que, como también he tocado, está escrito esto, pues está abierta también la posibilidad de personalizarse el visual y esto. Pero está interesante que al menos den más alternativas, y sobre todo en ese aspecto de que digan vamos a intentar darle un editor y que consuma menos. Porque ahora los editores como emprendedores, bueno, vamos a darles más herramientas, ahora metemos el Copilot, metemos esto, y en plan de, vale, me vas a meter un poco más de RAM también ya de paso. Lo único que les falta.

Bueno, pues yo me he quedado ya sin preguntas, pero la verdad es que ha sido bastante fructífero. Me he divertido bastante hablando de rastreo con alguien que tiene experiencia profesional y he aprendido un montón. Lo mismo no le ponga algo en práctica, ya te Ya te lo sabes. Y muchas gracias por estar aquí. Bueno, si quieres decir algo para despedirte.

Nada, que muchas gracias por invitarme, que ha estado entretenido hablar de Rise, que cualquier cosa, cuando quieras juguetear con Rise o cualquier cosa, me vas diciendo, que ya estoy aquí.

Estamos en contacto. Pues muchas gracias por habernos escuchado y haber estado ahí otra semana más. Ya no publicamos con tanta frecuencia, pero se va intentando. Y nos vemos en el siguiente capítulo.