Go y Rust con Miguel Ángel Ortuño

Pues buenas, una tarde más, bueno, cuando te pilles exactamente escuchando Codeadores. Estamos aquí hoy con Miguel Ángel Ortuño. Yo conozco a esta persona desde hace muchísimos años. La verdad es que no hemos tenido un contacto continuo, pero nos tenemos en LinkedIn, nos vamos conociendo, sabiendo de por dónde vamos y dónde estamos de vez en cuando. Es un placer tenerte aquí y Vamos a empezar con las primeras preguntas. En principio, o sea, yo te he presentado un poco, pero si quieres decir algo más sobre ti, adelante.

Bueno, sencillamente así muy por encima, sí, nos conocimos ya hace ya casi unos, yo creo que más de 10 años, en Murcia trabajando en una startup. Y bueno, desde entonces pues han cambiado mucho las cosas y Y bueno, con ganas aquí de charlar y ponernos un poco al día sobre tecnologías y lenguajes que, vamos, que toco a día de hoy, que tocaban en aquel entonces. Así que a ver qué sale de aquí.

Yo cuando te contesté en principio tenía en mente Objective-C y Swift porque, vamos, te hacía sobre todo programador de iPhone, pero me dijiste que llevas sobre todo 6 años con Go. Vamos, yo te recuerdo el proyecto este que empezaste de Cal, que creo que ya lo abandonaste.

Sí, sí, sí, demasiado, demasiado tiempo. Sí, al final he ido pasando por muchos, por muchos sectores diferentes. Entre ellos, al final, inicialmente estaba con toda la parte de frontend. También, bueno, estuve una temporada programando en una empresa de videojuegos. Pero sí, al final, desde aquel entonces ha cambiado un poco el tema. Hubo un momento, un episodio en concreto en que al final pues montamos una startup, una pequeña startup con yo y unos amigos. Y lo típico, al final era necesario gente en el backend, y pues yo en aquel entonces me dedicaba plenamente a desarrollar en iOS. Ya había pasado de Objective-C a Swift, pero claro, necesitaban gente y decían, bueno, ¿y ahora qué? Y por aquel entonces estaba Go, así se empezaba a oír las primeras campanas. Seguía siendo un lenguaje extraño, pero dije, bueno, qué mejor momento que ahora, que vamos a empezar desde cero. Y sí, empecé ahí y ya me metí con Go y he estado desarrollando desde entonces. A día de hoy sigo utilizándolo en mi día a día, o sea que tengo bastante experiencia con con ese lenguaje en cuestión. Y sí, ahora ya digamos que de iOS y del mundo Swift ya poco, poco o nada, ya sé.

Pero bueno, te moviste principalmente porque hacía falta alguien en el backend, y a partir de ahí pues ya viste que era mejor mantenerse en backend que ir buscando otros tipos de trabajo.

Sí, a ver, al final también el backend era algo que me había atraído siempre porque era para mí era como una caja negra, y decía bueno, pero Pero siempre al final, cuando, especialmente cuando estás empezando una startup, los mayores retos entre comillas estaban ahí, ¿no? Porque la parte, digamos, de aplicación de iOS en la que yo trabajaba era bastante sencilla. Además, ya por aquel entonces ya creo que llevaba, estuve unos 7 años creo, o sea, también estuve un tiempo programando para smartphones. Y digamos ya poco o nada tenía que aprender nuevo. Siempre, obviamente, siempre hay cosas nuevas que aprender, pero ya no me motivaba tanto. Entonces sí decidí dar el salto y al final lo di. Tuve la suerte de poder elegir en qué lenguaje o en qué tecnología quería desarrollar el backend y decidí hacerlo por Go. Por aquel entonces yo tenía cierta experiencia con backend, pero muy, digamos, muy elemental. Cuando ya tocaba algún lenguaje de programación era PHP o Ruby y no me gustaba. Definitivamente no eran lenguajes que me llamaran mucho. Los veía como muy— bueno, si quieres hablamos un poco del background que yo tenía, pero digamos que yo venía— a ver, yo empecé a programar, digamos, cuando tenía— mi primer acercamiento a la programación fue con 13 años, un profesor, me acuerdo que quería, creo que como mucha gente que se mete en el mundillo, al final quieres decir, bueno, yo quiero hacer un videojuego, aunque sea muy sencillo, pero yo quiero hacer un jueguito en casa. Y al final pues claro, te dicen, ¿y cómo puedes hacerlo? Y dices, bueno, pues tendré que aprender a programar. Y en aquel entonces la verdad es que no había muchos recursos. Yo recuerdo preguntarle a un profesor de tecnología en aquel entonces que tenía cierta experiencia Y él tenía un libro de Pascal, así que me dio el libro. Pero claro, yo en aquel entonces creo que utilizaba Turbo Pascal, creo que me quiere sonar, pero básicamente era algo muy diferente, ¿no? Tenía, me faltaban muchos conceptos, se daba por hechos, digamos que el libro era de un nivel medio. Entonces yo no terminaba de entender bien por dónde iban Todas aquellas explicaciones. Entonces recuerdo encontrar un libro, a lo mejor a ti te suena, que era Lenguaje ensamblador del 80-86 de John Beltrán Heredia, que luego fue posteriormente— sí, ahí lo tienes, ese, ese, ese, que todos los ejemplos de hecho estaban estaban en MS-DOS. Bueno, al empezar desde algo tan elemental, desde algo tan básico como era una CPU con unos registros y unas celdas de memoria, eso yo sí que lo entendía. O sea, yo decía, vale, esto, vale, yo sé que estoy moviendo datos de un lado a otro. Entonces recuerdo que los primeros, digamos, programitas o utilidades que desarrollé fueron en ensamblador para MS-DOS. Cosas muy sencillitas, o sea, dibujar figuras geométricas muy elementales en la pantalla, en el modo de texto, jugar un poco con el modo de texto del MS-DOS, bueno, entender el concepto de interrupciones y todo aquello. Y todo eso me gustó, o sea, fui poco a poco pues, digamos, cada vez aprendiendo más, incluso desarrollando en arquitectura de en el modo protegido del 8086. Llegué a hacer aplicaciones en Windows, lo que pasa es que ahí ya no era tan divertido porque básicamente lo que estaba haciendo constantemente era mover datos de una función a otra, de una DLL a otra, de una librería a otra, y ya no, todavía estaba todo muy, muy, muy encorsetado. Tú sabes que el MS-DOS al final aquello era, uno podía hacer lo que quisiera con la máquina, era una maravilla. No tanto para los usuarios, pero para los programadores era genial. Así que luego posteriormente, cuando ya empecé a estudiar, recuerdo que nos iniciaron en C y es cuando, digamos, di el siguiente paso. Entonces todo lo que me molestaba del ensamblador fue cuando con C dije, ah bueno, esto es una maravilla, ahora ya entiendo por qué la gente inventó esto. Curiosamente, luego cuando se hacía referencia al tema de punteros y demás, mucha gente tenía problemas en entender el concepto. Y para mí era, yo básicamente siempre trataba de ver cómo se traduciría. Obviamente yo no conocía, no hacía la traducción directa, pero más o menos podía imaginarme cuando estaba desarrollando en C cómo se traduciría eso al código ensamblador. Así que sí, o sea, con el C estuve una larga temporada y posteriormente, bueno, ya tengo que C++, que fue con lo que entré en el mundo laboral. C++ nos lo enseñaron en la carrera, más de lo mismo, fue como el siguiente paso. Fue decir todo lo que me molestaba de C o que me, digamos, no me gustaba, lo tenía en C++. Aunque bueno, luego ya eso se convirtió, luego fue al contrario, fue pasando el tiempo y dije pues a lo mejor C++ no está tan bien como a mí me lo habían vendido. Así que yo entré en el mundo laboral con C++, inicialmente en una consultora. Teníamos una serie de procesos batch y demás, no entendía bien por qué, pero se decidió escribirlos en C++. Y ahí estuve un año desarrollando en C++. Entonces yo me acuerdo que me quedé con la espinita de decir, bueno, yo quiero hacer algo relacionado con el mundo de los videojuegos. Y fue cuando ya salté, al final conseguí trabajo en Alicante en una startup gracias a un amigo, que se encargaban básicamente de portar, en aquel entonces estaban en auge los smartphones y los jueguitos casuals que se llamaban, Y entonces había muchas empresas que lo que querían era coger muchos juegos que tenían ya desarrollados para desktop y hacer el porting a smartphone. Entonces yo me metí ahí y ahí aprendí, vamos, aquello fue una maravilla porque aquello era el salvaje oeste. Yo tenía, te daban un proyecto y recuerdo que lo único que te daban era el código fuente original, no te daban nada más. Y me acuerdo que un compañero me dijo No te preocupes, esto es abrumador, pero tu objetivo ahora mismo es conseguir que el proyecto compile. Da igual cómo lo hagas, pero ese es el primer paso. Y estuvo muy bien. Al final te tirabas, no sé, 2, 3, 4 meses con un único proyecto solo haciendo el porting. En ocasiones el porting era directo, es decir, lo único que tenías que conseguir era que el código compilara y poder utilizar las librerías, a lo mejor reemplazar unas por otras, pero bueno, adaptar alguna interfaz para poder hacer uso de determinada librería. Otras veces no era tan directo y tenías que reajustar algún asset, editar algún nivel, algún sonido. La verdad es que fue, la experiencia fue enriquecedora, fue muy enriquecedora. Pero, ¿qué pasa? Que yo en aquella startup como desarrollábamos para iOS, había cierta, digamos, había una capa muy fina de Objective-C de la que no te podías librar. La mayor parte del código de los juegos siempre estaba hecha en C++, pero claro, esa leve capa de Objective-C, al final tenías que aprender un poquito cómo funciona Objective-C, familiarizarte un poco con Objective-C, y eso fue lo que me llevó luego posteriormente a la empresa en la que trabajamos tú y yo. Que era una startup básicamente que se dedicaba a todo el tema de una aplicación de VoIP, que por aquel entonces también estaba muy de moda, parecido a WhatsApp, o se pretendía que fuera. Bueno, los que hemos vivido aquella época sabemos que los móviles al final los teníamos inundados de aplicaciones del estilo, y la nuestra pues era una más. Y ahí ya sí que desarrollaba mayormente en Objective-C. Sí, el C++ se tocaba un poquito, pero muy poco. Y bueno, desde entonces, ¿qué es lo que pasó luego? Al poco, como te digo, monté junto con unos compañeros, montamos una startup, y en la startup yo estuve trabajando inicialmente en iOS, donde tocaba mayormente Swift, que al final fue como otra progresión. Vengo de Objective-C, Swift se supone que es el reemplazo de Objective-C, obviamente una maravilla. O sea, todo, todo lo que dolía en Objective-C, en Swift ya no dolía. Era un lenguaje moderno y eso se agradecía. Era un lenguaje compilado, eso siempre yo, a mí el tema al final de los, no era muy amigo de los lenguajes no tipados. Y el scripting me da un poco igual, pero el no tipado era algo que me dolía mucho. Entonces Swift me pareció una maravilla. Y sí, y como te he comentado, ahí es donde en un momento concreto necesitábamos desarrollar toda la infraestructura de backend y no había gente, así que yo me puse con ello. Y como era yo quien decidía qué lenguaje, porque no había nada escrito, Claro, tenía sobre la mesa PHP, Ruby y Go. Y Go estaba también, leí, o sea, me informé bastante sobre Go, me documenté, leí bastante sobre el tema de la concurrencia. Y ya te digo, en aquel entonces Go no era un lenguaje muy, se comentaba, se hablaba del lenguaje Go, del lenguaje de Google, pero nadie, no había grandes proyectos referencia o empresas que trabajaran exclusivamente en Go. Así que nada, me puse con ello y Y prácticamente hasta la fecha.

Yo que te hacía mucho de frontend y de ahora me voy dando cuenta de que eres más de backend, e incluso bajo nivel.

Sí, o sea, lo que pasa es que tengo, yo diría que ahora mismo si miro atrás, mi carrera se divide mitad y mitad. Hay un momento que doy el salto y obviamente ahora sí me gustaría, a veces echo de menos muchas cosas de frontend, pero bueno, imagino que si me hubiera quedado en frontend yo hubiera llegado a un punto en que me hubiera, digamos, estancado y eso no.

En frontend te refieres principalmente a dispositivos móviles, ¿no? En interfaz de web, a menos que utilizas TypeScript, no creo que ninguno otro.

No, en la parte de web sí que no la he tocado. Levemente al inicio alguna historia de Java, pero los famosos beans y demás, pero no me considero que haya sido algo en lo que he profundizado. Al igual que cuando, por ejemplo, estábamos en esta startup tratando de, estaba probando qué tecnología, con qué tecnología desarrollar el backend. Inicialmente toqué un poco de Node, pero no me considero, no considero que sea una tecnología que domino ni que conozco.

Cuando estuvimos hablando de hacer las charlas, me comentaste también que te estabas adentrando en Rust.

Sí, llevo aproximadamente un año tocando, adentrándome en Rust. Muy parecido a Go, al final es algo, lo estás oyendo, estás leyendo, identificas algunos pains en Go que luego ves en Rust que no existen. Principalmente todo lo relacionado con el garbage collector, pero bueno, obviamente también luego hay muchas cosas de Rust que no, al igual que en Go, que no que no, digamos, no me encaja mucho. Pero bueno, es muy interesante para mí. La verdad es que creo que me gusta mucho Rust, sobre todo porque me parece innovador en el sentido de que está planteando, está poniendo cosas diferentes encima de la mesa. Ha identificado unos problemas y ha dicho, pues yo los voy a arreglar, este es mi modo. A lo mejor hay gente que no le gusta, es difícil, es A veces se hace imposible, pero sí que es verdad que al final la intención, sobre todo en todo lo relacionado con el memory safety y vulnerabilidades, se está viendo a día de hoy que cada dos por tres siempre siguen, o sea, siempre que sale una vulnerabilidad siempre suele ser por los mismos motivos. Entonces cada vez que veo ese tipo de noticias digo, más razón para que la gente empiece a tocar un poco de Rust. No vale para todo, eso es el problema que hay, Hay gente que trata de encajar una tecnología, un lenguaje de programación, en convertirlo en una especie de navaja suiza que te puede solucionar cualquier cosa. No es el caso para nada de Rust, al igual que Go. Luego si quieres comentamos, pero yo a veces como que la gente dice, bueno, pero pues lo hago todo en Go. No tienes por qué. Pero me parece muy innovador en ese aspecto, la verdad. Me parece que trae aire fresco. Supongo que con el tiempo puede surgir algo parecido, algo mejor, pero a día de hoy la verdad es que, sobre todo comparándolo con C o C++, creo que es el mal menor, como dirían. Así que sí, últimamente llevo un año, se hace tedioso, la verdad. No es la curva de aprendizaje comparada con Go, no tiene nada que ver, pero sí, o sea, le encuentro mucho valor.

Si tuvieses que empezar un proyecto como cuando hiciste Jackal, por ejemplo, que era un proyecto de servidor implementando un protocolo específico, ¿lo harías a día de hoy en Go o lo harías en Rust?

Supongo que depende. Por ejemplo, el proyecto que mencionas, Jackal, que es básicamente está basado en, es un servidor XMPP, para nada lo haría en Rust, porque al final no deja de ser un protocolo muy extenso y el desarrollo e iteración en Rust es algo lento. Digamos, obviamente cuando va pasando el tiempo eres más productivo, pero al final no eres para nada igual de productivo que lo puedes ser en Go. Si el protocolo fuera algo sencillito, muy liviano, algo que no sé, binario, donde tienes 4 o 5 comandos, los casos de uso están muy bien definidos y es algo que digamos yo estoy creando de la nada, entonces sí, tal vez me plantearía hacerlo en Rust desde un inicio. También depende de en qué circunstancias, es decir, si todo esto se está haciendo porque tenemos una startup y deseamos lanzar un producto a mercado lo antes posible, me parecería una locura empezar a desarrollarlo en Rust. Para nada, no es lo que haría. Así que pues al final dependería, no diría lo hago en este o en aquel, yo creo que dependería mucho de las circunstancias. Así que volviendo al caso, al ejemplo, depende de lo extenso que fuera el protocolo y de qué necesidad hubiera, de por qué estoy lanzando ese producto, por qué estoy haciéndolo. Si es un side project que estoy haciendo yo por mi cuenta donde puedo estar años desarrollándolo Bueno, puede tener más sentido hacerlo en Rust, pero para el caso específico de XMPP, que es un protocolo que es enorme, y tú lo sabes, es un protocolo, vamos, gigante, sería muy tedioso. Necesitaría un buen equipo de gente alrededor. Hacerlo yo solo—

Y hablando así en general, tanto de Go como de Rust, ¿qué es lo que te atrae de cada uno de esos dos lenguajes?

Pues de Go, sencillamente la simplicidad. Digamos que es, para resumirlo, yo siempre digo que es como un lenguaje que es el que más se acerca al scripting sin serlo, pero a la vez te da todo, todo ese poder del lenguaje. El rendimiento al final es muy alto, entonces Go, por ejemplo, es muy fácil iterar, se es muy productivo en Go, entre otras cosas porque es un lenguaje muy sencillo, casi minimalista diría. Donde eso a la vez hay mucha gente que lo que hay mucho detractor alrededor de diciendo que el lenguaje es demasiado simple, pero Go, la verdad es que iterar en Go es una maravilla. O sea, tienes una idea en la cabeza y tardas muy poquito en implementarlo. Y además lo tienes y luego lo pones en producción y tienes un servicio que está a la altura, está muy a la altura, sobre todo comparado con otros lenguajes de programación u otras tecnologías como PHP o Ruby. Así que eso diría que es lo que más me atrae de Go. Con respecto a Rust, al final lo que te he mencionado, toda la parte del memory safety, por el hecho de saber que tú tienes un programa y que siempre va a haber bugs. Hay gente que piensa que programar en Rust es como no tener bugs, para nada. Pero si volviendo al ejemplo del protocolo, si al final lo que estás implementando, por ejemplo, es un protocolo de comunicación muy sencillito donde haces un parseo de la entrada, por lo menos estás tranquilo de que ese parsing no te lo van a romper, en cierto modo. Así que eso es lo que Rust te da, la certeza de saber que tu producto final final es seguro, siempre y cuando la seguridad sea algo relevante para ti, que eso es otra. Por eso digo que al final todo depende de para qué lo vayas a utilizar. Pero sí, Go es que es, yo lo utilizo en mi día a día y es muy fácil prototipar, escribir tests, iterar, cambiar, es muy fácil. Y a la vez pues eso, tienes todos los beneficios del propio Go.

Y ahora sacando un poco los trapos sucios, o sea, ya llevando 6 años programando con Go, algo malo habrás visto. Sí, sí, sí.

Yo, por ejemplo, sí que es verdad que a veces, bueno, por ejemplo, nosotros en la empresa en la que trabajo, en producción, constantemente estamos lidiando con el garbage collector, ¿no? Y con que, por otro lado, es el beneficio, ¿no? Pero sí que es verdad que a veces cuando quieres ir un poco más abajo y bajar de nivel, y por ejemplo evitar que ciertos ciertas allocations tengan lugar o no tengan lugar. En Go es muy difícil, o sea, tienes que al final, tienes que aparte de informarte mucho, es que llega un momento incluso en que no puedes optimizar, no puedes ir más allá. Un ejemplo claro que, por ejemplo, que nosotros tenemos es que el inlining de las funciones, al final eso es bueno cuando el compilador decide si llamar a la función o no para que para que el código sea más rápido es algo en lo que tú no puedes decidir como programador. A bajo nivel se asume que eso no es algo que tú vas a determinar en ningún momento. Creo que puedes forzar que no haga inlining, pero no puedes forzar el inlining. Entonces hay por ahí artimañas, trucos entre comillas, que la gente ha ido desarrollando a lo largo del tiempo para poder, digamos, de alguna manera hacerlo. Entonces sí que es verdad que a veces me encuentro peleándome con eso, con ese aspecto de Go, que al final se asume que eso no es necesario. Pero bueno, luego en el mundo real ves que sí, sí que es necesario, sobre todo cuando estás tratando con servicios en producción, con alta carga y demás. Es algo que que yo personalmente he echado mucho de menos. La justificación es como que no queremos, no queremos hacer que el programador se dispare en el pie. Hace poco, por ejemplo, hubo una propuesta en el lenguaje para implementar el concepto de memory arenas, donde alocas un gran bloque de memoria y en lugar de ir al heap a reservar memoria, vas extrayendo memoria del del bloque y lo tiraron para atrás. Creo que está como experimental, pero todo pinta que lo van a rechazar. El razonamiento al final es que si metes harinas en el lenguaje, ya no es un lenguaje, es muy probable que ya no sea tan memory safe como lo venden. Aunque es mentira, porque luego hay otras formas de dispararte en el pie utilizando Go. Así que pues sí, eso es lo que a veces echo en falta. Sí que es verdad que ciertas cosas también, por ejemplo la gestión de errores, sí que creo que puede haber soluciones más expresivas, o digamos no tener que repetirte una y otra vez. Es algo también de lo que siempre se mofan muchos detractores de Go, y sí que creo que bueno Podría alguna propuesta con sentido, podría existir y nos ahorraría el tener que leer siempre las mismas líneas de código una y otra vez. Pero bueno, es algo que tampoco me duele. Y hoy en día los autocompleteres lo hacen muy bien, o sea que no pasa nada. Así que sí, eso es lo que respecto a Go, eso es lo que más Digamos, hecho, a veces me duele el decir que, pero bueno, los beneficios al final superan, superan con creces a esos dolores. Al final, no sé dónde leí que al final Go se pensó como un lenguaje para ser leído, no para ser escrito. Y eso también es el recuerdo de ver recientemente un vídeo de un youtuber hablando de Go diciendo, es que Go me hace sentir tonto. Y a mí me llama la atención de decir, bueno, es que al final, o sea, el lenguaje de programación en concreto no está ahí para que tu ego, para que tú alimentes tu ego, no está ahí para que puedas arreglar problemas, que es a lo que nos dedicamos, solventar problemas. No está para que seas más listo o más tonto. Pues sí, a lo mejor es que lo mejor es que todos seamos tontos, entre comillas. Y ya está. Que un poco va por ahí la filosofía, la filosofía de Go. Creo recordar también que inicialmente se planteó el Go como lenguaje, fue desarrollado porque tenían en Google, tenían mucho, mucho código en C++, y C++ es un lenguaje que no se termina de aprender nunca. Entonces puedes tener expertos, pero si tienes al final 200 programadores, no puedes tener 200 expertos en C++. Y es muy, muy fácil que alguien la cague. Al final prefieres, prefiero yo personalmente también que nos traten como tontos si al final eso se convierte en un beneficio.

En ese aspecto yo creo que Google ha intentado, o sea, no solo con Go sino también ahora con la iniciativa esa de Carbón de eliminar tan pronto como sea posible C++. Creo que su objetivo es reemplazar todo el código del buscador, que es lo más antiguo que tienen hecho todo en C++. Y ya, bueno, imagínate las millones de líneas de código que hay escritas solo en C++ y que tienen que ir manteniendo. Y que realmente yo creo que poco a poco les puede ir pasando como en COBOL, de que C++ realmente no es un lenguaje muy atractivo. No hay mucha gente que finalmente quiera dedicarse a ese lenguaje porque hay otras opciones más asequibles como Go, Rust. Y claro, tiene mucho código que mantener y cada vez hay menos gente que se pueda contratar, por lo cual el mantenimiento se va encareciendo.

Sí, totalmente. Ahí ya depende de lo que busques, ¿no? O sea, hay gente, yo he conocido en el sector, al final he conocido gente que aprende los lenguajes, no los aprende porque les interesen, sino porque por la oferta que hay en el mercado, ¿no? O sea, Al final me parece muy bien. O sea, yo estoy de acuerdo. Yo creo que C++ perfectamente puede ser un lenguaje de nicho al día de mañana por el que se pague mucho, porque la cantidad de código legacy que va a haber en el mundo va a ser, va a ser, vámonos, va a dar miedo, ¿no? Entonces sí tiene pinta, ¿no? Yo creo, creo que se están, la comunidad de C++ está tratando de evitar eso, ¿no? Hace poco leí que ya había una propuesta para la nueva edición de C++ donde iban a incluir un borrow checker, básicamente lo que tiene Rust. Claro, ellos son conscientes de que, de que al final el lenguaje tiene, tiene serios problemas. Se está viendo todos los días, da igual lo que digas en una conferencia, que al día de mañana te salió otro exploit de seguridad y resulta que es por por cómo es C++. Entonces sí, claramente es un problema para toda la industria, y ese es el motivo por el que al final lo que se desea es tener una solución que sea igual de eficiente en términos de rendimiento, pero que no implique el tener que asumir tantos riesgos o el tener que confiar en que tus programadores sean auténticos genios. Que eso también a veces he visto que hay mucha discusión de, no, es que no sabes utilizar el lenguaje. Pero tío, no puedes decir eso, no puedes decir que no se sabe utilizar el lenguaje. Y es que es curioso, al final todo eso es lo que da origen al inicio de Rust. Creo que vi una entrevista también recientemente de John Carmack El creador del Doom. Estamos hablando de uno de los tipos que más ha programado a lo largo de su vida en C++, principalmente en C, pero en C++ también un poco. Y el tipo confirmaba que decía básicamente una frase, y es: cualquier cosa que semánticamente sea posible en tu lenguaje, en el lenguaje que utilizas, tarde o temprano acabará apareciendo en un codebase compartido. O sea, al final tienes gente alrededor Da igual, o sea, si puedes asignar una variable a un puntero null, eso va a pasar en tu código tarde o temprano, no te preocupes. Y hay que asumir que eso es así. Entonces es muy difícil, sobre todo para hacer, o sea, es muy difícil para C++. No sé, es un tema que obviamente la gente que programa en C++ Pues puedes estar de acuerdo, no, no, al final con esa idea, pero es una realidad, es innegable. Las probabilidades de dispararte en el pie utilizando C++ están ahí y están por las nubes.

Y sobre Rust, decía que lleva poco tiempo, o bueno, cerca de un año así dándole un poco a a ese aprendizaje poco a poco. ¿Marcaría la dificultad como la curva de aprendizaje, o ya he encontrado algunos dolores que te digan esto no nos gusta mucho?

La curva de aprendizaje está ahí, pero bueno, con paciencia al final se automatizan. Llega un momento en que te acostumbras, y como en todo lenguaje, y empiezas más o menos a Pillas el mindset, por decirlo de algún modo, y llega un momento en que ya eres más ágil a la hora de desarrollar. El tema es lo que ocurre con Rust es que al final, digamos, tienes como un diagrama en el que tienes todas las posibles aplicaciones, y luego dentro de esas aplicaciones estarían lo que se considerarían aplicaciones seguras, donde por el diseño propio de la aplicación no puede haber problemas de de memoria, el use-after-free, leaks de memoria, todo lo típico. Pero el problema es que Rust, por cómo está pensado, no te permite desarrollar todas esas aplicaciones seguras, solo te permite un subconjunto. Entonces, en ocasiones tienes que forzar un poco, retorcer un poco el lenguaje, o incluso replantearte cómo estás definiendo la arquitectura interna de tu aplicación para poder encajarla dentro del modelo de Rust y que pueda, y que pueda poder utilizarlo. Yo un ejemplo que tengo en mente, por ejemplo, un caso era, bueno, al final tenían una típica estructura donde había muchas autorreferencias de punteros dentro de la propia estructura, y al final cuando fue iterando, iterando, iterando, al final lo que de algún modo lo que Rust me obligó a hacer fue en lugar de utilizar esos punteros es utilizar lo que se llamarían handlers, con los que yo gestionara. Entonces al final tienes un componente, un sistema al que le pasas esos handlers y el sistema por debajo es el que hace toda la gestión de operaciones. Claro, tú lo piensas y dices, claro, es que así es memory safe, claro que sí, no estoy utilizando punteros. Pero Rust al final te acaba empujando, el propio lenguaje, a ese tipo de cosas. Entonces, pues eso es, al final sí que, sí que digamos se agiliza un poco, pero bueno, al final te tienes que dar de golpes de vez en cuando y tener que replantearte cómo estás haciendo la cosa, a pesar de que ya el borrow checker al final es algo con lo que te acostumbras. No es tan difícil, o sea, no es nada del otro mundo. Esencialmente es cambiar un poco el chip, por decirlo de algún modo. Pero sí, va más allá del borrow checker al final Rust. En ocasiones tienes que replantear completamente cómo has definido tú la arquitectura de tu servicio, aplicación, de lo que sea.

Si tuvieses que cambiar algo de estos lenguajes, de Go y de Rust, ¿Qué sería?

En Go, lo que te he comentado, ¿no? Al final, abrir una ventana a poder de vez en cuando incluso a lo mejor gestionar tu propia memoria en scope muy limitado, bajo el conocimiento de que si haces algo mal vas a reventarlo. Pero bueno, es así, ¿no? Es como tener esa pequeña salida para poder de algún modo en casos muy específicos de servicios en producción, por decir, bueno, pues lo necesito y quiero hacerlo y no pasa nada, o sea, cuento con ello. Y en el lado de Rust, pues sí que es verdad que he hecho, a veces echo en falta pues un poco algo más, la sencillez, ¿no? La sencillez que tiene Go es justo lo que a veces echo en falta en Rust, porque Rust es muy expresivo, puedes hacer puedes escribir una función de mil maneras que básicamente hagan lo mismo. Y eso, claro, al final para mí es algo que he aprendido a apreciar. Me gusta ver un código— lo bueno de Go, perdón, es que si hay un algoritmo, da igual quién lo escriba, los dos básicamente lo vamos a escribir de la misma manera. Entonces eso al final, sobre todo a la hora de revisar PRs y cambios en el código, pues te facilita mucho el trabajo. Entonces sí que es verdad que en Rust pues eso, a veces las cosas están un poco más, son más complejas. Por ejemplo, en Go todo el tema de librerías, al final lo que es el estándar library te cubre un montonazo de protocolos y de herramientas y de librerías que en Rust, bueno, al final tienes Cada uno viene de un sitio diferente y cada uno con una filosofía diferente. Entonces, pues eso, tienes que amoldarte.

Entonces, Rust da la sensación de que en las dependencias no hubiese una filosofía común en comparación con Go, digo.

Lo que pasa es que el estándar library de Go es enorme, es enorme. Y cubre muchas de esas dependencias que en Go hasta para el mínimo cambio necesitas recurrir a una librería. Entonces, y al final todas esas dependencias están mantenidas, no mantenidas, lo típico, ¿no? Entonces, bueno, lo hace un poco más complejo en ese sentido, sí.

Y si alguien llegase, o sea, supongo que te habrá llegado mucha gente en estos años de que saben que programas en Go y dicen, oye, yo también quiero programar en Go, ¿qué recomendaciones me das?

Bueno, lo primero, lo bueno de Go es que tienes, creo que se llama, si buscas Playground en, a ver, sí, si buscas Golang Playground, directamente tienes una, aparecerá una página web donde puedes escribir pequeñas líneas de código y trastear. A día de hoy, en ocasiones, cuando tengo dudas, alguien me hace una pregunta y, ¿qué pasa cuando haces determinada cosa o no? A veces yo directamente pongo el ejemplo en el playground y ahí ves el resultado directamente. Es muy ilustrativo el concepto del playground. Pero bueno, la verdad, lo bueno de Go es que se aprende muy rápido. Hay una guía oficial del propio Golang, de Google. Bueno, ya no es de Google, pero en su momento era de Google cuando yo lo leí, donde básicamente te describen el lenguaje como lo típico. Y en el caso de Go es que al ser tan minimalista, tan sencillo, se aprende muy rápido. Entonces, algo como montar un servicio HTTP con un par de endpoints sencillitos en Go se hace muy, muy rápido. Lo puedes perfectamente hacer en una tarde. Sin tener un conocimiento excesivamente amplio. Entonces yo empezaría por ahí, montarme un servicio sencillito. Lo bueno de Go es que, como te he dicho, en la librería estándar cubren un montón de posibles dependencias, con lo cual no es como Rust, donde sí que de pronto digo, ah, vale, me quiero hacer un servicio HTTP. Bueno, pues ahora tienes que buscar qué librería puedo utilizar. Bueno, y luego el Rust tiene todo el mundo del async await, que en Rust es una locura. Entonces eso, por ejemplo, en Go no lo tienes. No tienes que aprender todo cómo funciona todo ese modelo de async await. En Go directamente con la librería estándar te puedes montar un servidor HTTP con sus 4 endpoints ejemplos muy facilitos, muy facilitos. Que yo empezaría por ahí, leyendo el la guía de iniciación, haciendo algún trasteo en el playground para más o menos familiarizarte, desarrollar luego en local si quieres un pequeño servicio HTTP directamente con la propia librería estándar. Y luego lo que siempre recomiendo es que al final, lo hago también con Rust, yo como más aprendo es leyendo código. Yo sé que la gente dice, pero tengo que programar Luego, por supuesto, tienes que escribir código y tienes que programar y tienes que desarrollar y pelearte con el compilador, eso siempre. Pero a veces se aprende muchísimo simplemente leyendo código y viendo cómo, sabes, cómo, cuál es la, digamos, la forma idiomática del lenguaje, cómo se hacen las cosas, cómo se estructuran los proyectos. Ese tipo de preguntas, tan cosas tan elementales, es algo que Que yo generalmente siempre aprendo viendo, leyendo código. Entonces, no sé si conoces, pero bueno, Awesome Go, están estas páginas que básicamente son como índices donde te recopilan una serie de proyectos en GitHub que creo que está para— no sé si inicialmente el original fue Awesome Python, pero bueno, a día de hoy ya existe Awesome para cualquier para cualquier lenguaje de programación. Tú pones en el buscador de Google Awesome espacio el lenguaje de programación que te interese y lo que vas a ver es un índice de proyectos open source que puedes utilizar, descargar. Y yo lo utilizo mucho para leer. Oye, pues quiero saber cómo demonios se monta un servicio, no sé, un servidor de una base de datos, o cómo desarrollar una base de datos en Rust. Pues mira, voy a meterme en el código de Y no tienes, obviamente no tienes que entenderlo, digamos, todo lo que estás leyendo. No tienes que conocer todo el dominio de esa aplicación en cuestión, pero leyendo pequeñas funciones, el código, es con lo que se aprende mucho. Es más, yo con Go leía mucho también el código del propio Go. Cuando tú al final desarrollas un proyecto en Go, desde el propio IDE pues es muy fácil saltar a una función de la librería estándar o o incluso del propio runtime de Go, y ver cómo a lo mejor cómo se implementan por debajo, cómo está implementado el map de Go o los channels. Y eso al final es muy, para mí es muy, vamos, es lo que más, con lo que más aprendo.

Y entonces, los recursos, supongo que no habrá un playground para Rust Tendrás que utilizar otros recursos diferentes.

Me suena que sí. Yo alguna vez he visto por ahí en alguna charla un playground para Rust. Pero bueno, lo bueno del Rust también, al ser un lenguaje moderno, es que montarte, o sea, tú te acordarás del dolor que era poder compilar un proyecto sencillito en C++. O sea, con tus dependencias, le añades un par de dependencias, gestión de dependencias en C++ es un gran dolor, es algo que prácticamente no existe. Así que, pero en Rust no, en Rust es muy facilito. Inicialmente puedes montarte prácticamente como un script, lo que pasa es que eso pues al final tienes que compilarlo y pelearte con el compilador, es lo que tiene Rust. Rust al final es un lenguaje en el que, digamos, gran parte del tiempo estás peleándote con el compilador. No peleándote, al final es solo que el compilador te está diciendo cosas que tú no, que asumes que son verdad y no lo son.

Tenía que cambiar ese mindset inicialmente.

Sí, totalmente. Sí, digamos que en el resto de lenguajes eres tú a quien, digamos, lleva el compilador de la mano, y en el caso de Rust es al revés, es el compilador el que te está diciendo todo el rato no puedes hacer eso, no puedes hacer eso. Tienes que estar, digamos, abierto a los consejos del compilador.

Y echando una vuelta a lo que sería la parte laboral, ¿cuántas ofertas te llegan y cómo está el mercado laboral con respecto a Go en estos días?

Con Go, a ver, Go todavía no es un, digamos, mainstream, por decirlo de algún modo, o al menos yo lo percibo como tal. Pero sin duda es un lenguaje que está creciendo, sobre todo porque eso, porque creo que las empresas se han dado cuenta de que tienen, pueden iterar muy rápidamente con Go y tienen un beneficio en términos de rendimiento. Además, recientemente, como las empresas están metidas en el mundillo de Kubernetes, del cloud y de Docker, y al final todo esto son productos también que están hechos en Go, quieres hacer un plugin para Kubernetes, pues lo natural es que te leas código en Go al final. Entonces yo diría que esto cada vez es más realidad. Yo veo muchas más ofertas en Go ahora y me llegan muchas más ofertas en Go. No diría lo mismo con Rust. Rust creo que todavía sigue siendo bastante de nicho, aunque en toda la parte de sistemas y de esos sistemas que mencionabas que están escritos en C++, Creo que tarde o temprano lo va a acabar copando Rust. También sería aprender Rust, al final en ese sentido creo que sería una apuesta de futuro. Pero a día de hoy, si lo que te interesa, si tuvieras que elegir entre estos dos, sin duda, y lo que te interesa es el mercado laboral, apuesta por Go. Y yo creo que, ya te digo, es, veo mucho, mucho desarrollo, hay mucho cloud, hay mucho servicio en la nube y mucha gente está apostando por Go. Pero sigo, soy consciente de que la gran mayoría de lo que existe ahí fuera sigue siendo los clásicos PHP y Java, que siguen estando ahí obviamente porque fueron los primeros y el código, el código hay que mantenerlo, no puedes tirarlo así de un día para otro.

Entonces, parte de ofertas laborales que te han ido llegando las que estás escuchando son principalmente en Go y de vez en cuando te ha llegado alguna de Rust porque yo veo que no es lo mismo de cuando tú estás estudiando un lenguaje de programación. Por ejemplo, ahora a mí me da por Haskell y realmente, aparte de que hay muy poca oferta de trabajo de Haskell, me encontraría el problema de que por muchos años que lleve desarrollando en otros lenguajes de programación siempre está esa barrera de entrada de cuántos años de experiencia profesional llevas con este lenguaje. Entonces, ¿eso sería un problema?

Sí, claro, al final, al final, ahí tienes toda la razón. Es decir, si no tienes la opción de desarrollar en un lenguaje, no tienes la opción de, digamos, de promocionarte de cara a una empresa. Pero ahí está el mundo de software libre. Entonces hay gente, esto a veces lo hablo, hay gente que piensa que para hoy me gustaría desarrollar esta tecnología, ¿qué empresa la pide? Bueno, es que a lo mejor en lugar de pensar así tienes que pensar, bueno, voy a tratar de encontrar un proyecto ahí fuera y voy a tratar de hacer algún cambio, de leer, sabes, voy a coger la lista de issues del repositorio, voy a ver un problema que tengan y voy a tratar de hacer un fix. Y poquito a poco, al final, cuando te vayas a dar cuenta, al final podrás por lo menos decir a la empresa, vale, yo no he trabajado en ninguna empresa en Haskell, en el caso que decías, pero he colaborado en 10 proyectos open source de Haskell y soy contributor en estos 10 proyectos. O sea que ahí tienes cierto portfolio o cierto currículum que puedes mostrar. Es más, yo creo que a día de hoy el propio LinkedIn te permite enlazar repositorios de open source en los que hayas, o proyectos en los que hayas colaborado. Ya no recuerdo porque en LinkedIn me meto muy poco, pero me suena que he visto algo de poder decir, oye, pues yo trabajo en este proyecto. Obviamente, si la empresa— si tú— eso es en el caso de que tú no tengas la opción de desarrollar en esta tecnología dentro de la empresa en la que estás, pero es que al final eso es así. Por ejemplo, la primera empresa que me contrató para desarrollar Ango lo hizo basándose en los proyectos que había hecho Mencionabas antes Yakal. Yakal era un servidor XMPP hecho en Go. Cuando me decían tienes experiencia con Go, yo podía enseñarles el proyecto y podía explicarles y ellos podían hacerme preguntas al respecto y yo podía contestarles. Así que no sé, sí que es verdad que con los lenguajes de nicho es más difícil, pero bueno, por fortuna existe el open source y creo que eso nos abre muchas puertas.

Básicamente entonces la recomendación sería o intentar hacer un proyecto desde cero o sumarte a otro para hacerte ver, ver que estás haciendo, o sea, que entiendes el código que estás leyendo, que entiendes los problemas, que puedes contribuir poniendo código que arregle algo, y en última instancia incluso creando tu propio proyecto para demostrar que sabes ese lenguaje y lo sabes bien.

Sí, si no tienes la opción, a veces en la propia empresa surgen proyectos de determinado— determinada tecnología y ahí lo tienes más fácil. Si no tienes esa opción y tu empresa está cerrada en un lenguaje, por ejemplo, o lo que sea, creo que es la única forma de poder mostrar algo. Y ya te digo, no tiene por qué ser hacer una aplicación desde cero enorme. Que vale, si lo haces genial, pero es que a lo mejor puede ser algo tan sencillo como contribuir en un proyecto o en varios proyectos, ser contributor en esa tecnología. Porque eso, pues como tú decías, demuestra que al menos sabes leer el lenguaje, que entiendes, que tienes un poco del mindset, y que hay alguien que sabe, probablemente sepa más que tú, que ha decidido que el cambio que has propuesto es bueno. O sea, no sé, es mi manera de verlo.

Pues ha sido un placer tenerte aquí en el programa, poder hablar con otro programador de backend sobre estos tipos de lenguajes y sobre la progresión de llegar hasta aquí, ya de tantos años de trabajo, y cómo vas incluso progresando, aprendiendo nuevos lenguajes de programación, que la gente muchas veces se piensa que cuando empieza en el mercado laboral empiezas con un lenguaje y te vas a jubilar. Utilizando ese lenguaje.

No, al final yo creo que la clave es pensar que al final, vuelvo a lo mismo, lo comentaba antes, el lenguaje de programación es una herramienta y tienes que saber cuándo, cuándo y cómo utilizarla. Pero eso, hay que estar abierto a aprenderlo todo porque al final es eso. Yo ya te digo, sí lo comento a veces con un amigo, para mí el lenguaje de programación sería ideal, sería que al ChatGPT, no, en este caso yo le pudiera decir oye hace esto, esto y esto, y de pronto el servidor estuviera en pie, la solución estuviera montada y fuera 100% óptimo. Para mí eso sería el lenguaje de programación perfecto. Obviamente, en ese caso, a lo mejor ya no me necesitan, pero es que es así. Al final, los lenguajes de programación están ahí para crear soluciones, no son un fin en sí mismos. Entonces, pues eso, hay que estar siempre abierto a aprender nuevas cosas y Y a cambiar.

Bueno, pues lo dicho, un placer tenerte aquí. Si quieres decir algo para despedirte.

Nada, que ha sido un placer. Vamos, hacía tiempo que no nos veíamos. Ha sido un placer volver a verte y nada, espero que te vaya muy bien. Ha sido un gusto, gracias por invitarme.

Bueno, pues nos despedimos aquí. Ya sabéis que todas las semanas subimos un nuevo capítulo de Codeadores y hasta la siguiente.