Go con Jorge Fuertes

Pues estamos otra tarde más aquí hablando del lenguaje de programación y hoy le toca el turno a Go, que tenemos un vídeo bastante reciente en el canal de YouTube hablando de este mismo lenguaje que ha tenido bastante aceptación porque incluso los pequeños de mi casa, no sé si es por los gofers, pero les encanta la vocecilla y toda la interacción que tienen estos gofers. Bastante ameno lo que es con las mascotas y todo eso. La verdad es que atrae bastante visualmente y no solo por lo que es el lenguaje en sí. Bueno, esta tarde estamos aquí con Jorge, Jorge Fuertes Alfranca, si no recuerdo mal. Y tú eres programador ahora mismo de Go, así que así, si te quieres presentar y decir un poco así cuál fue tu primer lenguaje de programación Vamos allá, ¿en qué trabajas para utilizar Go?

Bueno, pues es una larga historia, no quiero aburrir a tu audiencia con eso, pero bueno, ya tengo una edad, tengo 53 años ahora mismo, y trabajando en el campo de la informática pues llevaré unos 30 años aproximadamente. Entonces, ¿cómo empecé? Pues queda muy lejano, pero Yo me aficioné mucho a los microordenadores de 8 bits, especialmente pues al ZX81, al Spectrum, Commodore 64 o el Commodore VIC-20. Tuve acceso, tuve suerte de tener acceso a alguno de esos microordenadores en aquellos tiempos. Y vaya, cuando la primera vez que vi una pantalla en negro y un simple cursor parpadeante, fue como una iluminación. Sí que es para algunas personas, seguramente para tu audiencia no, no, pero para muchas personas es muy difícil de entender. Pero seguro que me vais a entender. Yo tuve una iluminación cuando vi ese curso. Dije, aquí detrás no sé lo que hay, y como no sé lo que hay, para mí es un mundo infinito. Y ese mundo infinito de posibilidades pues me atraía como un abismo. No lo sé explicar muy bien, de acuerdo. Entonces empecé a a trastear muchísimo con todos esos cacharros. Y mi primer lenguaje pues quizá fuese el BASIC que venía con alguna de esas máquinas. No sería el Microsoft BASIC, eso lo conocí más tarde, aunque bueno, en Commodore sí creo que era una versión de Microsoft BASIC, si no recuerdo mal. Pero en el Spectrum pues no, era una versión custom de ellos de BASIC. Y en Amstrad pues también creo recordar que era de alguna empresa como Málar Locomotiv o algo de eso. Con esos BASIC empecé a trastear y ahí ya enseguida, si tenías cierto interés, pues enseguida ibas a necesitar algo más, porque eso se quedaba muy, muy lento. Era ciertamente un poco farragoso de programar y para hacer cosas sencillas estaba muy bien el BASIC, pero enseguida se te quedaba corto. Y entonces de ahí seguro salté al ensamblador. El ensamblador de Z80 sobre todo. Me encantaba ese procesador. Bueno, me sigue encantando a día de hoy. Y el del 6502 tenía unas ideas muy interesantes, ¿no? Con el set reducido de instrucciones y todo esto. En fin, ya me estoy liando por las ramas. El caso es que yo no sabía muy bien qué hacer con mi vida en aquella edad y tal. Pues lo que tenía claro es que los estudios reglados no eran para mí. Y no tenía problemas con la autoridad también, no soportaba que nadie estuviera por encima de mí o me diera órdenes. En fin, era una personalidad un poco complicada, sobre todo para aquellos tiempos y sobre todo para aquellas edades. Y entonces busqué la forma de empezar a ganarme la vida con los ordenadores. Y por suerte, allí en mi barrio había una pequeñísima tienda de informática de un tío que recordaré toda la vida, Javier Mainat. Ese tío vendía los primeros microordenadores ahí en el barrio. Arreglaba televisores y arreglaba faxes y ese tipo de cosas, pero también tenía algo de microinformática. Y enseguida con él empecé a arreglarle, porque el tío era muy ducho en electrónica, se lo daba muy bien, pero de software y eso no sabía prácticamente nada. Entonces empecé a ayudarle, a echarle una mano para arreglar los ordenadores, para instalar las cosas y tal. Y de ahí pues que ya me metí en ese mundillo. Y mira, de un trabajo fui saltando a otro y a otro y a otro. En principio con la electrónica, luego con la administración de sistemas, y luego ya pues más adelante, por culpa quizá de Amazon y de Cloud y todo esto, pues me pasé a la programación, ¿no? Porque la administración de sistemas estaba quedando un poquillo, cada vez había menos trabajo. Menos del que me gustaba a mí, de redes, de UNIX, de AIX, de todo este tipo de cosas. Y bueno, como también me gustaba programar, y de hecho cuando administraba sistemas programaba mucho para automatizar cosas, pues me metí a programar, empecé a buscar trabajos de programador y tal, me fueron saliendo, se me da relativamente bien, aunque no soy tan académico como mucha gente que a lo mejor ha hecho una ingeniería de de ingeniería de software o algo así. Entonces, como todos los autodidactas, tengo mis lagunas en otras cosas, pero hay muchas cosas en las que he podido profundizar de una forma que no ha podido hacer alguien que sí ha seguido ese tipo de estudios y tal. Y la gran ventaja que tengo es que conozco los ordenadores casi desde los inicios, o al menos desde lo que conocimos como los inicios aquí en España. Y entonces tengo ese fondo de saber cómo funciona un microprocesador, saber cómo funciona el lenguaje binario, lo que es un ensamblador, y sé cómo hacer cosas en 40K de memoria, y eso también es muy importante y tal. Entonces, bueno, pues es un poco mi background. Y en los últimos años, con lo de Go, vaya, yo estaba buscando, ¿sabes estas famosas listas que suelen salir de cuáles son los lenguajes mejor pagados de este año? ¿Qué están demandando más las empresas en este año? Yo estaba echando un vistazo por esas listas y vi Go y dije, coño, esto está en los primeros puestos de mejor pagado y tal, y más requerido porque hay pocos programadores. Y bueno, voy a echarle un vistazo. Vaya, le echo un vistazo y me gustó desde el primer momento porque me recordaba una especie de C, no un C moderno, pero más cómodo de usar, más sencillo, más que compiladores Es una bestialidad, es una idea maravillosa. El compilador es una genialidad. Poder compilar programas en milisegundos y tal, aquello me encantó. Poder compilar cruzado para cualquier plataforma, los despliegues de un solo binario, incluso con cosas embebidas y tal. Bueno, en la primera semana que lo estuve usando ya me enamoré de Go. Y entonces pues empecé a ver vídeos, lo típico, a leer libros. Iba a hacer mis propios programas y tal, y enseguida pues le cogí un poquillo el chino. Aunque realmente poder tener una cierta maestría en Go no es una cosa, lo digo porque nadie se crea que es así, incluso aunque tenga experiencia en programación, que yo la tenía, no es una cosa de 2 o 3 semanas. Esto tardas unos meses en realmente coger, llegar a comprender bien el lenguaje. Entonces, que nadie se desanime. Pero unos mesecillos de leer, de probar y de hacer cosillas y tal se van a pasar hasta que coja una cierta soltura con el lenguaje. Y eso, y últimamente pues, perdona si me extiendo demasiado, pero últimamente ya lo último que iba a decir es que hace como un año, después de pasar por varias startups, todos estos proyectos que me gustan, que sabes que posiblemente no va a salir adelante, pero sí te mola mucho y Y estás ahí en la startup haciendo lo que buenamente puedes, tu contribución a que eso pueda tirar o lo que sea. Pues después de eso me salió una oportunidad, me llamó un amigo para trabajar en Volkswagen Digital Hub porque necesitaban un programador de Go. Y bueno, pues allí que me metí y el último año he estado ahí. O sea que básicamente hasta ahí se acaba la historia.

Lo que estaba diciendo era que doy fe de que no es tan fácil como decir de venga, me pongo en una tarde o en un fin de semana y tomo el lenguaje y ya me hago con él. Hemos pasado por ahí, no, no es una semana, puede ser un mes largo, y depende de la cantidad de tiempo que tengas para aprenderlo y los recursos que puedas a los que tengas acceso.

Y aún con eso, aún con eso no vas a tener, no vas a tener una cierta maestría, no. Quiero decir, te puedes postular a, por ejemplo, como junior en un mes, posiblemente sí, si le metes caña y tal. Y luego ya la experiencia de unos meses de experiencia ya trabajando con eso es lo que te va a dar ese mayor conocimiento, no. Y luego pues también depende de los proyectos que te toquen. Bueno, si te toca una aplicación, una aplicacioncilla web normal y corriente, una PRREST y tal, pues a lo mejor tampoco vas a profundizar demasiado en el lenguaje. Ahora, si te toca una cosa compleja con canales, gorrutinas, concurrencia, tal, pues ahí sí vas a tener oportunidad de darle un poquito más de caña a todo, ¿no? Pero bueno, independientemente del proyecto, en los ratos libres se pueden hacer muchas cosas. Yo tengo por ahí algún GitHub abierto con un un sistema de monitorización y cosas así que son un poquito más complejos y que mira, necesitan de ayuda. O sea, que si a alguien le interesa, adelante.

Hace una semana estaba hablando también con Rafa, que es programador de C, C++, C#, y recuerdo que me dijo que ahora mismo, por ejemplo, estaba programando sistemas embebidos y que utilizaba principalmente C++ porque era lo que más se demandaba, era un puesto bien pagado y demás. Y realmente estuve echándole un vistazo y en la oferta de trabajo estaba ahora siendo bastante demandado C++ y los sueldos no eran tampoco muy bajos. ¿Qué hubieses hecho si uno de los lenguajes al mismo nivel que Go hubiese sido C++? ¿Te hubieses tirado por ahí?

No, no, no, no, creo que no. Creo que C++ sí lo he llegado a probar, pero no No me convenció. Como sí que me asomé y no me convenció. En Go me asomé y me convenció bastante más rápidamente. En C sí, en C he hecho mis cosillas. Tampoco soy un máster de C, pero sí que hice con un compañero, con un colega que es un genio, hicimos un emulador de Spectrum para microchip, el ESP32, y lo hicimos en C. Y vaya, salió una cosa niquelada, muy, muy, muy interesante, muy bonito. Nos liberamos y ya ha cambiado muchísimo. Hay un montón de gente que lo mantiene y tal, y han hecho unas cosas increíbles sobre eso. Así que el C sí que lo disfruté, pero el C++ ya me parece que no, que no es para mí.

Y viniendo de programación de bajo nivel, porque has comentado lo del ensamblador de Z80, y supongo que también atarías tus pinitos con el del 8086 y los típicos de PC, ¿no?

Sí, lo que pasa es que yo al PC entré tarde porque yo era de Commodore a muerte y entonces lo que tenía era Commodore 1000 y me dedicaba a despreciar a los que tenían PC. Entonces sí que entré tarde, sí que vi el 8086 y todo eso. Al final son Z80, es una evolución del 8080. El 8080 es lo que se llevó Federico Faggin, no, a Zilog. Y el Zilog Z80 es un 8080 mejor. Entonces, si tú conoces Z80, al final conoces 8080, 8086, viene a ser lo mismo. Para mí mejor el Z80, vale, pero bueno, viene a ser lo mismo. Y el Intel de hoy en día no deja de ser un Z80, es mucho más complejo, con muchos cores, con muchísimas cosas, con muchísimos gigahercios. Pero al final viene de lo mismo. Y perdona, ¿cuál era la pregunta? Porque me he ido por las ramas.

No, no, estaba simplemente divagando un poco viendo lo que es la trayectoria. Me estaba un poco elaborando la pregunta de que, claro, al pasar por diferentes tipos de lenguaje ensamblador, el lenguaje C, que te iba a preguntar también qué opinión te merecía Rust.

Sí, pues es otra cosa también que me ha sumado un poco. Tengo el libro por aquí encima, vale, ni siquiera lo he guardado en la estantería, de Rust Programming Language. Lo tengo por aquí encima y le he estado echando vistazos, le he estado echando vistazos al compilador, al cargo ese, al tal. Y vamos a ver, no me he visto en la necesidad de hacer algo de tan bajo nivel, en mi opinión, que pueda necesitar Rust. Pero si me vieras en esa necesidad, pues quizá no es una mala opción. Lo que pasa que, claro, en la actualidad lo que vamos programando aplicaciones, tanto mis proyectos personales como los de mi trabajo, son aplicaciones que son API REST, o como mucho pues templates en HTML, base de datos, cosas de estas y tal. Yo no me veo haciendo eso con Rust porque creo que es bajar el el nivel del lenguaje sin necesidad. Es que Go es rapidísimo, Go es un Ferrari, o sea, no necesitas nada más rápido para hacer este tipo de aplicaciones. Entonces pues no lo veo. Ahora bien, si tuviera que volver a programar sistemas embebidos o microcontroladores o algo así, no lo sé, porque tampoco sé el soporte de Rust para eso. Igual sí que podría, así que podría ir ahí, no lo sé. Bueno, sé que ha tenido mucho éxito porque incluso ahora se van a hacer cosas del kernel de Linux con Rust, programación de drivers y tal. Entonces sería un poquito ese el punto, ¿no? Tenemos que hacer un driver para el kernel de Linux para hacer no sé qué, pues seguramente no se va a poder con Go, o con Go podremos hacer el controlador de espacio de usuario, ¿vale? Pero no podemos meter nada dentro del kernel. Sin embargo, con Rust Sí, pues ahí sería el punto quizás de mirar eso.

Esa parte de Rust en el kernel hay que tomarla ahora con mucho cuidado y con pinzas porque el desarrollador principal, que de hecho era español, dejó el proyecto por la cantidad de lucha interna que hay dentro del kernel de Linux entre la gente que es aférrima a C y no quiere ceder ni un poquito para Rust y la gente que está entrando ahí, que está pidiendo Rust y que no es capaz de desplazar el código que hay hecho en C, porque obviamente los que están ahí pues quieren que siga estando en C.

Bueno, que te digo una cosa, es que C para ese tipo de rollos es imbatible. No sé cómo, quiero decir, que no ha salido posiblemente nada mejor. Es que C es un lenguaje que es relativamente sencillo Si conoces un poquito la máquina y lo que quieres hacer, y es relativamente sencillo, es muy, muy, muy portable. O sea, todo esto de que Java es el lenguaje que va a funcionar hasta en su lavadora y tal, luego resulta que era mentira, que va a funcionar hasta en tu lavadora C. Entonces ahí yo creo que C no ha sido superado. Hay cosas ahora muy interesantes como el impermanence y estas cosillas, pero claro, son muy minoritarias. Y entonces yo creo que ese ahí tiene un nicho que no va a desaparecer en los próximos 30 años, y esto estoy seguro, jugaría algo. Yo creo que es imposible. Entonces bueno, pues no lo sé, sé que hay proyectos muy interesantes ahora en Rust, o sea, yo no puedo hablar mal de Rust, pero sí que te digo que no es de tanto nivel como Go, y entonces para la programación de aplicaciones o sistemas de este tipo de paso de datos, tratamiento de datos e interfaces de usuario, cosas de esas, Go sería para mí el límite de bajo nivel. O sea, yo no bajaría de ese nivel para hacer ese tipo de cosas. Simplemente eso. Ahora bien, para programación de sistemas o para hacer un sistema operativo, un driver, un tal, posiblemente Rust tenga ahí su nicho y sea un buen nicho. Aunque tiene un gran competidor que es este y C más Clang.

Sobre la programación en Go, de momento todos los lenguajes que llevamos dichos, salvo por excepción C++, ninguno tiene orientación a objetos. Nosotros hemos levantado un poco la perdiz en el canal de YouTube porque publicamos un vídeo en el que decíamos que realmente no lo dice en el título del vídeo, pero se llama El desastre del billón de dólares, y cuando empieza el vídeo habla de Alan Kay y realmente lo que es la orientación a objetos, pero la implementación específica que hay en lenguajes como Java, C# y otros lenguajes que tomaron la idea de los objetos, pero no de los mensajes. Entonces, ¿tú crees que es estratégica la idea de Go de no implementar orientación a objetos?

Sí, sí, sí, creo que tiene algunas decisiones bastante bien tomadas, en mi opinión, la mayoría. Vale, yo hay días en los que me jode no tener un preprocesador, por ejemplo, pero luego al rato pienso, ¿y si tuviera el preprocesador qué hubiera hecho aquí? Pues hubiera montado una liada que luego no había quien cogiera mi código, ¿sabes? Y ahora pues no lo puedo hacer, y como no lo puedo hacer, pues lo hago de otra manera y mi código sigue siendo legible para el siguiente que venga. Por eso creo que es una buena decisión, por ejemplo, no tener un preprocesador. Y con lo de los objetos pasa un poco lo mismo. Mira, yo recuerdo los primeros libros que leí sobre objetos eran de un lenguaje que ya nadie se acordará, que era una evolución de Clipper, que Clipper era un lenguajillo para programar aplicaciones en MS-DOS, y entonces sacaron un lenguaje que era una especie de Clipper orientado a objetos. Y yo cogí el libro muy emocionado y empecé a leerlo y decía, vamos a ver, un objeto en informática viene a ser como un objeto en la vida real. Por ejemplo, una mesa tiene patas y una silla puede tener patas y ruedas. Y yo leía eso y no entendía nada, pero ni un carajo, te lo digo en serio. Yo que venía de programar no entendía absolutamente nada. Digo, ¿pero qué cojones están diciendo? ¿Qué quiere decir que una mesa tiene 4 patas? Y que no me hacía gran idea. Entonces, para mí, aunque nos lo hayan querido vender como algo natural, para mí es un patrón antinatural. O por lo menos a mí no me encajaba. Ahora luego con el tiempo y utilizando cuando a PHP le metieron, yo estaba en aquellos tiempos de PHP cuando la adaptación no estaba allí y tal, y le metieron orientación completa a objetos y ahí empecé a jugar con los objetos y luego ya pues en Ruby, que todo es un objeto, hasta el número 1 es un objeto y todo este tipo de cosas, pues ya como que te acostumbras un poco y ya piensas en clases y en herencias y en sobrecargar métodos, en constructores y todo esto y te haces un poquito la cabeza y vas tirando más por ahí. Entonces claro, luego de repente llegas a Go y te dicen, no, no, lo de los objetos olvídate, aquí hay unas estructuras y como mucho las juntas métodos, pero no tienes constructor, no tienes herencia, y dices, ah, bueno. Y entonces te cuesta un poquito otra vez la aceptación, pero una vez que estás adaptado dices, ¿para qué carajo querría yo los objetos? Antes, para nada, para liarla. Y sí, sí, efectivamente, en ese sentido estoy contento también con ese tipo de decisiones. Luego tiene unas, algunas bastante buenas, como tener 25 palabras reservadas, creo que son, pues está muy bien, o sea, 25 palabras reservadas, no te sales de ahí. Y con lo cual, lo que son las bases del lenguaje y el control del flujo y tal, eso sí que tenías tu razón al principio, lo puedes conocer muy rápido. En un par de semanas que te pongas a hacer cosillas y tal, te conoces esas 25 palabras y lo que hacen y tal. Entonces son ideas que sí me parecen buenas. Luego también eso hace que el compilador sea muy rápido, que la memoria se pueda manejar muy bien. Hay una decisión que no le gusta mucho a todo el mundo, que tiene muchos detractores, que es el garbage collector, el garbage collector bien integrado. Aunque se puede llegar a desactivar y hacer cosas por ahí, en principio no es fácil y no es lo habitual y no se debe. Entonces, en principio, Go es un lenguaje con garbage collector, igual que Java. Lo que pasa que el garbage collector de Go es muy efectivo y muy rápido. Entonces, hay decisiones, algunas te gustarán más, algunas te gustarán menos, pero el paquete en general está muy bien armado y, en mi opinión, muy bien pensado.

Y yendo un poco al lenguaje, ¿qué partes son las que tú consideras que cuesta un poco más aprender?

Yo creo que te va a decir todo el mundo lo mismo, y sobre todo van a ser, va a ser concurrencia, entender cómo funciona la concurrencia, las gorrutinas y los canales, vale. Pero también te voy a decir que de entrada eso no hace falta, que tú podrías obviar todo lo de concurrencia, incluidos los canales, incluidas las gorrutinas y tal, y aún así ponerte a programar. Un API REST, por ejemplo. Si hablamos desde el punto de vista de un API REST, en principio tú no vas a necesitar ni gorrutinas ni canales, porque eso te lo va a hacer el framework que estés utilizando o la biblioteca estándar. Entonces, una cosa que sí sería importante y que no es fácil de entender de entrada es el paquete context. El paquete context yo creo que te lo tienes que conocer. Y otra cosa que también sería de bastante interés son los mutex, los los cerrojos, los semáforos, poder hacerte un mapa de memoria y ponerle un lock, que es sencillísimo, y luego poder bloquear ese objeto desde distintos sitios cuando vas a leer o escribir datos, pues eso sería un paso fundamental que posiblemente sí vas a necesitar y que es fácil, pero tienes que, eso sí que aconsejaría a cualquiera que lo conozcas desde el principio, los mutex. El paquete Sync y el paquete Context. El paquete Context es importantísimo y además una vez que lo entiendes dices, hostia, qué genialidad, qué genialidad que con un request me entre un context o que todo, que este context tenga un timeout, le pueda poner un timeout, un deadline, lo pueda cancelar en cualquier momento. Es fantástico, fantástico el paquete Context. Ya te digo, es súper importante conocerlo. Las gorrutinas es una de las grandes cosas que tiene Go, es como lanzar otro proceso que haga una cosa en background, solo que no es un proceso de sistema, es un proceso de Go. Y como proceso de Go es muy rápido, muy efectivo, ocupa muy poca memoria y puedes lanzar millones. Si quieres hacer cosas que necesiten concurrencia, que no es paralelismo, es otra cosa, es concurrencia, es muy, muy interesante y muy efectivo. Entonces, cuando tú te pones a lanzar gorrutinas, yo he hecho pruebas de lanzar millones de gorrutinas y tal, el propio Go es quien te va a gestionar los cores de la CPU y todo este tipo de cosas. Tú no te tienes que preocupar si lo lanzas en un core, en otro, o si se va a comportar de forma paralela a otro. Por eso te dicen que no es paralelismo, es concurrencia. Incluso con un solo core se pueden lanzar 2 rutinas porque el propio runtime es el que va a ir cortando una y otra y asignando tiempos. Entonces, vaya, es importante, pero también te digo, de entrada para ponerse a programar no hace falta. Y la segunda parte que decías de los canales, los canales vienen a ser, el que conozca Smalltalk puede saber más o menos de lo que estoy hablando. Los canales son pues como unos IPCs, como un Inter-Process Communication, vale, solo que tú lo creas y lo asignas a una variable, y entonces en esos canales puedes tener gorrutinas escuchando o escribiendo. Y entonces cuando tú escribes datos, la otra gorrutina los puede recibir y operar sobre esos datos y responder por otro canal. Y todo ese tipo de cosas. Entonces ahí tendrías una comunicación interna entre distintos procesos o rutinas o lo que sea que te soluciona mucho la vida si tienes que hacer cosas complejas. También te digo, repetimos otra vez, para hacer una API REST no te va a hacer falta.

Ahora ya hemos hablado un poco de las características que más brillan en Go, como es la compilación, la concurrencia. Yo creo que es otra de esas joyas que tiene este lenguaje. Incluso los contextos, que te hice caso y le eché un vistazo, y la verdad es que son muy útiles, sobre todo cuando estás desarrollando cosas de servidor. Pero, ¿qué cosas? Porque yo, por ejemplo, cuando estuve revisando el lenguaje, me encontré que la gestión de errores no se hace por try-catch, por lo cual me llevé una sorpresa agradable, ¿no? Pues ya estaba bastante cansado de lenguajes que utilizan try-catch, y entonces manejar los errores como retorno, incluso como segundo retorno en lugar de principal, lo vi como una idea genial. Pero sin embargo vi que tiene goto. ¿Qué cosas tú señalarías que no te gustan del lenguaje? Yo, para mí es esa.

Bueno, vamos a ver, a mí esa yo no la uso. Me recuerda mucho, no sé si te vas a acordar, pero a mí me recuerda a Fort. Es como decir, bueno, ya aquí trabajamos y en esta posición de memoria le coloco un label y luego llamo a ese label y vuelvo allí. Es un poquito eso. Puede ser útil en algún tipo de bucle para hacer un goto a una parte intermedia del bucle, porque si hicieras un continue volverías al principio del bucle, si acabas el bucle volverías al principio del bucle, y la otra opción que tienes pues hacer un return o un break y salir del bucle. Con esta opción, la utilidad que yo le veo es poder llamar desde un punto del bucle a otro punto intermedio del bucle, saltando el principio, por ejemplo. Entonces, ¿cuál es el problema? ¿Y por qué no gusta? Porque esto de nuevo permite liar las cosas. Cuando habíamos quedado en que hay 25 palabras reservadas, un lenguaje muy contenido, la imposibilidad de liar las cosas y tal, pues llega el voto este que no sé quién se le ocurrió y no sé quién consiguió que Ken Thompson o Rod Pike o quien fuera consiguió metérselo allí, o igual se les ocurrió a ellos mismos porque todo el mundo tiene una mala tarde. Entonces metieron esto del voto y la verdad. En general, en aplicaciones serias esto está prohibido. La idea es que nadie, nadie hace esto, pero en un videojuego indie que estás programando tú solo, pues igual te resulta útil, ¿por qué no? Úsalo. Pero ya perjudica un poquito a la claridad del código. Y lo que decías de la gestión de errores, totalmente de acuerdo. Si vienes de Ruby, de Java, de PHP, qué sé yo, de un montón de lenguajes y estás acostumbrado a las excepciones, en Ruby es una locura ver las excepciones. Tienes que tirar una excepción, hacer un raise, entonces luego desde otro sitio que ya no recuerdas dónde está, estás cogiendo las excepciones y ahí comparando con los tipos de excepciones a ver qué cosa es y con eso contesto una cosa y contesto otra. En un principio puede parecer útil porque en una aplicación de Ruby, por ejemplo, ahí puedes capturar errores subyacentes y esos errores sacarlos a una página de error 500, o si es un error del tipo not found, llamar directamente a 404, y esto podría parecer útil, pero cuando la aplicación se va complicando y tal, eso es una complejidad añadida que a la hora de buscar un bujo de lo que sea, pues está volverlo Y eso en Go realmente no pasa, aunque tenemos una excepción que son los panic. Pero bueno, el panic ya es una cosa, es un último recurso, porque el panic va a tirar la aplicación directamente, o sea, va a dumpear un trace y va a tirar la aplicación abajo. Aunque se puede hacer un recover de un panic, vale. Entonces ahí es donde tenemos Y una nueva liada. Pero bueno, eso no se utiliza en general. En general lo que se utiliza es devolver un error con cada función que llames. Por ejemplo, tú quieres sumar 2 y 2 y tú vas a llamar a una función suma y esa función te va a devolver 4 y un error. Y ese error puede ser nil o puede ser un error. Entonces cuando sales de vuelta de la llamada a esa función, tú lo primero que haces es if error distinto de nil y allí y coges el error y haces lo que sea. En general, en una aplicación, en general lo que haces es patada para arriba. A mí me gusta llamarlo así. Es decir, a mí me ha vuelto un error una función, patada para arriba, return error en mi caso, ¿no? Return un dato vacío o return un nil y además el error. Y así ese error va escalando hacia afuera hasta que llega a donde tenga que llegar, donde finalmente va a ser manejado, ¿vale? Al final me dirás, pues es lo mismo que las excepciones. No, pero tienes toda la cadena y ese error se ha podido gestionar in situ en ese momento porque se puede gestionar ahí. Por ejemplo, voy a leer un directorio de disco y ese directorio no existe. Pues igual simplemente lo único que tengo que hacer es crear el directorio y ya está, ¿no? Por poner un ejemplo, o llamo a Redis para recuperar una clave y esa clave ya no está disponible porque ha expirado. Me viene un error, pues yo ahí gestiono el error simplemente pidiendo el dato real base de datos y guardando la API en Redis y siguiendo adelante. Y si son otro tipo de errores, pues más que requieran de gestionar fuera, porque al final donde estás haciendo eso es una función que también te han llamado desde otra parte, pues simplemente devuelves el error, pero ni te preocupas de lo que pone el error. Has tenido tu error y para arriba, y ya se gestionará donde se tenga que gestionar. A mí me parece una idea maravillosa. Creo que tú coincides conmigo por lo que has dicho.

Sí, sí. ¿Y algún aspecto que no te guste o que cambiarías del lenguaje?

A ver, a mí, ¿sabes esta frase que dicen de cuando uno tiene un martillo del cielo le llueven los clavos? Pues a todos nos pasa esto, no vamos a negar. O sea, si tú estás muy metido en Go, programando todos los días en Go y tal, pues todo lo quieres hacer en Go. Es que vas a hacer un script del bash y aunque yo he hecho muchísimos en mi vida, Pues te da asco. Joder, esto lo podría hacer en Go y quedaría mucho mejor. Pero me pones una cosa sencillísima. Entonces quizá echo un poquito de menos el no poder reducir el runtime, el no poder cortarlo y coger solo los cachos que necesite, porque el runtime me ha espesado. O sea, tú haces un hola mundo en Go y ese hola mundo te va a ocupar, pues qué sé yo, 2 megas, por ejemplo, y no lo puedes bajar de ahí. Puedes bajar un poquito haciendo un strip y quitándole las tablas de debugging y estas cosas, pero no mucho. Entonces, ¿me gustaría poder hacer un hola mundo en 2K? Pues quizás sí. Hay un Go por ahí para microcontrollers, pero claro, no es el de uso diario, es otra cosa diferente. Entonces, el runtime te vas a comer todo. En el runtime te vas a llevar las rutinas, los canales, la concurrencia. El garbage collector, todo te viene en un pack y ese runtime te lo vas a comer lo quieras o no lo quieras. Entonces eso es una cosa que quizá evita que Go pueda ser utilizado para cosas muy pequeñas o para programación de sistemas o para sistemas embebidos o para microcontroladores. Y ya te digo que hay un Go para microcontroladores con cierto soporte de los más famosos. Y bueno, me gustaría poder decir a veces, bueno, quiero hacer un programita en Go, no voy a utilizar concurrencia. No voy a utilizar el garbage collector porque ya voy a salir enseguida de la aplicación y me da igual, se libere toda la memoria al salir o quiero hacerme yo mismo un malloc o lo que me dé la gana. Y esa parte no puedes llegar ahí, es muy complejo. Entonces, en ese sentido, pero bueno, si tienes desde el punto de vista que Go es un lenguaje que está a más alto nivel que eso, pues lo tienes que tener claro. Pero bueno, quizás sí sería un punto que me hubiera gustado que se pudiera hacer algo, aunque costase más y no fuese lo estándar, ¿sabes? No sé.

Puede que el tamaño sea porque también compila de forma estática para no depender de nada.

Sí, también es verdad que te mete dependencias estáticas que, bueno, o no dependencias, no están en su propio runtime. Claro, ¿qué pasa en C? Que en cuanto tú te pones a importar cosillas de dependencias y compilas estático, importas cosillas de certificados, de claves elípticas de estas de 255, 19, o RSA, o cualquier cosita de estas, enseguida ese ejecutable se te va a poner al mismo nivel que el de Go de gordura. Te va a quedar igual de gordo que el de Go porque estás metiendo dependencias de cosas y tal. Pero también es verdad que en C, si tú quieres hacer una cosa que pille un dato de un GPIO y te lo escupa por el otro, pero modificado, multiplicado por 3, pues eso en C es un K o 2K como mucho. Incluso te lo puedo hacer en menos si me pongo. Sin embargo, en Go eso no es así. Pero sí que es cierto que en cuanto ya empiezas a hacer una cosa gorda y tal, pues ya esto queda un poco diluido porque los dos van a ser gruesos. Claro, la ventaja de Go también, ¿qué pasa? Que mandas el ejecutable a un cliente o lo subes a un servidor por SSH, sobreescribes el ejecutable anterior, reinicias el servicio y a correr. No tenías que preocuparte de nada más.

Habías dicho sobre la compilación cruzada. Me ha dado por probarlo porque tengo tanto Macintosh como Linux y Windows. E incluso un Synology que tiene una plataforma ARM5. Yo voy a compilarlo a ver si poniéndolo por SSH lo ejecuto y funciona. Y funciona, funciona, funciona, funciona.

Incluso no te tienes que preocupar de, sabes, el runtime y la biblioteca estándar son suficientemente inteligentes para saber que están en Windows y que los directorios funcionan de otra forma y qué tal. O sea, pero es que puedes compilar para No sé, aix, PowerPC, arquitectura vigendiano, yo qué sé, sabes, y te lo compila y luego lo llevas a la iX y rula. Ahí tienen montonazo de sistemas. Si os ponéis a mirar la lista de sistemas, yo qué sé, he visto cosas de lo más peregrino, como UNIX, que no conocía. Y eso que me gusta mucho el UNIX y más o menos he seguido la historia un poco de todas las ramificaciones y tal. Y hay UNIX por ahí que no conocía, para los cuales Go compila. Y no sé, se me ocurren VCDs del tipo Dragonfly o cosas de esas, están soportados, me parece, o estaban. Y luego dentro de esa arquitectura pues tienes los, o dentro de esa plataforma tienes las distintas arquitecturas. Hay MIDA64, PowerPC, MIPS, ARM, ARM64. Y tú le pasas los 2 parámetros de la plataforma de arquitectura, te sale un ejecutable y lo mandas ya a funcionar totalmente estático. Eso sí es una gran ventaja.

Pudiendo compilar para plataformas de diferentes arquitecturas, que incluso he visto que puede compilar para Android y iOS, ¿tú crees que de la cantidad de posibilidades que tiene el lenguaje y donde se puede utilizar ¿Dónde ves que encaja mejor Go para la hora de decir tengo que hacer un desarrollo de este tipo? Go es el que mejor encaja. O sea, ¿lo ves en plataformas móviles y demás o lo ves más encasillado en otro tipo?

No, las plataformas móviles es muy complejo, es que hay que valorar muchas cosas. Por ejemplo, te pones a programar una aplicación para plataformas móviles y tienes que decidir si utilizas un sistema que funcione para los 3 más importantes, ¿no? Y entonces vas a necesitar Flutter o alguna revivida española parecida que no te va a acabar de— te va a hacer una aplicación sencilla, no te va a satisfacer en otras cosas y tal, pero es decir, vas a ahorrar tener 2 programadores o 4 programadores, 2 para cada cosa, ¿no? Y tal. Entonces sé que va a pasar mucho. O un programador de iOS programando en nativo en Swift o lo que usen ahora, no lo sé. Y otro con el Java o el Kotlin este que utilizan en Android y tal, por su cuenta y tal. Pero eso sí van a llegar más abajo nivel, las aplicaciones van a estar mejor hechas. Go ahí tiene difícil encaje, no imposible, porque hay proyectos por ahí como Fein, por ejemplo, me viene a la cabeza, que Fein con Y. Este te permite hacer interfaces de usuario con Go. Y estas interfaces de usuario, aplicaciones, funcionan tanto en web como en desktop como en plataformas móviles de forma nativa. O sea, que se pueden hacer cosas, pero quizás no está tan adaptado a eso como puede hacer los lenguajes propios de Apple, el Swift este, o antes era Objective-C y ahora creo que se llama Swift, ¿no? Y el otro que hay para Android no va a estar tan bien integrado ni va a tener acceso Muchas cosas de APIs nativas o tal, aunque en Go te las curras más o menos. Pero ya te digo que hay cosas. Y desde luego, si quieres hacer una PWA o alguna cosilla de estas, también hay proyectos por ahí que desde luego puedes hacer una single page application como si fuera una PWA y colarlo en una aplicación móvil. Sí se puede llegar a hacer también. Pero quizá no sea su campo más Cómo decirlo, quizás no se hace el terreno natural. El terreno natural de Go para mí es más bien el servidor. El servidor en el que puedes hacer con Go todo tipo de servicios, de comunicaciones entre servidores, de microservicios, de aplicaciones, de APIs REST, de gRPC, todo este tipo de cosillas. La puedes poner en clouds, en servidores de tu todas las arquitecturas. Ese es el terreno más abonado para hoy en el que se da.

De hecho, había visto recientemente, porque normalmente las empresas que utilizan mensajería interna de AMQP, mensajes de estos que se van con un bróker intercambiando entre todos los componentes de la red, he visto que actualmente se utiliza uno que se llama NATS. Y que realmente, bueno, y que está hecho en Go precisamente. Pero cada vez más empiezas a ver que hay más elementos dentro del sistema que se pueden agregar. Bueno, tenemos incluso Docker, que está también hecho en Go, y otros elementos como etcd. Me viene a la cabeza ahora mismo eso, lo de Nats, etcd, Docker. Pero poco a poco se van viendo nuevos.

Yo creo que es más lo que te digo, incluso es esto, cosas de espacio de usuario como puedan ser Docker o incluso etcd o residentes de todo tipo. En mis tiempos en el mesón le llamábamos residentes a esto. Esto, pequeñas aplicaciones o no tan pequeñas que puedan estar funcionando en background, en un desktop y todo eso, yo creo que Go es muy bueno para eso. No sé, a mí me ocurre si quisiera hacer algún servicio de sincronización de ficheros tipo Dropbox, por ejemplo, Go es estupendo para hacer eso. Se podría hacer muy bien. Y lo mismo pues una aplicación de mensajería instantánea o un sistema de telefonía de voz, alguna cosa así. En eso Go es bastante bueno. Eso es lo que hablamos ahí. No habría necesidad de bajar más de nivel y el juego te daría la velocidad más que suficiente para hacer todo eso. Sin embargo, si nos fuésemos un nivel más arriba, pues ya seguramente no podríamos llegar a esa efectividad. Y en cuanto a la mantenibilidad, pues que claro, los juegos son sistemas que puedes mantener a lo mejor con pocos programadores y sin conocer por entero proyecto van a ser capaces de arreglar un bug en una parte que no han tocado porque es bastante legible y con los IDEs de hoy en día, bueno, incluso con el NeoVim o cosas de estas, es muy fácil ir siguiendo el código, las llamadas, incluso el debugger de Go es muy efectivo, es muy amigable de manejar y puedes realmente ir siguiendo la toda la pila de llamadas, los métodos, las variables. En la parte izquierda va saliendo el estado de las variables. Es muy fácil. Bueno, muy fácil, como todo en esta vida, hay que saber lo que estás haciendo, pero vaya, es muy mantenible ese código aunque sea grande y aunque el programador que está de guardia ahora no está de vacaciones, no haya tocado esa parte del código, va a poder Vamos a poder meter mano ahí. Yo creo que en otros lenguajes no se puede decir.

Otra cosa que se me ha olvidado comentar, de una de las cosas que más me gustan de Go en cierta forma, porque hace poco tiempo empecé a echar un vistazo al tema de obsolescencia, que es, vamos, en sí una lacra en muchos campos como la fábrica de hardware. O sea, el hecho de que te hagan un hardware que solo dure 1, 2, 3 años. Pero en software es que estamos acostumbrados a verlo de forma continua. Es decir, yo por ejemplo tengo software que está hecho en Erlang y que he dejado ahí sin modificar durante 2, 3 años. Y ahora intento tomar ese mismo código, compilar con la última versión de Erlang y echarlo a correr, y no se puede. O sea, tienes que siempre modificar alguna cosa que ha cambiado. Para poder adaptar el proyecto de alguna forma. Y bueno, ya no digamos las dependencias, yo hablo únicamente del lenguaje en sí. Pero sin embargo me encontré un artículo de alguien que estaba, vamos, que había escrito un libro de Go en 2016 y que le había dado por descargar todos los ejemplos del libro, los había compilado, y como un un ritual casi que tiene él de comprobar cada año si el material del libro está roto o no. Y dice que se alegra mucho de haberlo hecho con Go porque desde que salió la versión 1.x nada se rompe nunca.

Sí, eso te iba a decir, hay que mirar que sea superior a la 1. Sí, porque yo sí que una vez me pasó, tuvimos un problema con un blockchain que estábamos operando para certificación y estaba hecho en Go. Y el código de la versión que se nos rompió a nosotros, culpa nuestra por no haber actualizado, era anterior a la 1. Y vaya, yo, fue un auténtico pain in the ass, vale. Pero a partir de ahí sí que es verdad que es retrocompatible, y creo que la promesa es hasta la 2. Luego ya veremos, vale, pero en principio es retrocompatible. Yo no creo que vaya, que vaya a dejar de serlo pasada la 2. Pero ya veremos. Sí que es cierto que tengo un cliente que nos llamó hace unos meses, que le hicimos un software para un autómata Go, que bueno, no estaba dentro de Autómata, para ser sinceros. Lo que tenía Autómata dentro es una Raspberry Pi enganchada a un puerto serie o un GPIO, no recuerdo bien, y entonces la Raspberry Pi al arrancar Lanzaba este programa en Go, este programa en Go iba leyendo los estados del robot por el CPU cada equis tiempo y generaba, o era bajo demanda, no recuerdo bien, pero generaba un PDF. Y este PDF lo enviaba por correo a una serie de personas y esa serie de personas podían ver el trabajo del robot o el estado del robot en ese PDF. Esto hacerlo sin Go hubiera sido Se podía haber hecho en Python dentro de la Raspberry, pero el software para mí, y esto igual es un poco controvertido, el software en Python no hubiera tenido la misma calidad ni la misma mantenibilidad, ni 7 años después, creo que fueron cuando nos llamaron para hacer una modificación, hubiera habido quien cogiera eso. Sin embargo, 7 años después cogimos el software Lo abrimos, lo recompilamos con la versión nueva, compiló sin ningún problema, hicimos las 4 modificaciones que nos habían pedido y de nuevo el ejecutable de subida al autómata y a funcionar. Y no volveré a saber nada de ellos en los próximos 10 años, casi seguro. Esto sí que es algo que es realmente una ventaja enorme, una ventaja enorme. Bueno, a no ser que vivas de de mantener tus propias aplicaciones, que entonces quizá sea una desventaja, pero no lo sé. Yo creo que en ese sentido soy muy, prefiero no ganar tanto pero llevarme mucho más a gusto y no tener que estar manteniendo cosas que se rompen cada 2x3. La calidad del software que escribes en Go, creo que no porque uno escriba bien o mal, sino que por el propio lenguaje, el compilador y tal, tiene una calidad una calidad superior a otros sistemas. Y gran parte es eso, la retrocompatibilidad es una baza importantísima.

Aprovechando que comentaste al principio que viendo oferta de trabajo te decantaste por Go porque eran puestos mejor pagados y había suficientes, haciendo un pequeño balance y para dar una recomendación a la gente, ¿Cómo de difícil o fácil está el mercado laboral ahora mismo en Go?

A ver, hay un problema importante ahora en el mercado laboral de informática, y ya no es en Go, es en todos los lenguajes, yo creo. Y es que como llevamos unos años en los que se ha estado ganando dinero, quiero decir, un programador senior puede tener un sueldo que antes quizás solo ganaba un directivo. En España. Entonces, en ese sentido, creo que esto ha atraído a muchísima gente, y esta gente ha creído, quizá en su ignorancia y con toda la buena fe del mundo, que haciendo un bootcamp podían acceder a esos puestos. Eso no es así y no es tan fácil. Entonces, en ese sentido, no quiero desanimar a nadie, porque si uno tiene vocación y cree que esto es lo suyo, adelante, porque para mí es maravilloso y hay que seguirlo, vale. Pero no penséis que haciendo un bootcamp o estudiando un mes Go vais a conseguir un puesto de programador de Go, porque no es así. ¿Qué puedes hacer? Primero, si vienes sin ningún otro background o experiencia, que no me gusta meter a mi lenguaje en sí, si vienes sin ningún tipo de experiencia de programación, difícilmente vas a conseguir un trabajo de programador de Google. Entonces mejor empieza por otra cosa, hazte un bootcamp, estudia fundamentos de programación, estudia un poco cómo funcionan las máquinas, ten una buena base, consigue un trabajo de junior, peleate 3 o 4 años o 5 en ese trabajo y luego coge un lenguaje más duro y empieza otra vez a estudiarlo, a meterte de junior en alguna empresa y hacer tu seniority, y a llegar al punto en el que realmente te manejes el lenguaje, te sientas cómodo con él y te puedas poner a programar. Y es así de duro, pero es así la carrera informática. O sea, que me sabe mal cuando veo gente joven y tal que quieren ganar, no sé, por ponerte una cifra, no lo sé, quieren de entrada ganar 50.000 o algo así, habiendo hecho, y aquí ya me da igual el título que tengas, habiendo hecho un bootcamp sobre determinado lenguaje, aunque hayas hecho una ingeniería, normalmente con la ingeniería la ventaja que tienes es que tienes unas buenas bases, que has estudiado lógica, has estudiado algo de matemáticas, has estudiado fundamentos de programación, tal. Eso a mí me faltó, lo tuve que completar por otras partes, y eso lo vas a tener. Con la carrera, vale. Pero eso no te capacita como programador. Cuando llegues al mundo del empleo te vas a dar una hostia inmensa. Entonces hay que empezar por otra cosa, hay que ir tirando poco a poco, hay que ir haciendo experiencia, y luego ya sí podrás optar a esos puestos de senior y tal. Entonces, ¿hay pocos o muchos? Yo lo que veo es que hay empresas que están desesperadas por contratar gente senior de Go, vale. Yo me vienen ofertas todas las semanas. De distintas empresas. Por eso también tenemos sueldos relativamente altos, porque hay demanda. Sin embargo, hay gente que me dice, pues a mí no me entra ni una, o yo no consigo trabajo de brand manager. Pero coño, si no tienes experiencia, si no tu GitHub está vacío, no has escrito ningún paper sobre vos, ¿cómo quieres que te vengan las ofertas? Además, en el mundo en el que vivimos hoy, porque antes, en mis tiempos, tú simplemente teniendo contactos podías tener trabajo, vale. Esto era así, o sea, para trabajar de sistemas, si la peña te conocía, de haber sido a conferencias, a charlas y tal, tenías amigos, que habías ido de juerga con administradores de sistemas de otras empresas y todo eso, pues te llamaban por teléfono y podías cambiar de empresa o podías trabajar, que van haciendo unas llamadas y tal. Hoy en día no es así. Hoy en día te tienen que encontrar en LinkedIn, te tienen que hacer una oferta, tienes que hablar con ellos, tienes que demostrar que sabes algo y tal. Y entonces, pues no lo sé. Mi recomendación para alguien que empieza es que no, que entienda que se va a tener que pegar unos años haciendo el mandril en un puesto peor pagado y aprendiendo cómo se cuecen las cosas dentro de una empresa y tal. Y más adelante ya hablaremos de poder ser senior. No lo sé, es complicado, pero sí que veo ese problema. Ese problema en el mundillo de la informática hoy en día y en JavaScript y todo eso está muy competido. Hay muchísima gente que programa en JavaScript y que van a competir contigo a la hora de pedir un puesto y tal, pero Por eso no te importe el poder optar a sueldos más bajos o lo que sea durante un tiempo hasta que puedas coger experiencia. Esa sería mi recomendación. Y lo de Go, pues claro, es que quizá haya que venir ya de otros lenguajes para empezar a buscar algo en Go. Aún realmente estudiar de repente Go sin tener ninguna experiencia y pretender que te contraten. Pero ofertas sí que hay. Lo que pasa que, ya te digo, seguramente esas ofertas no le caen a todo el mundo, le caen a quien ya se ve que tiene una trayectoria en eso. Puede ser. Lo que es fundamental también, y yo lo tenía un poco crudo, un poco menos cocido, es el inglés. El inglés hoy en día es fundamental para trabajar en esto. También es una cosa que quizá nos podemos lamentar y llorar mucho y tal, pero está ahí y no la vamos a poder evitar. Entonces, la gente joven sí tiene esa ventaja que habla un buen inglés en general, que quizá ha estudiado fuera también, que puede tener esa puerta más abierta. Y el que no la tenga, pues casi te diría que antes de estudiar Go, que se coja una buena academia de inglés o un buen profesor particular o lo que sea, y se ponga a estudiar inglés como un cabrón, porque le va a servir más que lo otro.

Lo que me quedaba preguntar era de las recomendaciones que das para aprender Go y Y bueno, ya has comentado un poco el cómo hacer la trayectoria de entrar en una empresa como junior e ir aprendiendo, aprendiendo, aprendiendo hasta posicionarte como senior y entonces ya poder aceptar otras ofertas. Pero esos primeros pasos antes de incluso entrar en la primera empresa como junior, ¿cómo recomendarías empezar y acercarse al lenguaje?

Es que claro, me cambia mucho La percepción, si es que estoy hablando contigo, que sé que eres un tío porque tiene una experiencia similar a la mía de muchísimos años en muchísimos lenguajes y con muchísimas máquinas, es diferente. Porque quizás sí pudieras estudiarte el lenguaje en unos meses y luego optar a un puesto de senior, vale, si tienes ese background. Ahora, si eres un chaval de 20 años o de 20 y pocos años con la carrera o con un grado o con que haya ahora que conozco por completo, no vas a poder. Entonces, ¿cómo empezarías? Pues mira, hay comunidades, luego por ahí hay un Golang hispano, creo. Hay un, nosotros tenemos la suerte también con el español de que hay muchísima comunidad en español por todo el mundo, y puedes empezar por ahí metiéndote, preguntándote a ver qué eventos hacen, qué conferencias. Hay muchísimos vídeos en YouTube, muchísimos, algunos muy buenos. Recuerdo, hay un programador que me gusta seguir, me gusta bastante en YouTube, que se llama Anthony Gigi. Buscadlo porque este tío programa en vivo en Go y da buenos consejos generalmente. Por supuesto, uno no va a estar de acuerdo nunca con todo, pero en general es muy interesante seguirlo y ver qué cosas hace y los consejillos que da y tal. Este es en inglés, pero en español hay un montón también. Sobre todo de países de Hispanoamérica, hay un montón. Y entonces empezar por ver esos vídeos, por ver cómo se hacen los primeros pinitos con tal. Luego hay un libro, hay un libro bastante recomendable, lo tengo por aquí. Mira, esto se llama Learning Go de O'Reilly, An Idiomatic Approach to Real-World Programming. Es interesante, pero En internet hay un montón, pero un montonazo. Entonces, coger algún libro de esos. Hay algún otro que te recomienda qué cosas no hacer en Go, no me acuerdo del título ahora mismo. Hay uno que es 100 cosas, creo que es 100 cosas que no debes hacer en Go, eso es muy interesante también. Sobre todo si venís de otros lenguajes, hay que quitarse mucho el olor a Java. Decirlo así, no quiero ofender a nadie porque Java es un lenguaje que simplemente no he trabajado, pero supongo que sirve y de hecho ha servido durante muchísimos años para muchísimas cosas. Pero Go es otra cosa y hay que quitarse la vestimenta de Java y ponérsela de Go y eso cuesta un poco de tiempo. Aparte de los libros y aparte de los vídeos de YouTube, que no son nada desdeñables, todos son muy buenos, pues de mí mismo hay varios cursos. Hay de estos cursillos tipo de 0 a 100 en un mes o cosas así que son bastante buenos. Yo me haría alguno de esos porque siempre esa primera ayuda en la que te van explicando las cosas en lugar de buscarlas tú proactivamente puede ser buena. Y en los Reeling ya más avanzados, en los Reeling he visto algún curso, no me voy a acordar del título, pero en los Reeling hay algún curso más avanzado que realmente son son bastante buenos. Yo creo que por ahí se podría empezar. Y sobre todo haceros algún proyecto, alguna idea, algún, no lo sé, cualquier cosa. Hazte un crawler que baje páginas de internet. Yo hice unos proyectos cuando estaba aprendiendo para las máquinas retro, para los RPGAs, para poder descargar todos los juegos de una plataforma en FPGA, para convertir cintas del espectro, una TGX, para, no sé, es lo que a mí me gustaba, vale. Pero seguro que hay cosas que le puedan gustar a otra persona que tienen, que pueden hacer algo. Entonces, hacer esos proyectillos, poner vuestro código en público desde el primer día, no preocuparse de nada. Aquí si alguien se ríe, pues lo bloqueas y fiesta, o lo que sea, no. Pero ponerlo desde el primer día, aceptar comentarios, buscar gente que incluso os pueda ayudar, o la otra, que es buscar proyectos que hacen hechos en Go, e irse a la lista de issues y a ver si podéis corregir alguno, podéis ayudar en algo, pues también sería muy buen punto de partida. Y sobre todo, pues eso, no me canso de decirlo a lo largo de los años, software libre. Liberad el software y colaborad en el software libre. Y eso es lo mejor que hay para aprender y que todos tengamos todo en abierto en general. Por supuesto, una aplicación de una empresa y tal pues no la vas a liberar por ahí. Y generalmente además no serviría de nada, pero el código que ya hay libre y tal, pues meteros ahí a mirar, a remirar, a colaborar, a romperlo, a lo que sea, y eso es lo que más os puede hacer progresar. En cuanto a la carrera profesional, es que lo que ya he dicho, pero no hay nada escrito. Hay gente con más suerte, con menos suerte, con más carisma, que se le dan mejor las entrevistas en la campus. A mí lo de la campus Esa se me da bien, pero bueno, aún así hay que hacerlo. Y a veces te hacen preguntas que te dejan descolocado. Puedes descolocar, no pasa nada. A mí me ha pasado también. A mí, conociendo ya bastante a fondo el lenguaje, me han tirado una entrevista y me han hecho preguntas de cosas que no se me había ocurrido mirar y me he quedado totalmente en blanco. Entonces, eso no pasa nada. Tomas nota y para la próxima ya lo sabes. Así que en fin, no sé qué más consejos puedo dar.

Nos queda claro, son los materiales que ya habíamos mencionado, del libro, cursos. Echaremos un vistazo a Anthony también de hacer proyectos de software libre. Yo creo que eso es incluso lo más importante, como decía Richard Stallman, un buen escritor tiene primero que haber leído mucho. Entonces, si nos hacemos con muchos proyectos y vamos leyendo, yo creo que también es un gran consejo. Pues creo que ya hemos dicho todo lo que se tenía que decir de Go. ¿Quieres decir algunas últimas palabras antes de cerrar?

No, pues nada, recomendar Go si alguien va a empezar una nueva aplicación y duda en qué lenguaje la tiene que hacer y tal, que eche un vistazo a Go porque tiene cosas interesantísima. De seguro va a encontrar cosas que le gusten mucho y que es muy buen lenguaje ahora mismo para casi cualquier tipo de aplicación. Si es una aplicación que tiene que correr en background en un servidor y no se tiene que comunicar más que con otras máquinas, es perfecto. Pero si tiene que tirar HTML, también es bueno. Y si es un API REST para un front que estáis haciendo en React o cualquier cosa así, y un Svelte o cualquier un fallo de estos de JavaScript, también es muy buen acompañamiento. De hecho, es perfecto porque ya veo empresas llorando con el frontend React y el backend en Node.js con Express o alguna cosa de estas, y eso no escala. O sea, eso olvídate, eso sirve para el principio de una startup, pero luego no va a escalar, vale. Entonces, si desde el principio queréis hacerlo escalable, pensad en Go. Y seguramente no os vais a equivocar. Para la nube también está muy bien. A mí no me gusta Amazon Web Services, no me gustan las landas. Otro día podemos hablar de eso si queréis, pero no queda más remedio que usarlas hoy en día en muchos casos, vale. Pero entonces Go está perfectamente adaptado para eso también. Así que no sé qué más, no sé qué más decir. Y si no, pues oye, buscad un un experto como Manuel, o como yo si estoy disponible, o como cualquier otro, y hacerle 4 preguntas que seguro encantados os puede resolver alguna duda de partida para ver si es un lenguaje apropiado para lo que queréis hacer.

Ponemos en la descripción los datos de contacto tuyos y todos los enlaces que hemos ido comentando de libros y canales de YouTube y demás. Y poco más. Así que gracias, Jorge, por atender la petición de entrevista interrogatoria.

Gracias a ti por la invitación y un gusto tenerte aquí. Un gusto hablar contigo, Manuel. Un abrazo.

Pues nos vemos ya en la siguiente semana con otra charla. Muchas gracias y hasta pronto.