Go y TypeScript con Jesús Espino

Pues buenas, estamos otra tarde más en Codeadores. Esta vez nos acompaña Jesús Espino, que realmente yo no lo conozco mucho, hemos estado solamente hablando por LinkedIn, pero me ha parecido una persona bastante interesante porque trabaja en Mattermost, que es uno de los grandes competidores de Slack, trabaja desde España y trabaja con lenguajes como Go y TypeScript. Así que le he invitado para que nos hable un poco de cómo trabaja con estos lenguajes y cómo le ayudan. Y te hago la primera pregunta aprovechando para que te presentes un poco, porque mi introducción ha sido muy rápida, y de paso para que introduzcas un poco el cómo te introdujiste tú en la informática, o sea, cuál fue el punto en el que dijiste quiero dedicarme a esto.

Bueno, Veamos, primero, bueno, soy pues eso, como has comentado, soy Jesús Espinoza, trabajo en Mattermost, donde hacemos pues es una herramienta de comunicación similar a Slack. Tenemos nuestras cosas que son diferentes, pero bueno, y trabajamos mucho con Go y TypeScript. Pues, ¿cómo empecé? ¿Cómo empecé yo en la programación? Yo empecé, bueno, en realidad empecé primero con el tema de la informática, con el tema de de Linux allá por el 96, 97 o por ahí. Yo tenía un amigo que empezó a usar Linux y me introdujo a Linux. De hecho, le agradezco prácticamente toda mi carrera profesional a él, es Francisco Martín, y gracias a él empecé a usar Linux. Y como usábamos, usaba Linux, teníamos un grupo de IRC en aquel momento que era el grupillo de la gente que estábamos allí en Lanzarote. Yo soy de Canarias, soy de Lanzarote, y del grupo de IRC pues decidí que iba a montar una pequeña web y empecé a hacer cositas en PHP y empecé a probar. Y ahí fue donde empecé a aprender mi primer lenguaje de programación, fue PHP, y bueno, HTML y todo este tipo de cosas. Y entre eso y Linux pues fui pillándole mucho el gusanillo a todo esto, fui empezando a meterme en más cosas, en administración de sistemas, en en programación de shell script, en otros lenguajes. Luego llegué a la universidad y en la universidad pues también me metí un poco más con Python. Y bueno, estuve haciendo durante años, estuve trabajando en Python en Madrid en una empresa que probablemente muchos del mundo Python la conozcan, que es Kaleidos. Estuve 6 años en Kaleidos y después ahora he estado, llevo Voy a hacer 7 años trabajando en Mattermost ahora con Go. Así que eso es un poquito una versión muy, muy, muy resumida de mi historia. Y yo creo que fue amor a primera vista cuando empecé a usar Linux, cuando empecé a usar, a programar y a ver lo que se podía hacer. La verdad que ese proceso creativo me atrapó desde el principio. Yo creo que no, no, una vez empecé a hacerlo, ya, bueno, ya no había vuelta atrás.

Entonces, ¿cuál fue tu primer lenguaje que te introdujo en esto de la programación?

Mi primer lenguaje fue PHP y lo usé durante años. PHP, probablemente empecé con PHP 3 o algo así, luego usé durante años PHP 4 y PHP 5. Yo sé que No es uno de los lenguajes más mejor vistos, o con, pero bueno, fue el que, el que a mí me ayudó. Y es cierto que una de las cosas buenas que siempre ha tenido PHP es que era como muy fácil, tenía una barrera de entrada muy, muy, muy pequeña. Es muy fácil programar, es un poquito HTML, tiras etiquetas aquí y allá y todo funciona. Pero bueno, ese fue mi primer lenguaje. No lo uso hace muchos, muchos, muchos años que no programo nada en PHP. Ya digo, lo último que programé en PHP fue PHP 5 y no sé si van por el 8 o algo así. O sea, es que hace mucho, mucho que no hago nada.

Y cómo, o sea, porque la experiencia que tiene antes de Go y Mattermost es Kali 2 con Python, ¿cómo determina el saltar de Python a Go? O sea, porque son lenguajes muy diferentes. Python es muy parecido a PHP, y sin embargo Go es compilado, orientación a la concurrencia. ¿Cómo te da por cambiar de lenguaje?

Pues en realidad la situación fue que yo estaba, yo estaba trabajando, llevaba 6 años, llevaba como 5 años en Kaleidos, y a mí siempre me ha gustado contribuir a proyectos de software libre aquí y allá. Siempre he estado intentando contribuir en alguna cosa en algún lado. Y una de las cosas en las que me puse a contribuir durante ese año fue precisamente a Mattermost, que estaba escrito en código. Bueno, pues mira, es una buena excusa para aprender un lenguaje que llevaba tiempo queriendo probar. Tenía una compañera, Yamila Moreno, que estaba probándolo y que le estaba gustando. Y digo yo, oye, pues esto pues le tendré que echar un ojo. Y con la excusa de echarle un ojo, pues digo, bueno, pues voy a contribuir a algún proyecto que esté bien. Y empezaba a contribuir a Mattermost, que además era, la verdad que estuvo muy bien porque era una, bueno, tenía y tiene una comunidad muy, muy activa, muy, respondían muy rápido a los pull requests, cosa que cualquiera que haya contribuido al open source sabe que uno de los problemas es mando un pull request y no sé si van a tardar 2 días en contestarme, 2 meses o 2 años, que me ha pasado. Pull request que me han contestado después de 2 años. Pero bueno, en Mattermost las respuestas eran rápidas, la sensación fue muy buena, y entonces me enganchó y empecé a seguir contribuyendo. Y me gustó el lenguaje, me pareció un lenguaje muy, muy bonito, muy elegante. Y bueno, de hecho fue así como al final acabé trabajando para Mattermost. Llegó un punto en el que me hicieron la oferta de entrar a trabajar con ellos y empecé a trabajar para Mattermost directamente. Y la verdad que fue, pues así fue un poquito como entré yo en el mundo de Go.

También estuvimos hablando de que estás trabajando en Mattermost con TypeScript. TypeScript es un lenguaje que conocías ya de antes de entrar a trabajar, o has aprendido a medida que ibas trabajando con ellos.

No, yo, bueno, yo aparte de PHP, por supuesto, en aquella época, bueno, PHP es un lenguaje principalmente de web, con lo cual al final siempre pues ibas acompañado de JavaScript y demás. Entonces yo durante muchos, muchos, muchos años he programado con PHP, JavaScript, Python, JavaScript, porque al final era, bueno, yo siempre he sido un full stack, me gusta hacer un poco de todo, me gusta desde desde el desarrollo de, desde CSS hasta administración de sistemas. O sea, me encanta, me encanta todo el abanico. Con lo cual, pues yo JavaScript ya, yo llevo usando JavaScript igual probablemente más de 20 años. Entonces no había usado TypeScript hasta que entré, hasta que entré en No, poco antes de entrar en Mattermost ya empecé a usar TypeScript con Angular 2, creo recordar, un poquito de TypeScript con Angular 2. Luego entré en Mattermost y Mattermost estaba hecho en JavaScript y migramos a TypeScript durante, hemos tardado un buen tiempo en migrar a TypeScript porque lo hemos hecho gradualmente. No, no es un cambio de todo o nada, era un cambio gradual y hemos ido cambiando cosas aquí y allá. Y a día de hoy el 99% de nuestro código es TypeScript y no JavaScript. Tenemos algunos flecos sueltos por ahí todavía que tenemos que migrar, pero, pero ahí fue donde, donde realmente ya ha empezado a trabajar con TypeScript de una manera más activa.

Vamos, sin dejar todavía el tema de TypeScript, porque me interesa saber un poquito acerca de esto. O sea, la idea de cambiar de JavaScript a TypeScript, ¿qué ventajas incorpora?

Bueno, principalmente para mí es esencialmente el tipado. Es decir, es el hecho de tener tipos, control de tipos, y poder asegurar que el código cuando cambia ciertas cosas no se van a romper, porque al tener tipos puedes tener una coherencia y una consistencia mayor. Eso yo creo que es la clave, porque sí es cierto que TypeScript incorpora ciertas mejoras al lenguaje aquí y allá, Pero esas mismas mejoras del lenguaje las puedes conseguir con cosas como Babel o con otros, otros compiladores o preprocesadores que te van a dar funcionalidades similares. Pero el sistema de tipos, el tener la capacidad de tener esa seguridad de que lo que dices que estás pasando y lo que dices que recibes cuadra es muy importante, entre otras cosas porque nuestro proyecto es un proyecto bastante grande. Entonces, hacer modificaciones en una parte y que puedan romper otras partes no es una cosa extraña, especialmente un sistema de componentes. Tengo un componente, ese componente lo uso en muchos sitios. Si yo cambio la estructura del componente, antes tenía que asegurarme de que todo lo cambiaba en todos los sitios. Ahora me sigo asegurando, pero el compilador me ayuda. El compilador me dice, oye, que se te ha olvidado este, este sitio donde no estás pasando ese parámetro, que tienes que pasarlo obligatoriamente. Y luego te ayuda también, una de las cosas que me ayuda del sistema de tipos es a pensar en qué es obligatorio, qué no, qué, y si es obligatorio estoy comprobando, y si no es obligatorio estoy comprobando en todos lados cuando viene sin definir, cosas así. Son pequeños detalles que te ayudan a tener errores en tiempo de compilación en vez de en tiempo de ejecución, que son mucho más costosos de arreglar.

Y volviendo ahora a Go, ¿qué te gusta del lenguaje? Porque claro, viniendo de lenguajes como PHP y Python, el cambio a Go ha sido bastante significativo. ¿Qué te atrae o qué te gusta de ese lenguaje?

Bueno, una de las cosas que para mí es la parte que yo creo que me enamoró de Go es la simplicidad. Cuando yo empecé a mirarme Go, la sensación fue similar a cuando estudié C en la universidad, en una cosa muy concreta, no en general, porque C es un lenguaje que tiene cierta complejidad. Pero la realidad es que tanto C como como Go, son lenguajes muy pequeños, son lenguajes con una cantidad de sintaxis, por así decirlo, relativamente pequeña y acotada, y con eso haces todo. Si te vas a otros lenguajes más complejos donde tienes un montón de estructuras diferentes, un montón de complejidad alrededor de la orientación a objetos, alrededor de un montón de cosas, tienes unas una serie de complejidades, un montón de palabras reservadas, un montón de formas de hacer las cosas. Eso en Go no pasa. En Go es un lenguaje relativamente compacto, relativamente pequeño, relativamente sencillo, y con eso tienes que hacer todo. Luego tiene pues sus complejidades, como que durante muchos años no hemos tenido genéricos, con lo cual no podías hacer ciertas cosas de manera sencilla. Cosas de ese tipo. Pero la simplicidad del lenguaje en sí mismo es algo que yo creo que me enganchó desde el primer momento.

Y teniendo en cuenta de que Mattermost es un sistema tan grande, la verdad es que no he visto la base de código, pero me imagino que tiene que ser bastante grande y complejo. ¿Crees que, bueno, habéis tenido alguna sugerencia, iniciativa de reescribirlo a Rust u otro lenguaje?

La realidad, bueno, siempre hemos bromeado sobre ello internamente, especialmente en concreto con Rust, porque a mí también me encanta, me encanta Rust. Yo para eso me considero como bipolar, porque me encanta Rust y me encanta Go, y son lenguajes completamente opuestos. Go es un lenguaje muy simple con la funcionalidad justa que necesita para hacer un buen programa, un lenguaje, un buen lenguaje de programación. Y Rust es como el lado opuesto, es un lenguaje súper potente con bastante complejidad en realidad, por todo el tema del sistema de borrowing y ownership. Todo, todo es un sistema complejo lleno de funcionalidades, lleno de funcionalidades que vienen en el lenguaje, como bueno, las abstracciones de coste cero, todo este tipo de cosas. Es un tema súper potente, pero a la vez es, ¿cómo te pueden gustar los dos? Pues a veces me siento un poco bipolar ahí, me gustan mucho los dos. Entonces yo siempre, pues siempre he estado pues haciendo comentarios, ah, pues va, pues Rast, pues Rast. Y durante un tiempo teníamos la broma de, bueno, Jesús cualquier día nos lo migra a Rast, por una noche que se despisten, que nos despistemos, nos lo deja migrar por la mañana a Rast. Y llegamos aquí todos y está ya migrado. Pero la realidad es que eso no va a pasar en ningún caso. Rust es un lenguaje que a mí me gusta mucho, pero creo que Go tiene una ventaja sobre Rust, y es que Go permite programar más rápido en general. Es decir, la eficiencia del del compilado probablemente no alcance los extremos de Rust, pero la eficiencia del programador o lo rápido que el programador escribe código yo creo que es mayor en Go. Con lo cual eso es una gran ventaja. Aparte de eso tiene ciertas cosas que son muy buenas, el tema de la sincronía nativa, que no lo usamos de manera excesiva, pero sí es cierto que que soluciona algunos de los problemas y nos permite trabajar de una manera muy eficiente en general en Mattermost. Entonces hacemos bromas sobre migrar a Rust, pero no, no va, no va a pasar. Y hemos tenido conversaciones, pero nunca han sido conversaciones en serio y nunca se ha llegado a plantear en serio, porque es como bien dices, es un proyecto demasiado grande para migrarlo a cualquier otra cosa, incluso si Rust fuera la mejor opción posible a día de hoy sería, sería una labor titánica.

Bueno, hemos hablado hoy de las partes positivas y lo que te gusta de estos lenguajes. Ahora vamos a dar la vuelta y vamos a ver qué es lo que te genera más fricción o más pesadilla cuando tienes que enfrentarte, por ejemplo, a TypeScript.

Vale, bueno, TypeScript, TypeScript, la realidad es que Para nosotros el problema es que estábamos migrando de JavaScript, no hemos escrito TypeScript desde cero, con lo cual TypeScript tiene ciertos, ciertas cosas que si no estás migrando desde, si no lo estás escribiendo desde cero o no eres desde el principio bastante estricto, te empiezas a encontrar cosas como, bueno, esto es un any, o esto, bueno, esto voy a poner un tipo Pero el tipo lo voy a poner que es un record de una cadena, a un mapa que tiene la clave es cadena y el valor es cualquier cosa, o el valor es otra cadena. Entonces ya empiezas a no estar, empiezas a jugar a hacerte trampas al solitario. Es decir, estás haciéndote trampas al solitario muchas veces usando los tipos, qué tipos más laxos de los que te gustaría. Porque estás en un proceso de migración. Entonces, como nosotros hemos estado en un proceso de migración, muchas veces no hemos abusado de los anys, o hemos tratado de evitar abusar de los anys, pero es cierto que no hemos tampoco llegado al punto de definir los tipos con el nivel de definición que tendría un lenguaje compilado como Go, porque eso aparte requiere tipos relativamente complejos. Empiezas ya a meterte en líos de, bueno, esto, el campo este de aquí es el del campo, infiérelo a partir del campo que tiene este otro tipo porque es una foreign key. Entonces ya empiezas a hacer, empiezas a hacer pues un poco de hilado fino y el tipado empieza a volverse también complejo ahí. Eso yo creo que en la parte de TypeScript que no me acaba de encajar es te permite saltarte hasta cierto punto las reglas del tipado y tipar relativamente mal, te permite tipar bien, pero si tipas bien también tiende a generar tipos relativamente complejos. Yo creo que ahí tengo una relación de amor-odio con TypeScript, porque es cierto que para mí lo ideal sería que los tipos estuvieran bien definidos, y probablemente si hubiera hecho el proyecto desde cero lo hubiera definido los tipos mejor, y probablemente habría una consistencia bastante mejor de los tipos, pero, y no se desmadraría demasiado los tipos. Pero cuando ya estás en un proceso de migración, definir los tipos bien y definirlos coherentemente, y con además que el tipo definido no se vuelva loco y no sea como una, bueno, esto es un tipo que tiene un genérico, que tiene un genérico, que tiene un genérico, sabes. La cosa se desmadra con mucha facilidad. Yo creo que esa es la parte que a mí acabo, no acabo de, no acabo de gustarme del TypeScript.

Estábamos diciendo de que habíais estado haciendo una migración de JavaScript a TypeScript. No sé si sabrás las gracias que hay con JavaScript y acerca de las dependencias, de que instala una dependencia pequeñita por una línea de código y terminar arrastrando mil dependencias en tu proyecto. La idea esa de que cuando necesitas una dependencia externa, al utilizarla con TypeScript, eso, es decir, tienes que importar algo que es de JavaScript dentro de TypeScript, obviamente no tiene tipos. ¿Genera algún tipo de problema o tienes que definir una interfaz?

Eso generaba problemas hace unos años De hecho, cuando empezamos a hacer esto generaba problemas, pero a día de hoy la gran mayoría de las librerías que se utilizan en general, que se utilizan a diario, están, están ya soportadas. Hay un, de hecho hay un repositorio que es el @types que te permite importar tipos de un montón de bibliotecas que están que están ya aportadas a TypeScript, que tienen la interfaz definida. Que es una biblioteca no tan conocida, pues siempre puedes ir y definir tus tipos a mano. Eso sí, sí es así y sigue siendo así, pero es cierto que a día de hoy es mucho menos necesario que antes. A día de hoy cualquier biblioteca mínimamente popular tiende a tener los tipos ya definidos en algún lado.

Y ahora volviendo otra vez a Go, es decir, la misma pregunta pero con Go, sería, ¿qué es lo que no te gusta o qué te crea más fricción? Porque me resulta curioso de que te guste tanto Rust como Go siendo tan diferentes, tal y como has dicho. Entonces seguramente en algún punto echas de menos algo de Rust que quisieras hacer en Go y no te deja.

Bueno, ahí hay varias cosas que Rust permite que pocos lenguajes permiten, de hecho, y que sí que podría echar de menos en Go. Una de ellas es el hecho de poder hacer, hacer un programa en Go que se pueda acceder desde otros lenguajes. Eso no es algo que funcione todo lo bien que me gustaría. En Rust, por ejemplo, tú haces un programa en Rust y lo puedes importar desde casi cualquier, cualquier lenguaje, o haces una biblioteca en Rust y la puedes importar desde cualquier lenguaje porque tiene una interfaz muy similar a la de C. No tiene garbage collector, no tiene nada. Es decir, es prácticamente como si hicieras un programa en C, que tienen una compatibilidad grandísima para, para poder importarlo desde otros. Eso en Go no se puede porque tenemos el garbage collector, tiene otras, otras implicaciones. Una de las cosas que echo de menos en Go, porque durante un tiempo yo estuve también jugando un poco con Clojure, con Haskell, lenguajes funcionales y demás, y la verdad que echo de menos que se pueda hacer algo parecido en el ecosistema Go a día de hoy. No, no, Go no es un lenguaje funcional, no hay estructuras de datos inmutables con compartido de estructura o cosas de ese tipo. Entonces pues esa parte me gustaría, pero no es tanto culpa del lenguaje, sino pues algo que echo de menos de lenguajes que son, que cumplen específicamente otra función, que son los lenguajes funcionales, que están pensados para ese modelo de programación. Con lo cual, echarle la culpa a Go de eso me parece un poco, un poco exagerado. Y luego hay cosas que no necesariamente me molestan, pero sí son cosas que para que sí que están ahí, como pues como el garbage collector. El garbage collector el 99% del tiempo funciona fantásticamente y no te tienes que preocupar de él. De hecho, diría que el, no, prácticamente el 99% de los programadores viven muy, muy a gusto y muy tranquilos sin entender, sin tener que entender y sin tener que preocuparse del garbage collector de Go. Pero es cierto que para hacer cosas de eficiencia y demás sí que tienes que ya meterte a entender qué está haciendo el garbage collector, cuándo, cómo funciona el escape analysis de Go, como tiene ciertas cosas que hacen que tener un garbage collector tenga implicaciones en el rendimiento. Entonces, ¿eso es bueno o malo? Diría que de nuevo, al 99,9% de los desarrolladores no les afecta porque el rendimiento de Go ya es suficientemente bueno. Pero Rust no tiene ese problema porque no tiene garbage collector, porque funciona, funciona con el sistema de ownership y borrowing y demás. Y eso pues es una maravilla en realidad. Con lo cual, pues ahí yo creo que es donde, donde veo cosillas que Go podría haber hecho mejor en algún aspecto, pero también a la vez todos son trade-offs, todos son ventajas e inconvenientes. Entonces, tener un garbage collector es muy, muy, muy cómodo. Es añade una ergonomía fantástica que el sistema de borrow and return de Rust no trae. El sistema de borrow and return de Rust significa que él te ayuda y te avisa cuando lo estás haciendo mal, pero tú eres el que tiene que hacerlo bien. En Go te puedes olvidar, ya sabes que el garbage collector lo está haciendo bien y lo está haciendo todo por ti. Entonces es, de nuevo son trade-offs, pero hay veces que echo de menos esas cositas: programación funcional, ausencia de garbage collector, capacidad para tener interfaces con otros lenguajes de manera mucho más al arrastre, vamos, con esa capacidad de compilar y ya está listo para importar como biblioteca. El tamaño de los binarios de Go también tiende a ser más grande, tiene su motivación y de nuevo es una cuestión de trade-offs, pero también hay veces que dices, pues estaría bien que fuera un poquito más pequeño, pero Pero bueno, al final parece que es casi como elegir si quieres coche con marchas manuales o automáticas. Sí, sí, al final el garbage collector es exactamente eso. Es decir, yo tengo un automático y tengo uno manual, entonces para mí lo más cómodo, lo más cómodo seguro es el automático. Yo entiendo que haya gente que diga no, pero es que yo no es una cuestión de comodidad, yo es que yo es que quiero ajustar eso a cómo quiero usar yo el coche. Digo, ah, entonces sí tiene sentido usar el manual. Pero el 99% de la gente no necesita ese grano fino, no necesita ese nivel de detalle. Con lo cual, yo estoy muy contento con cómo funciona el garbage collector de Go y creo que fue una decisión muy acertada por parte del equipo de de Go.

Y en este sentido, ¿qué cambiarías de Go si tuvieses la posibilidad de que el equipo de desarrollo de Go te dice, oye, queremos cambiar algo, danos unas sugerencias?

A mí personalmente me gustaría que Go tiene un sistema de módulos que permite crear módulos en Go que tú cargas de manera dinámica. Nunca ha llegado a funcionar del todo bien, nunca ha sido 100% compatible. Es decir, tenías que, los binarios tenían que estar compilados de una manera muy concreta y tenían que ser compatibles los, el compilador, versión del compilador tenía, había como ciertos requisitos para hacer que esos módulos empastasen bien, con lo cual al final es algo que no se usa. O se usa relativamente poco. Yo, si se hiciera un cambio, no es un cambio que digas, guau, es un cambio drástico, no, pero sí que me gustaría que esa funcionalidad fuera una funcionalidad mucho más robusta y que pudieras, pues eso, dividir tu programa en módulos que se puedan cargar dinámicamente, porque muchas veces un programa de Go puede ocupar mucho espacio, y si tú puedes separarlo en diferentes bibliotecas que hacen cosas concretas y que cierta parte de ese programa ni siquiera se carga en memoria cuando, cuando no la vas a usar, pues, pues estaría bien. De hecho, se pueden cargar esos programas, pero no se pueden descargar de memoria a día de hoy. Sí puedes hacer, aparte de los problemas que pueda tener y demás, puedes cargarlos, pero no puedes descargarlos. He dicho que no es una funcionalidad así de muy drástica de cambio del lenguaje, pero probablemente a nivel interno interno sí lo sea. A nivel interno probablemente requiera unos cambios bastante drásticos, y probablemente el hecho de que no exista la funcionalidad como tal a día de hoy en las condiciones que a mí me gustaría es probablemente una limitación estructural, porque si no probablemente lo hubieran solventado.

Y haciendo la misma pregunta pero enfocándonos en TypeScript, si el equipo de TypeScript se pone en contacto contigo te dice venga, aceptamos una sugerencia y lo hacemos, ¿qué les dirías?

Madre mía, es más complicado porque realmente al final TypeScript para mí es JavaScript con el sistema de tipos. Entonces sería el sistema de tipos, y para mí ya el sistema de tipos que tienen ya es extremadamente potente. A mí, para mí no, yo no necesito nada más en realidad. Yo necesito lo que me dan. De hecho, incluso podría llegar a necesitar menos, a pedir, oye, me lo simplificáis. Pero entiendo que también es cierto que no querría que lo simplificaran, porque cuando en los puntos donde quiero llegar al nivel de complejidad que me interesa, me gusta tenerlo a mano. Pero en general, a mí me sobra una parte relativamente no grande, pero me sobran algunas cosas que hace TypeScript que yo no utilizo diariamente o que utilizo muy rara vez. Entonces es, para mí no se me ocurre nada que añadir ahí.

Si alguien quisiera adentrarse en el mundo de TypeScript, supongo que sería alguien que ya es programador de frontend, pero incluso sin serlo, ¿qué recomendarías para que iniciasen su andadura en TypeScript?

Yo soy una persona muy de hacer, de hacer más que otra cosa. Es decir, cada persona aprende de una manera diferente. Entonces es muy, es una pregunta complicada la que me haces, pero mi forma de aprender, o para la gente que aprende como yo, lo que les recomendaría es que buscaran algún proyecto en el que, el que hacer o al que contribuir. Porque al final se trata de programar y se trata de estar haciendo algo y estar probando cosas y estar viendo cómo falla y estar viendo todo ese tipo de cosas ayuda muchísimo a entender cómo funciona un lenguaje o una biblioteca. Entonces mi recomendación es esa, buscad un proyecto que os llame la atención ya sea personal o un proyecto de otra persona que admita contribuciones, y empezar a cambiarlo, empezar a hacer cosas y empezar a usar TypeScript. TypeScript, al final, si ya sabes JavaScript, TypeScript es JavaScript con tipos. Solo tienes que ir añadiendo tipos. En muchos casos los va a inferir, van a ser opcionales, con lo cual realmente es, es relativamente fácil adaptarte a usarlo. La complejidad entra cuando ya empiezas a tener que definir los tipos de manera muy granular. El tipo, bueno, ¿cómo defino? Pues bueno, un caso típico que hay que definir es: defino un tipo y ahora quiero mandar unas modificaciones, un parche, a un objeto de ese tipo. Pero yo no voy a mandar todos los campos, yo solo voy a mandar algunos. ¿Cuáles? Bueno, ya veré. Pues eso es lo que se llama un partial, con lo cual ya empiezas a aprender truquitos de, ah, vale, yo meto, hago un partial de un tipo, que lo que viene a significar es que es el tipo que estaba definido pero que todos sus campos son opcionales. Todos sus campos son pues eso, opcionales, se pueden, pueden estar o no. Entonces ya pues con truquillos así, con eso se llama En TypeScript se llaman utility types. Con los utility types ya empiezas a meter un poquito más de abstracción. Hay utility types del tipo este objeto o esta variable es del tipo que esté definido en la key de esta de este otro tipo, sabes. Entonces empiezas a hacer definiciones que hacen relación a otros tipos y cosas de ese tipo, pero eso ya es cuando vas entrando en complejidad, vas entrando en hacer cosas más complejas. Empezar añadiendo tipos aquí, allá, tipos sencillos, ayuda muchísimo porque empiezas a ver pues eso, los campos opcionales, tengo que hacer checking de si es, si está definido o no. Los campos pues de ciertos tipos, tengo que, tienen que coincidir los tipos en la entrada con la entrada de los parámetros de las funciones con las llamadas de las funciones. Entonces al final es, para mí es una cuestión de usarlo, y lo mismo es aplicable a Go. Es decir, para mí aprender un lenguaje como Go fue a base de usarlo, para mí fue a base de usar. También es cierto que yo tengo muchos años de experiencia programando. Entonces, para mí aprender un lenguaje nuevo tiende a ser más fácil que alguien que empiece de nuevas a programar. Pero, pero si ya eres programador y quieres aprender Go, mi recomendación es pues márchate las manos de harina, ponte a trabajar y a hacer cositas. Y si encuentras un proyecto en el que contribuir que te dé un objetivo claro pues mejor que mejor.

¿Y cómo va el mercado laboral si quieres dedicarte, por ejemplo, a TypeScript? ¿Es algo que dices se puede dedicar únicamente a TypeScript o tiene que ir en combinación con otro?

Yo diría que a día de hoy TypeScript, tanto TypeScript como, bueno, si haces TypeScript se entiende que sabes JavaScript. Yo diría que a día de hoy es un mercado bastante amplio. Hay muchísima demanda, en mi opinión, de gente que haga desarrollo web y demás. Es cierto que el mercado también se ha llenado de gente, ha habido muchísima gente que se ha incorporado al mercado y se ha incorporado a trabajar. También es cierto que yo llevo 7 años sin mirar cómo está el mercado, con lo cual me es difícil determinar exactamente. Sé que hubo una una subida, una locura, una locura de la gente empezando a repartir dinero y a decir, guau, $500,000 al año por un ingeniero y cosas así. Eso ya se acabó, eso ya no, ya no existe. Pero, pero creo que mi sensación es que sigue haciendo falta gente, sigue haciendo falta mucha gente para temas de desarrollo de frontend, y probablemente lo mismo para backend. No sé, no sé hasta qué punto la IA va a mitigar esa falta de gente. Es decir, que igual los que ya estamos, si somos capaces de sacar mucho más trabajo con la IA, pues igual ya no ya hace falta menos gente y el mercado se queda en una situación complicada. No sé lo que va a pasar. De hecho, probablemente esa sería mi, mi predicción, será que los próximos meses o probablemente un par de años como, como poco, muchas empresas estarán más reticentes a contratar porque quieren ver si se pueden ahorrar las contrataciones usando IA. Eso yo creo que va a pasar, porque bueno, porque al final, si puedes con la misma gente que tienes puedes sacar más trabajo, lo normal es que no necesites contratar más gente. Pero bueno, ya veremos. Y sobre todo se van a ver afectados principalmente, en mi opinión, los puestos más de puestos de entrada, los juniors, gente que todavía no tiene experiencia, que son más, más fáciles de reemplazar con una IA. No necesariamente se pueden reemplazar, pero se puede. Muchas de las tareas que son capaces de hacer, pues las IA más o menos son capaces de hacerlas a día de hoy. Con lo cual creo que esos son los que más afectados se van a ver. Y mi preocupación es que si hoy no hay juniors, mañana no hay seniors. Entonces no sé cómo vamos a solucionar ese problema si llega, si llegamos al punto de que los juniors, desde que los juniors no encuentran trabajo porque la IA es capaz de dar un nivel de calidad similar. Entonces llegaremos al punto en el que no haya seniors porque la gente querrá jubilarse.

Entonces tú ves que, o sea, porque a día de hoy para que eso se dé, la mayoría de seniors deberían de estar utilizando la inteligencia artificial que le haga como de juniors para poder ahorrarse el tener que mandar esas tareas que son tediosas, repetitivas, a la gente que está aprendiendo a día de hoy. Esos seniors tendrían que hacerse con la inteligencia artificial dentro de su empresa. ¿Crees que eso es algo que—?

Eso creo que va a pasar, eso creo que va a pasar, y creo que va a pasar más pronto que tarde. Es decir, otra cosa es que eso vaya a reemplazar a las personas. Yo, a día de hoy, mi experiencia es que la inteligencia artificial a nivel de programación No es capaz de reemplazar a un programador senior que entiende el, que entiende el problema, que tiene el contexto, que entiende una serie de cosas. Pero es cierto que la inteligencia artificial es capaz de hacer las tareas que el senior le indica, porque el senior le puede dar las instrucciones de, no, modifica estas cosas, estas otras cosas, este es el contexto que tienes que tener en cuenta. Haz las modificaciones que te pido. Entonces realmente puede ser capaz, puede ser un acelerador muy bueno para programadores con experiencia que saben lo que quieren hacer, pero puede ser también, pero hay que, va a haber que aprender a usarlo, va a haber que ver cómo evoluciona el mercado en ese sentido, cómo evolucionan las IA que a día de hoy Mi impresión es que las IA no son capaces de sustituir a un senior, pero igual dentro de 6 meses, un año o 2 años sí son capaces y no es necesario. No lo sé, a día de hoy es difícil saberlo. A día de hoy sé que no son capaces de sustituir a un programador senior porque no son capaces de entender el contexto entero y la funcionalidad entera y qué es lo que se quiere conseguir. Es que tiene cierta complejidad.

En tu experiencia, trabajando tanto con TypeScript como con Go, ¿has utilizado alguna inteligencia artificial que te haga de ayuda en la consecución de tareas simples? Sí, sí, es cuando has tenido la oportunidad.

Sí, sí, he tenido la oportunidad. De hecho, lo estamos empezando a usar ahora bastante. Y la verdad que es impresionante. Tiene varias ventajas y es que principalmente es capaz de hacer trabajo que te llevaría días en hacerlo, lo puedes hacer en horas, si no minutos, porque la IA, mi sensación de uso de la IA es que se comporta como, tiene la capacidad de un junior más o menos, incluso de un becario si lo pones, sí, es decir, es relativamente poco independiente y poco capaz de hacer muchas modificaciones y demás, pero tiene dos ventajas. Uno, si le das el contexto adecuado, si tú a un junior le das todas las explicaciones, mira, aquí está la documentación, aquí está lo que yo quiero hacer, estos son los ficheros que tienes que modificar. Esto, si le das toda esa información, es capaz de, es capaz de resolver tareas bastante, bastante complejas. No necesariamente complejas, pero tareas de programación que llevarían su tiempo. Y la segunda cosa muy interesante es que está entrenada con muchísimo código de, probablemente de GitHub y demás, Y el tema es que es un junior, pero es un junior en prácticamente todo. Entonces, yo no soy un junior en las APIs de Google Docs, por ejemplo. Yo no, no me conozco las APIs de Google Docs porque nunca las he usado. No llego ni a junior en eso, pero la IA sí se sabe muchas de esas APIs. Y se conoce muchas bibliotecas y conoce muchas cosas. Entonces yo le puedo pedir, oye, hazme un programa en Go que se conecte a Google Docs, que se descargue el documento en formato texto, que se lo pase a OpenAI, que me saque un resumen. Ese resumen me lo metes en un Confluence y va a saber conectarse a todas las APIs que necesita para hacer, para hacer lo que le has pedido. Es decir, tampoco es que sea infalible ni mucho menos, pero con darle todo el contexto y explicarle lo que quieres y hacerle las correcciones que necesita después, puedes pasar de algo que te llevaría días hacerlo a tenerlo resuelto en 30 minutos. Es mi experiencia, es, es de locos, es auténticamente impresionante. Si queréis probarlo, hay una herramienta que nosotros usamos y que realmente a mí me gusta mucho el flujo de trabajo que utiliza, que se llama Aider.chat. Si buscas Aider.chat lo vas a encontrar, Aider, vale, como ayudador o algo así. Y es una herramienta que funciona en el terminal, y entonces tú vas escribiendo, le vas escribiendo cosas y él va haciendo commits al proyecto, y entonces Que no te gusta lo que ha hecho, le pides que lo deshaga. Que necesita más contexto, copias y pegas y se lo das la información, o le pides que se descargue una web para que tenga toda la información, todo el contexto de lo que estás haciendo. Y le vas pidiendo cambios y le vas diciendo modifícame estos ficheros, lee también estos ficheros para que sepas lo que hay que hacer, y haces modificaciones y le pides que haga modificaciones y te muestra las modificaciones que ha hecho, te explica un poquito el porqué de lo que ha hecho. Es, es realmente alucinante, es alucinante. Y bueno, es una herramienta open source. De hecho, Aether está escrito con Aether. Cada, cada versión que sacan de Aether te dice, pues esto está hecho un 80 y pico por ciento con Aether, esto está hecho un 70 y pico por ciento con Aether. Porque muchas veces lo que haces es haces cosas con Aether y luego te vas al código y haces modificaciones ya de grano fino, de Porque, porque son detalles más específicos que quieres hacer y realmente funciona muy, muy, muy bien. Nosotros en concreto estamos usando el modelo Sonnet de Anthropic y que es el que recomienda, es el top 1 en el leaderboard de Aether y funciona de auténtica maravilla. Es una locura.

Es una auténtica locura. Y sobre Google, porque además de que es una de las empresas que más está apostando últimamente por la inteligencia artificial, con la última salida de sus IA y demás, que están, creo que en este mes ha ido teniendo mucha publicidad y se ha ido comparando con OpenAI, dejándola un poco por los suelos. Es verdad que Google también saca muchos lenguajes de programación como Dart, Go. Bueno, Dart en Flutter. Go tenía también la propuesta de Carbon para intentar reemplazar a C++, pero también está el miedo de la gente de que cuando Google saca un proyecto lo puede terminar cerrando, como está pasando un poco con Flutter, que se está viendo ahí la comunidad intentando salir un poco más aprisa, que han creado la rama esta llamada Flock para intentar disparar un poco el proyecto Flutter hacia arriba. ¿Qué opinas tú acerca del futuro de Go dentro de Google?

Yo creo que el futuro de Go no está en peligro. Go tiene una comunidad bastante, bastante amplia de desarrolladores y Hay mucha gente contribuyendo al proyecto. Incluso si Google decidiera no financiar al equipo de Go nunca más, probablemente el volumen de empresas que hay detrás de Go a día de hoy haría que el equipo de Go tuviera trabajo. Ten en cuenta que la mitad de los proyectos de CNCF, de la Cloud Native Foundation, están escritos en Go. Kubernetes está escrito en Go. Es decir, es imposible que Go pueda caer sin llevarse medio internet por delante. Es decir, es muy difícil dejar de dar soporte a Go como lenguaje. Google podría llegar a decir, oye, bueno, yo no voy a invertir más dinero aquí, pero si la comunidad alrededor de Go de empresas no se pone de acuerdo para crear una fundación alrededor de Go, en ese caso sería, sería que la propia industria se está dando un tiro en el pie muy importante. Porque digo, la mitad de la infraestructura de cloud y de internet a día de hoy, y si no más de la mitad, está escrita en Go.

Yendo a la parte de frontend, porque da la sensación de que en frontend te despistas un poco y salen 3 o 4 nuevos frameworks. Es verdad, es verdad que lo de TypeScript, yo escuché un poco un revuelo que salió no hace mucho, creo que fue hace un par de meses, 2 o 3 meses quizás, de que el creador de Ruby on Rails, David, DHH creo que se lo llaman así de forma acortada, había en principio integrado TypeScript dentro de Ruby on Rails para la parte que comunica el servidor con el cliente, que estaban haciendo ahí una serie de mejoras, cambios. Y al principio creo que utilizaban CoffeeScript hace mucho tiempo y decidieron probar o darle un tiento a TypeScript. La cosa parece que no fue muy bien y el creador decidió eliminarlo todo, eliminar todas las referencias que tenían de TypeScript, incluso tipos y conversiones y todo el código que se había hecho alrededor de TypeScript. Y dejarlo todo en lo que llaman vanilla JavaScript, en lo más simple de JavaScript, porque no querían complicarse más. A partir de ahí empecé a escuchar que había un poco de revuelo en base a si TypeScript iba a durar o no iba a durar. Microsoft está detrás de ellos, así que da la sensación de que Microsoft en principio no son de los que suelen abandonar proyectos. Pero, ¿cómo ves tú así el futuro de TypeScript?

Yo, yo veo claro que va a seguir adelante. Igual me equivoco, también te lo digo, pero yo veo claro que va a seguir adelante porque realmente tampoco, tampoco es nada, nada tan raro. Yo comprendo que alguien que viene del mundo Ruby diga, bueno, es que TypeScript no me gusta o no me, no me ha encajado, me vuelvo a vanilla JavaScript. Pero cualquier persona que viene del mundo de mundos tipados, es decir, cualquier persona que trabaja en servidor y cosas así, con lenguajes tipados, dices, hostias, que una de las cosas maravillosas de TypeScript es que tengo esa, pues esa seguridad, esa robustez, ese, ese, el estar tranquilo de que mis tipos son lo que dicen ser. Con lo cual yo creo que Ruby y Ruby on Rails probablemente no sea específicamente el mercado donde el tipado brilla. En cambio, para mucha gente TypeScript es una herramienta muy, muy, muy útil, especialmente en proyectos grandes, para poder tener esa consistencia, esa seguridad de que si modifico algo y rompo algo, el compilador va a ser capaz de detectarlo o va a ser capaz de detectar un porcentaje significativo de las formas que puedo liarla. Porque bueno, yo llevo muchos años programando y yo la sigo liando. Yo no sé tú, pero yo la sigo liando a día de hoy y sigo cometiendo errores y sigo metiendo código que cuando voy a ejecutarlo, cuando voy a compilarlo, no compila o no hace lo que yo esperaba. Entonces todo lo que el compilador sea capaz de de pillarme, pues mejor que mejor. Y en este caso TypeScript es eso, es, es un, es un seguro que yo creo que toda la gente que está convencida con los, con el sistema de tipos no tiene ninguna duda entre TypeScript y JavaScript. Puede no parecerte la solución idónea o la forma idónea de implementar los tipos, en eso puedes Podemos tener seguramente gente que piense de una manera u otra, pero entre no tener tipos y tener tipos, cualquiera que haya experimentado esa seguridad de programar con tipos probablemente vaya a preferir tener tipos.

Y si tuvieses que hacer un proyecto así nuevo, que vamos, no fuese ninguna migración de ningún proyecto anterior, sino que dices tengo, creo que lo llaman greenfield, el campo verde para empezar a crear el proyecto desde cero. En frontend casi que me queda claro que elegirías TypeScript por todas las posnadas que dices de él, pero en backend, ¿elegirías Go o Rust o intentarías algún otro lenguaje nuevo?

Depende, depende del proyecto. Depende, y depende del propósito del proyecto. Si yo hoy fuera a hacer un proyecto que yo quiero, por ejemplo, imagínate que quiero hacer un proyecto para sacarlo comercialmente y demás, personalmente elegiría Go por varios motivos. Uno es, es en el que me siento más cómodo a día de hoy y probablemente es en el que vaya a poder sacarlo lo más rápido posible. Creo que es un lenguaje muy rápido de programar y que es ideal para el go-to-market. Y por otro lado, es muy fácil encontrar programadores que puedas reciclar para que programen en Go. No es lo mismo para Rust. Si tú coges a un programador de Python y lo quieres convertir a programador de Rust, le va a llevar mucho tiempo. Si quieres convertirlo a programador de Go, en cuestión de 2-3 semanas puede estar haciendo cosas sin demasiado problema. Y en cuestión de 6 meses, un año, se puede considerar un programador bastante robusto en Go. Si pretendes conseguir lo mismo con Rust, no creo que eso pase así. Se lleva mucho tiempo hasta que eres capaz de ser mínimamente productivo. Pero bueno, eso si quisiera hacer algo que en lo que Go pudiera funcionar bien. Si funciona bien con Go, cogería Go. Si Go va a tener problemas, por ejemplo, si quiero hacer una biblioteca que se puede importar de otro lenguaje, no elegiría Go. Si quisiera hacer un programa de tiempo real, no elegiría Go porque el garbage collector ya me va a meter unas latencias que no puedo manejar bien. Hay una serie de programas, serie de lenguajes, hay una serie de problemas que Go no va a solucionar igual de bien que Rust, por ejemplo. En esos casos, probablemente Rust. Si a día de hoy tuviera que hacer un proyecto y no tuviera limitación de tiempo, no tuviera una visión empresarial y es solo por pasar el rato y divertirme, probablemente lo haría en Zig porque quiero aprender C y para mí una forma de divertirme es aprender un lenguaje nuevo, con lo cual ese sería lo que haría. Para el frontend usaría TypeScript, pero lo que voy a decir ahora probablemente suene un poquito a señor mayor. También probablemente, bueno, señor mayor en el mundo de JavaScript, vale. No voy a decir jQuery, que eso ya sonaría señor muy mayor, pero probablemente lo que yo utilizaría a día de hoy para para, para frontend seguiría siendo TypeScript y React, porque es algo que yo me siento muy cómodo, que creo que tiene un equilibrio muy bueno entre darme la libertad a mí de elegir cómo quiero hacer las cosas y qué bibliotecas quiero usar, y coger los diferentes building blocks y ponerlos juntos. Y hay otras bibliotecas a día de hoy que son como más integradas, que además se vienen, no, el server-side rendering y un montón de cosas, y Para mí me parece, está muy, entiendo que está muy bien si quieres la solución completa y quieres, pero yo no quiero la solución completa, yo quiero hacerme mi propio, yo me gusta montarme mi propio Lego, yo me gusta montarme mis propias piezas. Ahí también entra muy en juego la filosofía de Go, de usa la biblioteca estándar, es decir, móntate tu servidor web, móntate tu propio Es decir, en Go hay frameworks, pero no hay muchos frameworks. De hecho, hay poquitos frameworks y la mayor parte de los proyectos ni siquiera usan esos frameworks. Tenemos sistemas de routing, tenemos sistemas de gestión de las requests y las response, pero la mayor parte de ellos no te engloban algo. No, no hay, hay pocas cosas que sean parecidas a Ruby on Rails o Django. En Go. Con lo cual, esa misma filosofía me gusta aplicarla en el frontend. Uso bibliotecas específicas para las cosas que yo quiero y las aplico de la manera que yo quiero. Pero vamos, ya te digo que cualquiera, probablemente los chavales más jóvenes que están experimentando con cosas nuevas y demás, dirán, bueno, es un señor mayor que aprendió React en su momento Y ahí sigue. Y es más o menos cierto, pero bueno, también he experimentado con otras cosas en cualquier caso. Pero eso sería un poco el stack que yo usaría a día de hoy.

Además, llama la atención eso de que hayas mencionado Zig, un lenguaje que está también surgiendo mucho y se habla mucho de él. Y vamos, quizás en un futuro podamos hablar de alguna experiencia que tengamos en ese lenguaje De momento tampoco puedo decir gran cosa porque lo conozco así de oídas y todavía tampoco he tenido la posibilidad de probarlo.

Sí, yo poco lo he probado también.

Casi llevamos una hora, así que si quieres decir algo para finalizar.

No, nada, que ha sido un placer esta conversación contigo, una conversación muy agradable, me lo he pasado muy bien. Y nada, gracias por invitarme.

Ha sido otra tarde más en Codeadores y le damos las gracias a Jesús por habernos dado su experiencia con estos lenguajes y ha sido muy interesante e incluso educativa. Gracias por haberte pasado y nos vemos la semana que viene en otro capítulo de Codeadores. Gracias por estar ahí.