Julia con Miguel Raz

Buenas tardes, estamos aquí en otro capítulo de Codeadores. Esta vez ya por fin hemos conseguido conectarnos con Miguel Razz, que fue casi quien inspiró la idea de que hablásemos con gente del mundillo y no solo dar información de los lenguajes de programación. Así que mucho gusto de tenerte aquí, Miguel.

Muchas gracias por invitarme.

Aprovechando un poco que voy a dejar que te presentes y te introduzcas, quiero también que respondas respondas la primera pregunta, que sería: ¿cómo te introdujiste tú en el mundo de la programación? ¿Cuáles fueron tus primeros pasos?

Ah, bueno, primero, y antes que nada, muchas gracias por tenerme, por invitarme. Esta colaboración surgió porque, este, si no mal recuerdo, alguien posteó algo sobre Julia en Twitter en español, y entonces creo que soy de los únicos pocos que está ahí siempre posteando Julia en Twitter, o antes Exo, lo que sea, ahora Blue Sky también. Y obviamente me llega a mi radar, y entonces tuve que llegar a decir, oigan, creo que aquí, este, vale la pena aclarar mis orígenes en la computación. Creo que había una computadora con Windows 95 en la casa. Nunca programé nada, pero jugué mucho pinball. En prepa tuve una clase donde creo que programamos en HTML, pero ni siquiera pude hacer una calculadora. Es, fue hasta la universidad que una Navidad me senté con este tutorial que se llama Learn Python the Hard Way. Y entonces este cuate te dice, oye, vamos a anotar todos los comandos 10 veces, es en serio, porque así lo aprendes. Ya sé que es muy estúpido, ya sé que es muy repetitivo, pero así se hace. Entonces escribí ls ls ls pwd pwd cd cd cd cd, y ahí Y recuerdo el momento de ponerle echo hola mundo en la terminal y que saliera, ¿no? O creo que el primer momento mágico que tuve fue cuando puse mv asterisco y se movieron todos los archivos y dije, no lo tengo que hacer todo a mano. Eso fue la primera cosa que automaticé en mi vida, el no tener que mover directorios a mano con ese comando. Pero yo entré a física en la UNAM y habían unos cursos de de computación y a lo más hacíamos un péndulo, un sistemita, y como que no sabías programar más allá de 40 líneas y que este sale una grafiquita bonita. Eso no creo que lo llamaría programación. Y luego tomé unos cursos de MATLAB y Fortran porque para física esos pueden ser muy útiles. Y luego tuve un profesor, antes tuve un profesor que se llama David Sanders, y justo me dijo, oye, hay un, el futuro del lenguaje de programación es para la ciencia, se llama Julia. Y yo le dije no y fui, aprendí Fortran, y después regresé, me enteré que había unas becas para aprender Julia con Google, este, y dije, ah, pues a ver de qué se trata esto. Y entonces me metí al foro. Si tú googleas julialang.org te dice hay comunidad, te metes a un Slack, y entonces ahí está mucha gente que programa en Julia. Entonces No sé, yo no sabía programar bien, no tenía idea qué era un arreglo, qué es una cadena, o sea, nada. Y ahí recuerdo que pregunté algo como, oigan, ¿cómo se hace 2+ 2? ¿Cómo defines una función? Casi, casi algo verdaderamente de principiante. Y recuerdo que me respondió un cuate con un sombrero de vikingo, no, así como, oye, eres nuevo, bienvenido, pásale. Oye, así te da 4, así le defines, o pícale aquí, no. Y así como de, ah, mira qué buena onda, no. Y qué chistoso que hay gente con fotitos de vikingos, no. Bueno, así es el internet. Y después me entero que el creador de Julia Lang se llama Stefan Karpinski y tiene una foto con un sombrero vikingo en su perfil, y que muy felizmente se la pasaba contestando dudas de la gente que entrara al chat, y lo sigue haciendo, no. Digo, bien, ahora ya acaba de nacer su segundo hijo, entonces este tiene un poquito más de otras responsabilidades. Pero el ethos de las comunidades de programación a los que yo me he podido, he tenido la oportunidad de acercarme, han sido increíbles. Porque es de, o sea, al menos Julia y Ross, la gente llega, pregunta, comparten conocimiento, colaboran, te agregan, puedes volver coautor si quieres. O sea, así es, me ha tocado la mejor cara. Claramente hay un legado muy tóxico de las mailing lists de gente que es muy atroz y racista y lo que tú quieras, y misógina. A mí afortunadamente no me tocó eso, y en los círculos que yo, este, me muevo trato de que no sea así para los demás, que tengan una experiencia tan bonita como yo tuve. Y eso me ha llevado a tratar de hacer tutoriales, traducciones, este, cursos a dar en la universidad que sean de libre acceso. Ayer liberé una traducción de 100 ejercicios para aprender Julia, ¿no? Hay un repositorio por ahí que se llama 100 ejercicios para aprender NumPy. NumPy, esta biblioteca de álgebra lineal en Python. Y pues me harté de que no hubiera una versión en español y ahora ya la hay. Y desde que empecé ahí me pegué a las comunidades de open source y he estado desarrollando muchos tutoriales, introducciones y algunas herramientitas que necesito para temas de cómputo científico.

Me ha llamado la atención que dijiste de te ofrecieron Julia y dijiste no, Fortran. Pero Fortran entonces lo utilizaste o llegaste a hacer cosas aunque solo fuese a nivel de carrera con él.

Sí, sí, sí, o sea, sí sigo siendo fluyente en Fortran, como que lo aprendes una vez y no se te va. Desafortunadamente, como que Fortran sufre del legado de no tener un manejador de paquetes por 60 años. Entonces cada vez que ves un proyecto en Fortran es otro monstruo, muy como los infiernos que pueden existir para los desarrollos de C++, cada quien reinventa su config file. Make es un infierno. Ahora hay un esfuerzo por modernizar Fortran y hay un manejador de paquetes de una biblioteca estándar que están haciendo en Fortran. Y sí, muchas de mis quejas contra Fortran no existirían si hubieran buenas prácticas por un manejador de paquetes, un buen linter, un buen language server protocol. O sea, de repente Fortran tiene cosas muy, muy padres. No creo que es ideal para muchas cosas, pero lo que hace bien lo hace muy bien.

Y sobre Julia, porque si al final decidiste volcarte más sobre Julia fue porque algunas de las cosas del lenguaje te llamarían más la atención que cualquier otra opción que tuvieses disponible. ¿Qué fueron esas cosas que destacarías más de Julia?

Probablemente la necesidad por ser interactivo. Entonces muchas veces cuando uno está tratando de hacer un cálculo en donde hay, ¿cómo calculo? Pues sí que es ser muy ñoño, la desviación estándar, o ¿cómo haría? ¿Cómo graficaría esto? En muchos otros lenguajes, digamos C o Fortran, tienes que hacer todo el código, luego cambiar la línea de comandos, compilarlo, a ver si te acuerdas cómo compilarlo, y luego encontrar una biblioteca para que plotee. Entonces como que tú quieres hacer una tarea, tú quieres hacer una tarea, es calcular algo y mostrar una imagen para ver si te salió bien. Y en otros mundos necesitas 4 o 5 herramientas hiladas, ¿no? Necesitas saber el editor de texto, necesitas escribir el código, necesitas saber cómo incluirlo, necesitas saber compilar, llamar el linker, y después necesitas saber— o sea, como que sí son— ninguno de esos pasos en retrospectiva es, digamos, como que un enorme obstáculo, pero cuando uno está comenzando toda esa complejidad auxiliar, por así decir, o no necesaria, te previene de hacer, de lograr hacer proyectos cuando quieres. Y en ese mundo Julia tiene una experiencia fantástica que se llama el REPL, el Read Evaluate Print Loop. Entonces si tú le pones Julia en la terminal, te sale bienvenida Julia, ya puedes hacer 3 3 y corre, ya puedes definir una función y corre. Entonces yo puedo calcular la distancia de Hamming para 2 cadenas, puedo hacer tratar de escribir un método para calcular la ecuación de calor. Puedo intentar hacer una matriz de 7 dimensiones y a ver si me sale una manera de rellenar solo los bordes de unos o ceros. Y entonces mi habilidad para poder de tener una idea a ejecutarla en la compu con Julia es un tema de segundos. Y yo como que soy una persona que a veces se va, se distrae muy fácil. Entonces para mí eso es drogas, ¿no? O sea, cada vez que yo quiero saber algo sobre mi código, qué tan rápido corre, este, si está usando un algoritmo más eficiente, si puedo mejorarlo, si le puedo bajar el número de allocations. Julia me permite todas esas facilidades en menos de una línea de código. Entonces hay una comunidad muy fuerte alrededor de hacer benchmarking de funciones, porque si en estos canales mismos tengo una plática por ahí, pero es ahí todo el tiempo hay gente de todos los institutos y lugares financieros y lo que tú quieras, de gente que dice como, oigan, tengo una función que se está tardando como 80 milisegundos milisegundos. Y para mí es el cuello de botella. ¿Alguien sabe cómo hacer este, esta operación un poquito más rápido? Y entonces dices, aquí este es mi momento, ¿no? Y te pasas ahí unos 20 minutos y es, ah, ya lo bajé a 70 milisegundos. Y llega alguien más de Singapur y dice, ya lo bajé a 50. Y de repente se despierta el cuate de California, ¿no? A las 3 de la mañana porque no duerme, y dice Yo lo tengo en un milisegundo. Y todos, guau. Pero lo padre es que cada quien va compartiendo su código y todos pueden y van compartiendo el cuántos los inputs y cuánto se tarda en un, en el mismo canal de Slack, no, Slack o Discord, la verdad es indistinto para esto. Pero el chiste es que con copiar y pegar un código puedes saber si sí están diciendo la verdad, si sí corre, si dice lo que hace. Y entonces ha llevado a que hay se llaman perf junkies, no. O sea, hay gente que está adicta a estar como que ganándole a esos. O sea, ese es el ethos de mucha gente, de no solo saberlo pero compartirlo, o al menos de volverse así como, ah, es que este cuate es el que sabe manejar cadenas súper eficiente, ¿por qué no vas y le preguntas allá? O, ah, no, este cuate sabe hacer los cruces de los data frames, pregúntale. Ah, no, los de ploteo están aquí. Entonces cada quien tiene su canal y más o menos sabes a quién ir y preguntarle cuando tienes cierto tipo de problema. Y para mí esa parte de la comunidad se me ha hecho increíble, y es algo que cuando voy a otras comunidades no encuentro. Como mi físico interior sí me dice, me pica mucho el cómo sabes lo que estás viendo, y el al menos tener un numerito que me dice que estoy midiendo algo me calienta el corazoncito. Ya después hablamos qué tan mentiroso es eso, créanme, yo soy el primero en no confiar en lo que me dice. Pero al menos hay un mundo de herramientas que permiten, digamos, tener estas ideas, probarlas. Y lo padre es que se acaba creando comunidad alrededor de esa facilidad, lo cual es un efecto dominó no tan fácilmente visto. Nadie te dice hoy estás enseñando un lenguaje de programación, si tú le metes esto vas a atraer a esta gente.

Como se ve casi como un círculo virtuoso en el que se van retroalimentando uno a otro. Bastante inspirados, como tú mismo has dicho. Y cuando estamos aprendiendo un lenguaje de programación, siempre, yo al menos tengo la sensación de, a medida que voy avanzando, me voy encontrando las tripas del dragón. Son esos tipos de tropezones que hacen que sea un poco más difícil avanzar o que te crean una fricción a ciertos problemas específicos que queráis implementar. ¿Qué cosas dirías tú que son así como no tan obvias o que dificultan el acceso a Julia?

Hay varias, ¿no? Como cualquier lenguaje que es nuevo, nuevo relativamente. Julia tiene casi la misma edad que Rust, ¿no? Pero digamos, no hay 30 años de tutoriales en Python hechos en donde la gente pueda más hacer así como que googlear, encontrar la primera, así ir al primer resultado de Stack Overflow, copy paste y funciona. O sea, sí hay eso. Tal vez ahorita tienes que escarbar menos, eso ha ido en decrecimiento. Al parecer hay algunos estudios por ahí que dicen que es más fácil hacer, usar el código de ChatGPT generado para Julia que para otros lenguajes. No sabría, no uso ChatGPT. Entonces, una sí es como que digamos faltan décadas de conocimiento que se difunda. Más en temas técnicos, hay un cierto modelo de cómo opera el lenguaje que si la gente se rehúsa a aprenderlo va a doler. No al nivel de Rust, no, va a doler en términos de performance. Entonces les tienes que explicar a la gente Digo, clásico, no. Julia es famoso porque tiene un compilador JIT basado en tipos, o sea, no es, es compilado pero solo hasta que corres una función la primera vez. Y entonces todo el tiempo salen blogs en donde alguien dice, ah, Julia no es tan rápido, miren, no, yo voy a escribir estas funciones y se tardó, uf, como 100 veces más lento, entonces, ¿para qué lo usamos? Y luego llega alguien y dice, oye, por favor, córrelo una segunda vez, y lo corre y es 1000 veces más rápido, literal. Porque la primera vez estaba compilando, la segunda vez está usando el código de máquina súper optimizado. Y entonces dicen, ah, oh, wow, eso pasa todos los días, ¿no? Y no es único a Julia. Yo he visto blogs de CEOs que llegan a Rust y dicen, ah, no es tan rápido. Y alguien amablemente les tiene que decir, oye, por favor, haz cargo run --release, no, no lo, no tienes el binario optimizado. Entonces ahí dicen, oh, bueno. Disculpen, pero no quitan el blog. Eso es como comentario aparte. No crean que me estoy burlando de la gente que no sabe medir las cosas. Yo tengo una plática donde me burlo en mayoría de mí mismo no sabiendo medir en público. Es difícil. Sí, sí, sí, se llevan una lección de esta plática, por favor, que sea antes de publicar un resultado de rapidez, consulten con alguien que supo un poquito más que ustedes o que le puede decir si está haciendo algo muy tonto para ahorrarse esas penas, porque créanme, no las quieren pasar. Otra dificultad técnica, sabemos que para, hay ciertos gotchas del performance que para gente que no está versado en temas de performance puede ser difícil porque todavía no hay herramientas que lo señalen también. No, obviamente habría cosas que tal vez tu editor de texto te puede decir, oye, aquí estás haciendo un despacho dinámico, eso no está tan bien. Hay muchas más herramientas de linters que se podrían usar. Me acabo de enojar con el linter de Julia hace 2 días porque me di cuenta que solo, este, solo checa por llamar una función pero con la aridad de una función mal. O sea, si tengo h de x definido y trato de llamar h de x y de y, sí dice, ah, eso probablemente está mal. Pero si estaba definido para cadenas y le paso un número, no me dice, oye, aquí claramente esto no va a jalar, ¿no? Y entonces ahí todavía hay un mundo de herramientas que involucran la experiencia de programar alrededor de los errores de mensaje, los linters, las extensiones de lo que tú quieras, que se pueden mejorar. Y ya, ya como que en el corazón de qué se dificulta sería entender lo que se llama despacho múltiple, porque ese es como que así lo que sí es el corazoncito de Julia es el despacho múltiple. Y cuando la gente no entiende, así como, ah, pues esto es otro, nada más es un Python reskin. Es como que tiene una salsa distinta. Ahí sí les tienes que decir, sé que se ve como Python, pero son dos mundos muy distintos.

En otro orden de magnitud, es decir, si tú tuvieses la posibilidad de cambiar el lenguaje o de realizar cambios, ¿qué ves que se podría cambiar en el lenguaje que dijese ahora me gusta más?

Ojalá no me manden a la hoguera, pero yo quisiera que las partes internas de Julia estuvieran escritas en Rust. Eso es, hay un, yo sé que esta plática en su mayoría es de Julia, pero hay que reconocer cuando otras herramientas son mejores para otros dominios. Y el dominio en donde Rust es rey es en sistemas de bajo nivel donde tratas de poner invariantes dentro del sistema de tipos del compilador. Y digamos Julia tiene un garbage collector, tiene un sistema de subtipado, no tiene el algoritmo de subtipado de tipos, el algoritmo de subtipado, el subtyping algoritmo, las tablas de métodos para poder implementar el multiple dispatch, un sistema de parallel runtime. No sé, hay como que 4, 4 o 5 corazones importantes que son muy necesarios para el funcionamiento de Julia, y que si quieres implementar algo en eso o si quieres cambiarle una piecita, no es como jalar un bloquecito de una torre de Jenga con 27 cabezas, no. Una sola, mueves una cosa y tienes que controlar que no se muevan las otras 40. Y para saber cuáles son las otras 40 cosas que se pueden mover, hoy en día la respuesta, la hoy en día la manera en que se hace es que te sientas al lado de un cuate que se llama Jameson Nash, le dices Jameson, oye, por favor, ¿cómo funciona esto? Y te dice, ah, sí, es que aquí tienes que ir a ta ta ta ta ta ta. Y yo creo que eso no es buena idea para el futuro. Yo creo que en la medida de que más invariantes se puedan pasar del cerebrito de Jameson y de otros compiladores, ingenieros en compiladores, hacia un compilador, es mejor porque más gente va a poder contribuir. Se va a levantar, este, se van a bajar, este, las compuertas para que la gente pueda entrar. Va a ser más fácil contribuir, van a poder hacerse más cosas, y algo de eso está pasando. No, no, esta es una conversación que va para décadas. Entonces los desarrolladores de Julia no van a aprender Rust mañana, y probablemente no vale, tal vez no vale la pena que lo aprendan, no sé. Su tiempo es muy preciado y hay como 5 de ellos buenos buenos, entonces todavía está difícil. Pero sí, eso es lo que yo cambiaría. Ojalá más de Julia estuviera en Rust. Yo creo que necesitamos robar más gente de Rust. Hacen muy buenas herramientas.

Pero esto quiere decir que, porque el núcleo del sistema supongo que estará escrito en algún lenguaje como C, ¿no?

En C. Entonces es C, es un C llamando a todos los bindings del compilador LLVM. Creo que lo podrías llamar C++ en teoría, pero es C. Pero es un C, digamos, que ya corre en millones de máquinas, que ya lleva 10 años la base de código desarrollándose, madurando, tomando todo en cuenta, todos los posibles corner cases, con muchísimas optimizaciones, muchísimas optimizaciones. El garbage collector, hay un grupo de investigación que se dedica a sacar papers e implementar nuevos garbage collectors, tienen todo un framework para hacerlo, todo en Rust. Y al menos para el caso de Julia, resulta que los garbage collectors son increíblemente sensibles a las heurísticas dependiendo de tu tipo de problema específico. O sea, no es lo mismo estar, tener un programa que está recibiendo un millón de requests de input/output, no, o mensajes web, y los tiene que procesar, a un programa, o no, no se ve ese perfil de performance para el garbage collector, nada parecido a un programa, digamos, estilo Fortran, donde agarras e inicializas 10 matrices enormes, las haces update en cada ciclo, tal vez las escribes a memoria una vez cada minuto y luego se acaba, no. O sea, uno casi ni le moviste, el garbage collector ni se entera, casi casi, no. Si solo estás calculando numeritos intermedios y tienes una gran matriz, ni pinta. Entonces el mundo de Julia es más parecido hacia el mundo de Fortran, pero no completamente. Y entonces han tenido que hacer décadas de optimizaciones y caché y caching y reglas y heurísticas, y entonces es muy difícil ganarle. Aunque tengas un algoritmo así que vale la pena el paper y que sea óptimo con nuevos respectos, o que demuestra una nueva cota inferior, o sea, aún así les ha costado ganar a las implementaciones de Julia. Y en particular es difícil porque todo el mundo de garbage collectors en su mayoría está financiado por Big Java, por Oracle, entonces casi, y por JavaScript, entonces casi todos los benchmarks son cosas que le interesan a gente de Java y JavaScript. Pues estos benchmarks no son los mismos que le interesan a gente de Julia. Entonces hay toda una industria que se ha vendido de garbage collectors hacia estos casos. Necesitamos jalarlos para otro lado. Eso ha sido difícil.

Sé que cuando se habla de Python en el análisis de datos, la mayoría de librerías para Pandas, NumPy, que la comentabas tú, y otras librerías, hay muchísimas librerías, pero la mayoría están implementadas en C. Y tienen sus bindings hacia Python. Creo que es la única forma que han conseguido de que Python responda medianamente rápido, sin despreciar al lenguaje. Julia, sin embargo, tiene esto también, tiene los bindings hechos en C y hacia arriba ya se programa en Julia, o tiene más hecho en Julia de este tipo de librerías.

La pregunta es, este, ¿Qué tan fácil es llamar Julia desde otros lenguajes o qué tan fácil es llamar a otros lenguajes desde Julia? Porque los dos sentidos de la calle son parecidos, pero digamos tienen implicaciones distintas.

Bueno, eso sería interesante también. Mi pregunta iba más en base a si la potencia de Julia se debe, como en Python, a que se utiliza C para la parte interna.

Excelente pregunta. 99% de todo Julia está escrito en Julia y corre súper bien. Corre, digamos, también como podrías esperar que corre un lenguaje como C o Rust. Entonces, a menos de que le estés pegando a casos donde tiene que correr el garbage collector, básicamente tienes performance de C. Y digamos, estoy diciendo tienes performance de C porque no quiero decir probablemente le puedes ganar a C. Entonces hay capas en donde uno empieza a preocuparse por performance, ¿no? Primero es como, o estás haciendo el algoritmo correcto o no estás haciendo una cosa muy, muy, muy desafortunada. Ayer vi un tweet excelente que decía, si tienes un código y le subes y le ganas un factor de, y incrementas el performance por un factor de 2, algo hiciste que fue listo. Pero si tienes un código y le metiste un factor de 100, dejaste hacer algo muy, muy estúpido, ¿no? Entonces algo similar pasa en el mundo de performance, ¿no? O sea, la razón por la cual Python nunca va a poder correr tan rápido como otros lenguajes compilados es simplemente porque no partió de una base en donde está en una posición para hacer eso. O sea, no está destinado para eso, está corriendo con una máquina virtual, no puedes saber el tipo, el tamaño, los tipos de datos en memoria, ergo está restringido siempre buscar punteros. Eso es una limitante física, o sea, no hay manera de acelerar Python más que tal cosa, salvo que puedas de repente darle un atajito y decir, oye, en este caso pues llama esta subrutina, no, turbo optimizada en C. Y entonces por eso te dicen, no, solo usa mi estructura de datos, solo usa mi join, solo usa mi tipo de pandas DataFrame y hace este tipo de otra cosa. Si haces otra cosa, no, no uses for loops, usa generators, no sé qué otras cosas, no. Y entonces ni siquiera, o sea, no, no es hate mío. La gente muy competente en Python te diría, si quieres tener performance, tienes que salir de Python lo más que puedas, quédate en C el más tiempo que puedas. Y hay un excelente debugger y una una plática de Emery Berger de un debugger justo que hicieron para códigos en GPUs que se llama Scalene. Y justo pueden detectar qué parte de tu, cuánto porcentaje de tu código te la pasas en Python y cuánto en C. En la medida de que uno le gana al otro, entonces se vuelve más rápido tu código. Entonces también hay un tema ahí en donde no es un tema de la implementación, no hay una máquina virtual, no hay un JVM, por así decir, sobre el que está corriendo Julia, está corriendo código compilado, ¿no? Entonces es un híbrido interesante en donde se ve como el lenguaje más interpretado del mundo y sin embargo tienes código compilado. Entonces ahí hay un, y puedes saltar entre los dos, ¿no? Como las cosas se compilan on the fly, como just in time, como se va necesitando, eso cambia el cálculo de cómo ciertas cosas tienen que ser programadas. Y se pone muy interesante porque en ese sentido como que es un campo, no diría nuevo, pero definitivamente no tan transitado. Entonces hablé sobre los garbage collectors para JVM y lo que sea, pero los just-in-time compilers no están optimizados para el caso como Julia. Hay muchos papers del cold start versus hot start para el JIT del V8 de JavaScript y muchas gráficas de performance de eso. Casi no hay ningún, pero todos esos just-in-time compilers, los JITs así llamados, no tienen benchmarks para el caso de JITs estilo Julia, que son con base en tipos. Normalmente lo que hacen estos JITs es que tienes una función con 100 líneas de código, la llaman mucho, y luego hay un burócrata por ahí que dice, oye, ya llamaste esta función como 10,000 veces. Y esta es la parte que más pasas tiempo, ¿por qué no te voy a hacer un favor? Voy a ir a compilar esta parte de la función. Y entonces optimizan esa parte, la más caliente. Entonces obviamente, si no le pegas al criterio para que sí se compile ese cacho, entonces te quedas en el lento y tienes que saber, y hay alguien que está pagando el sistema para contabilizar todo donde pasas tiempo y toda esta cosa. Entonces eso, digamos, ese es un problema conocido en el mundo de los este JIT de JavaScript, los cold starts y los hot starts y todo esto. Pero no hay una, no esa cantidad de tratamiento sistémico en el mundo de Julia, al menos por industria, por academia. Obviamente dentro de la comunidad de Julia entras y la gente te dice, ah, pues obviamente tienes que poner todo en un paquete y tienes que precompilarlo, y así es como, así ya no tienes que pagar ningún, este, el precio de la precompilación. Es lo que llamamos nosotros al— entonces como que parte de lo difícil es que para mí ya se volvió segunda naturaleza, como que todas estas buenas prácticas, y como, ¿cómo que programarías de otra manera? Y luego llega alguien y dice como, espérate, ¿por qué pondrías esto en una función? Es solo un script. Y yo así como, no, ponlo en una función, es bueno para ti, como tus verduras, va a ser más rápido. Y entonces no me creen, y luego ya lo ponen, y es como, oh, wow, sí, sí hace diferencia. Entonces como que los tienes que sentar y decirte como, no, te lo juro, tienes que leer el manual. No es Python, please.

Y entonces, bueno, volviendo a la pregunta que entendiste antes de cuánto, bueno, reenfocándola un poco, sería en qué momentos interoperas con otros lenguajes donde, o sea, en qué partes no llega Julia y entonces dices pues mira, tengo estos otros lenguajes que utilizo para completar en estos casos específicos. ¿Y qué tal es la interoperabilidad en esos casos?

Entonces aquí la conversación está, es en dos partes, ¿no? Porque está, tengo un poco de código en Julia que quiero usar en otro código, entiéndase Python, C++, Rust, bla, bla, bla. O hay un código de Fortran, C, este Python que quiero usar desde Julia. Voy a empezar con la segunda. La historia interoperabilidad de llamar otros lenguajes de Julia es hermosa, en serio es fantástica. Salvo por C++, el cual siempre va a ser una bestia por sí misma, en casi todos los otros casos es muy, muy, muy amable. Muy, muy, muy amable. Te estoy diciendo, yo puedo hacer una función que llama, que llama a un shared object. Entonces, si yo tengo mi código en C, tengo una función que dice calcula pi o algo así, no tiene que entrarle un flotante y sale un flotante. Yo la compilo como un shared object. Se la hago pública para el linker, no sé qué. Pero desde Julia, para yo llamar esa función, lo único que tengo que hacer es, este, hacer @ccall, poner el nombre del shared object, en dónde está el path, la biblioteca, el type signature, y la puedo llamar. O sea, una línea de código si ya está compilado el binario en mi máquina. Entonces eso, yo tengo facilidades para eso desde Python, R, C, o más bien de Julia llamando a Python, R y C, y hasta Java, creo. O sea, sí es increíble. Y no, no para ahí. De hecho, hay todo un ecosistema, porque en el mundo de cómputo científico todo el tiempo hay alguien que dice, ah, ¿qué crees? Implementé el mejor algoritmo para calcular esto en gráficas, o esta cosa que puede ser un cruce de bases de datos, o necesitamos poder hablar con el rasterizer para poder hacer análisis de datos geográficos. Cada quien tiene su código implementado en algún lenguaje, o sea, C, C++, Fortran, R, lo que sea. Y obviamente, si tú eres alguien preocupado por ser un, o sea, a mí no me importa que la gente sepa programar en Julia. Lo que verdaderamente importa es que puedan resolver problemas reales, no, o sea, que puedan decir, oye, esto fue la cantidad de agua que cayó aquí, modelamos, así va a estar la costa en unos años, este es probablemente donde deberías o no construir un edificio, no, esto es lo que puede tener la próxima vacuna de COVID. La vacuna de COVID anterior, al menos la de BioNTech, la diseñaron con Julia en parte. O sea, la diseñaron en una semana usando códigos en Julia. Increíble. Entonces el chiste no es que la gente como que se vuelve experta en Julia, es que pueden resolver sus propios problemas. Y para eso, si tú necesitas instalar bibliotecas de todos estos otros lenguajes y tú estás desarrollando ese código, se vuelve muy tedioso. Larga historia contada de manera muy breve, pero existe una manera en que tú solamente puedas hacer using biblioteca gráfica de otro lenguaje, y el manejador de paquetes baja una versión versionada, te la importa, te la pone donde tiene que estar, y tú puedes ya hacer tu wrapper sin ningún problema. Tú y todos los usuarios, independientes del sistema operativo que tengan. Hay toda una infraestructura increíble para facilitar que solamente tengan que descargar un tarball de manera automágica en el background y se expandan donde se tengan que expandir. Y entonces, en términos de usar código con dependencias de terceros, al menos desde Julia, él es el, como que la forma de la solución estructural que eso toma está resuelta. Lo cual no es algo que se puede decir para cualquier lenguaje, ¿no? O sea, existe un sistema que te puede ayudar a resolver ese problema. Que los wrappers de Haskell no sean tan bonitos, o que Rust de repente se rompa porque Blah, blah, blah, es otra cosa, pero en teoría se puede y eso es increíble. Del otro lado, el llamar y el tú tener tu código de Julia que lo llama alguien más. Aquí lo interesante es que, o sea, es tan fácil como llamar Python, ¿no? Entonces es chistoso porque mucha gente como que escucha de algo que es nuevo y parecido a Python, pero si no es exactamente lo que quieren, o sea, de repente empiezan a exigir como, oye, pero se puede hacer esto. Es como, sí, tan fácil como Python. Es como, no, porque era algo más. Es como, ok, es que si no tiene eso nunca lo voy a usar. Es como, la gente igual llama Python así. No, no, ese no es un argumento en contra, pero bueno, no es mi empresa supongo. Pero sí, sí existe manera. Hay una C API, puedes tener toda una manera de llamar estos, este, de recuperar estos objetos con Zero copy si es posible. Hay que tener mucho cuidado con, porque obviamente si tienes un objeto en Julia y se lo pasas a C++, por así decir, entonces tienes que hacer que el garbage collector de Julia no lo trate de, este, desalojar, ¿no? Entonces ahí hay toda una serie de bailes con muchos pasos muy sutiles que son dependientes de cada lenguaje desde donde lo llamas. Y pues hay que ser muy experto en los movimientos internos de ambos lenguajes para eso. Pero, y coincido en que ese es un área en donde no es tan fácil todavía, no en el sentido teórico, pero más bien en las facilidades para desarrolladores, como de oye, quiero picar un botón y que todo esto ya funcione, tú encarga toda esta talacha. Podría haber más talacha automatizada, y al punto en donde podría decir como wow, esto fue divertidísimo. Creo que la gente sale más con experiencia de un dentista que de haber visto un museo de arte. Entonces tal vez hay que empujarlo hacia la experiencia museo de arte.

Y sobre utilizar Julia, porque hay otros lenguajes que la gente pues entra a trabajar en una empresa y ya están utilizando, pues no sé, Ruby, Java, otros lenguajes, Mojo tal vez si son muy hipsters. Pero, ¿ha encontrado empresas que ya estuviesen trabajando con Julia y que nada más entrar estuviesen utilizando ya en sus computadoras, en sus cálculos, Julia.

Sí, sí, sí. Entonces, Julia definitivamente nació del mundo académico, pero no se quedó ahí, no. Digo, igual que Fortran empezó para construir bombas, no, y ya se usó para muchas otras cosas. Fortran está en nuestros celulares para poder decodificar las señales de WiFi, haciendo transformadas de Fourier y otras cosas. Pero oye, por ejemplo, entonces mencioné el efecto, el caso de que creo que fue Pfizer o BioNTech, pero una de las primeras vacunas de COVID se diseñaron con Julia. O sea, los investigadores de la farmacéutica usaron, este, simulaciones de dinámica molecular y encontraron justo el componente activo que era el bueno. El nuevo códec de video de WhatsApp fue diseñado en Julia, ¿no? Entonces, oye, WhatsApp tiene no sé cuántos miles de millones de usuarios, tiene que ser algo en serio. Y sí, lo implementaron y ahí está, está Corel feliz. Hay muchas otras compañías que se dedican a usar Julia todo el tiempo, todos los días. Lo que pasa es que no tiene tan buen marketing, eso sí. No hay una necesidad de muchas compañías, así como, ah, sí, estamos usando Julia, es la neta del planeta. Como que en el caso de Rust había toda una serie de gente de C, C++ con barbudos de hace 50 años y diciendo como no, ellos nunca van a poder. Y entonces cada vez que escribían estos cuates no van a poder y hacían algo, entonces les daban marketing gratis, no. Entonces ahorita el Rust Evangelism Strike Force es inevitable, muchas cosas se van a oxidar. El caso de Julia no ha tenido un ascenso tan meteórico y no está tan mal. O sea, sí, sí hay que, a veces la gente como que A mí se me olvida hasta que amablemente me lo anotaron amigos de lenguajes de programación. Muchas veces no es solamente la, este, el mérito técnico lo que hace que una tecnología es la que gane, no. Betamax y VHS y todo eso, o sea, a grandes rasgos, las razones por las cuales se usa C++ en una enorme parte de la industria es porque por muchas décadas IBM impuso que se iba a hacer el lenguaje para construir infraestructura. Entonces sí, como de que tenían mucho dinero y eran un turbomonopolio, y pues todos los demás vamos a seguir usándose, nos guste o no. Entonces en ese sentido ha habido mucho acercamiento de empresas muy grandes de infraestructura de nube, no, Cloudflare, Amazon, Microsoft, este, Google. Para incorporar Rust en todo tipo de herramientas backend, infraestructura crítica. En el caso de Julia, no, y han metido el dinero correspondiente. En el caso de Julia, no ha habido una enorme gran empresa que ha querido llegar y apadrinar todo el proyecto con unos milloncitos de dólares por ahí o para acá. Han tenido contratos, la gente de Julia ha hecho consultoría para esas compañías, y de eso estoy seguro, para también para el gobierno gringo, pero no es lo mismo tener cientas de millones de Amazon para que crezca tu cachorrito, que no. Y no sé si eso es bueno o malo, la verdad. Todavía veremos. De repente, alguien que sepa mejor la historia de Oracle y Java nos podrá decir.

Hay muchas empresas que dicen eso, que muchos proyectos grandes han muerto porque se impulsaron demasiado, dice obligaron a gente que no lo necesitaba a usarlo y entonces pues terminaron odiándose. En el caso de Ada, creo que el lenguaje Ada es uno de ellos.

Sí, Ada conozco algo de la historia. Había una gran compañía que básicamente monopolizó el mercado. Entonces Ada se convirtió en el estándar de facto del gobierno militar estadounidense para todos sus proyectos porque tienes una manera de comprobar que que no vas a tener errores durante runtime. No, esa es una propiedad muy fuerte para cierto tipo de errores, para cierto tipo de códigos, y prohibiendo muchas prácticas del lenguaje. Pero hay una gran compañía que se llama AdaCore. AdaCore era la más grande, no tiene ahorita toda la gente que escribe los estándares de Ada desde hace muchos años, y que son muy, este, son los meros meros, pero tú no puedes ver su código. Entonces de repente era juegas con sus juguetes o sufres. Y yo sé que la gente en el mundo de Ada voltea a ver el éxito de Rust y dice, nosotros tenemos memory safety, nosotros tenemos este básicamente el sistema del borrow checker, nosotros tenemos, nosotros tenemos más cosas, oigan, y los tenemos de hace 30 años, ¿por qué nadie nos hace caso? Y es como, ah, pues resulta que no les importó tener un buen manejador de paquetes, no importante en una comunidad abierta y que permitía participar a los demás. O sea, no es que no les importara, es que iba directamente en contra de sus intereses financieros. Entonces, de repente, por ahí hay gente de ADA que está maldiciendo a los cielos porque, porque perdieron, porque están perdiendo muchísimo terreno contra Rust. Y pues no sé, yo, yo, o más bien, tal vez sí sé, y creo que la respuesta es Si construyes un monopolio, que no te sorprenda. Digo, el auge ahorita de los Jupyter Notebooks creo que se debe a la red, en cierta medida, que la gente no quiere seguir pagando por matemática, no están dispuestos a absorber las ideas de matemática, no. El estilo del notebook es muy amable, pero pagarle al señor Stephen Wolfram no sé cuántos miles de dólares al año cada vez, cada vez, ya no está tan bonito.

Pues Julia sí tiene su formato en notebook, no.

Sí, entonces súper, para la gente que sigue con nosotros, este es el mejor, la mejor trivia. Pero Jupyter, los Jupyter notebooks significan Julia, Python y R. Jupyter, todos los días alguien aprende algo. Este, de hecho, ¿cómo se llama? Carlos o Fernando, uno de los originales, este, desarrolladores de Jupyter, justo invitó a los cuates de Julia cuando estaban arrancando y en 2 semanas sacaron el kernel, jaló y perfecto. Desde entonces se usan clases por todo el mundo. Ahí hay otro sistema de notebooks que a mí me encanta que se llama Pluto, porque yo sí creo que los Jupyter Notebooks tienen una falla de diseño fundamental, y es que permiten el estado global mutable. Digamos, una hoja de Excel, por ejemplo, cuando tú mueves un numerito se recalcula todo. Entonces tú no puedes tener que habías definido una función y luego vas y reescribes un código, pero está llamando a la f vieja, no. Entonces tienes que darle, no, esta es la f nueva, y recompilar todo. Y entonces, ah, tenía estado global mutable, no, no quiero tener ese tipo de cosas en la cabeza. Y entonces hay un sistema en notebooks que se llama Pluto.jl, no, planetita un poquito más allá de Júpiter, y que tiene, tiene este sistema para recalcular on the fly las cosas que no son demasiado pesadas. Con todo un ambiente muy pedagógicamente amable para que la gente empiece a programar en Julia. Entonces, este, a mí se me hace fantástico. En la medida en que me puedes dar en vez de Jupyter, lo prefiero. Creo que la gente, hay unos estudios apabullantes sobre cómo 2/3 de todos los Jupyter Notebooks no se pueden reproducir. Entonces es como, hay, hay una desafortunada camada o generación de data scientists que no sabe hacer reproducible su código, o más bien las herramientas que ellos tienen para hacer reproducible su código claramente no funcionan lo suficiente, ¿no? Entonces, más allá de culpar a los individuos, las herramientas que tienen son inadecuadas, ¿no? Porque todos están, más de la mitad de los notebooks están fallando a este respecto. Entonces, ¿a qué se debe? Me acaba de salir una compañía que se llama Marimo o algo así, y tiene este estilo de notebooks para Python, ¿no? En donde de manera reactiva todos los resultados se recalculan. Y tal vez si consiguen sus milloncitos de dólares de algún venture capitalist, no sé. Pero me alegra ver al menos de que el diseño de estado global mutable para Jupyter Notebooks no se va a quedar por siempre. O que tengan, o tal vez los inspire para que tengan el botón de modo estricto y que se recalcule todo. Eso sería muy amable.

Si alguien te llegase a día de hoy y te dijese oye, soy nuevo en Julia y quiero aprender para implementarlo en mi empresa, ¿por dónde tendría que tirar para empezar y llegar a un nivel profesional?

Profesional, pues depende mucho qué necesita la empresa. Digamos, en términos de recursos educativos, en la página de Julia, julia-davenport.org/learn, hay n cantidad de tutoriales en YouTube, está el manual. Yo creo que vale la pena leer el manual de Julia al menos una vez, este, de portada a portada, porque hay muchos detalles que se aprenden, hay muchos temas que se explican. De hecho, yo también debería releerlo, supongo. Ya hace un rato no lo he leído. Y va cambiando. Y la verdad, ya hay libros que enseñan DataFrames por el creador de DataFrames. Ya hay, todavía no hay libros sobre ecuaciones diferenciales, y hay libros sobre visualización de datos. Sería empezar a usar ejemplos. Y luego la parte en donde convertir, digamos, programar scripts allá, paquetes reusables, ese es donde está, digamos, el colmillito. El cómo hacer tu código reproducible es la parte más importante, yo creo, porque algo que aprendes en la carrera es cómo resolver tu problemita, pero pasar a cómo resolver un problema que los demás tienen y cómo empezar a hablar con sistemas de documentación, tener testing, buenas prácticas, formatters, todo. O sea, ya ese nivel de complejidad ya es, ya estoy compartiendo con los demás, ya estoy en comunidad, y esa es la bestia grande. Entonces, en ese sentido, pues yo les diría que se unan al chat y pregunten por dónde pueden empezar y cuáles son sus problemas específicos. Porque obviamente, si alguien que está procesando tablas y tablas y tablas de datos No es lo mismo que alguien que está haciendo modelos matemáticos muy sofisticados. Digamos, punto. Si alguien como Uber quiere empezar a trazar rutas, van a querer bibliotecas de gráficos y estar haciendo todo tipo de cálculos. Si alguien está procesando nóminas, va a ser un tema muy distinto, ¿no? Probablemente. Entonces hay que saber hablar, saber preguntar.

Y en tu experiencia, O sea, porque como has visto gente que ha ido empezando en diferentes, con diferentes backgrounds, ¿qué crees que es más difícil? ¿Alguien que empieza desde cero sin saber programar o alguien que viene de otro lenguaje de programación y tiene que desaprender?

Creo que el segundo, cuando ya llegas a la parte de compartir código. Porque al primero le puedes decir así se hacen las cosas porque vale la pena, y te dice ok. Y el otro te dice como no, es que yo quiero tener solo mis imports hasta abajo porque tal cosa. Y le tienes que decir no, estás loco, así no se hace, no, por favor, no hagas eso. Como que quitarles el cuchillo contra ellos mismos. Digamos, a esa etapa, así cuando están empezando desde cero, la persona que sepa de otras cosas Este le va a poder sacar mucho. Yo creo que le saca más provecho a Julia como principiante. Julia tiene una gran virtud, que es que Lenor, como todo el código de Julia, como casi todo el código de Julia está hecho en Julia, tú siempre puedes ver el código en la biblioteca estándar y entender qué está pasando. En teoría no, pero cuando tú necesitas una paquetería, tú puedes ir y ver el código, ver qué está pasando, no. O sea, no hay un wrapper, o sea, como Hay una distinción muy desafortunada que sucede en otros lenguajes que son interpretados, que están los que saben correr el lenguaje y los que saben implementarlo. O sea, si alguien que sabe implementar, alguien que sabe el código del C Python runtime, no sé qué, ese cuate lleva 30 años en C, tiene una configuración de Emacs que solo ellos entienden, y esa persona vale oro, ¿no? Y como Julia le apostó a ser un lenguaje en el que se vale tener un prototipo que se va a ir después a producción y no prototipar en Python y luego reimplementar en C++ para producción. Esas dos culturas se ha desborrado, esa más bien se ha borrado la línea que divide esas dos comunidades. Entonces empieza a haber pues gente que son los expertos de dominio, no, punto, tus data scientists o el cuate que sí sabe química o la persona que sí sabe de derechos humanos, que es capaz de hacer las estadísticas, y luego el cuate que está hablando de Docker y automation. Si los dos hablan Julia, de repente se pueden ayudar y comunicar y resolver problemas entre ellos. Hay algo, entonces ese factor, yo conozco gente en Julia que son biólogos, economistas, o digamos hasta plomeros, ¿no? Y no hay, aparte de obviamente mucho tiempo y esfuerzo y las estructuras que lo faciliten, como que tanta necesidad de, o más bien, no hay más barreras de las que se deberían tener para que la gente se meta a temas que son mucho más difíciles de lo que normalmente pasa. Por difícil me refiero a cosas más profundas en el stack. O sea, si sacas una fichita de Jenga, ¿cuántas cosas, cuántas otras cosas se mueven? Entre más abajo, entre más profundo, ese número crece. Entonces Julia informalmente lo conocemos como una droga de entrada para ser un ingeniero de compiladores. Yo empecé no sabiendo programar a mitad de la carrera. Ahora estoy aprendiendo cómo hacer cosas en ensamblador y LLVM porque para mí era trivial ver el output de ensamblador de mi código en Julia. Entonces no soy el primero y no seré el último. Resulta que sí tienen las herramientas para que las cosas no sean tan difíciles. Entonces mi analogía para esto es que yo siento que en Julia, él, y es como si estuvieras en un coche con el motor transparente. Yo no sé de mecánica automotriz, pero si abro el cofre voy a poder ver y decir como, ah, mira, aquí el aceite y ahí hay un pistón y no sé qué, esto entra y esto sale. Dios, si no funciona el coche, tal vez si se está trabando, está chorreando, no. Y dices, no sé mucho, pero creo que eso por ahí va y vas e intentas. Y en cambio, yo sé que con otros lenguajes, digo, al menos el caso que conozco es el de Python, me imagino que el de R es muy similar, y el de MATLAB ni se diga. Que tú pases de una capa a otra en el nivel de profundidad es dificilísimo. O sea, no, no hay una cultura de hacer eso, no hay una necesidad. O sea, porque hay un límite muy duro de, ah, es que aquí se vuelve C, y Ya cuando pasas, Dios te ampare. Entonces ese tipo de excursiones a la profundidad, si son, si cuestan muy poco esfuerzo y si son transparentes y son accesibles, de repente es, o sea, esa persona que lo hizo en vez de en 70 milisegundos, en un milisegundo, dice, es que mira, si te fijas en esto, aquí te está enseñando que se está llamando las instrucciones vectorizadas del ensamblador. Entonces yo sí estoy jalando ese método, ¿por qué el tuyo no lo está jalando? Así, sí, ya vi, por tal cosa u otra. Te dicen, ah, no, hoy resulta eso está mal, deberías hacer un issue, no, o sea, ve y mételo. Entonces ahí así lo picas, no. Me ha pasado varias veces, así como, oigan, esa función está jalando como debería. Me dicen, sí, ya sabemos, o gracias.

Y, ¿cómo ves tú la salida laboral de alguien que dice voy a dedicarme a Julia y quiero buscar trabajo solo de Julia?

Yo la veo interesante, definitivamente hay Trabajo para gente en Julia. Hay más trabajos involucrados en temas donde hay un corte tecnológico más especializado. O sea, me refiero a, yo sí, entonces mi experiencia de programación es muy rara. 90% de la gente que conozco que dice que hace cosas de programación, de cosas de páginas web o de Docker, o sea, algo mueven en frontend. Yo no he tocado frontend. Yo tengo un blog y apenas sirve. O sea, yo agarré el template de alguien más. Tengo mucho respeto para frontend, yo no lo sé hacer. Qué bueno que alguien más se encargue. Entonces, el tipo de compañías que tienden a venir a Julia lo usan porque le ven un beneficio. La cantidad de performance que consiguen les permite hacer algo más interesante. Entonces, les permite correr un modelo de machine learning más aplicado, les permite tener métodos estadísticos que los demás no pueden usar, les permite usar algoritmos de teoría de gráficas que los demás no podrían implementar, les permite comprobar ciertas invariantes sobre sus datos, les permite usar GPUs en ciertos problemas que los demás no podrían, este, implementar. Entonces hay algo que está comprando, no, o sea, el poder tener ese mayor edge computacional tecnológico. Y ese es el tipo de compañías que es que han gravitado a Julia antes, no. Entonces no es como si alguien dice, ah, pues tengo una compañía de, este, anuncios de JavaScript, y entonces corremos esta métrica, te sacamos tus KPIs y listo, y tratamos de dar un buen servicio al cliente. ¿Importa si eso está en Julia o JavaScript? No sé, no, o sea, hay muchos códigos. Hay para tanto este ruido que hay por cosas de big data, le preguntas a una compañía cuántos datos tienen, te dice como, ah, sí, 500 megabytes en el histórico. Y si dices, eso cabe en RAM y fácil, por hacer un chiste, pero hay Hay muchos problemas que no requieren de, este, digamos, la nube. Pero para eso, si me dijeras, hay, yo creo que hay una expectativa de que vas a estar más en trabajos que tienen que ver con estar desarrollando tecnología de filo de alguna manera. Y eso también implica que hay más puestos que involucran bachillerato, maestría, doctorado. No todos, no, obviamente. Pero si alguien dice como, oye, tengo, me interesó saber sobre polinomios simbólicos, entonces te preguntan, ok, ¿qué sabes? Si tienes el código, tal vez sí, sí va. Si no, ese es otro tema. Afortunadamente creo que se comparte un poco, al menos en los ámbitos no académicos, el espíritu de si lo sabes, lo sabes, y no me importa el papelito. Dicho eso, yo todos los cursos que empiezo con Julia sí los empiezo con el disclaimer de probablemente vale más la pena laboralmente aprender Python hoy en día, porque no, porque Python se comió el mundo. Dicho eso, lo que el 99% de la gente que conozco que aprende Python aprende el Python al mismo nivel que sus compañeritos, no. Yo les voy, o sea, en los cursos que yo he dado trato de enseñarle a la gente yo te estoy enseñando una herramienta que te permite ser mínimo 100 veces más rápido que Python fácilmente, ¿no? Eso a ti te permite llegar con un futuro empleador, proyecto, consultoría, y decir: tu competencia ofrece esto, yo ofrezco algo que es 50 veces mejor porque bla, bla, bla, y esto va a permitir tener otra cosa. Entonces yo sí entendí desde hace mucho tiempo que mi manera de diferenciarme con los demás era poder llegar y presentar un código que era cumplía muchas más expectativas. Y para eso necesitaba yo o ser mucho más listo o tener una herramienta que es mucho mejor. Yo no, yo me he vuelto más tonto con el tiempo, nada más ahora me doy más cuenta. Y pero sí escogí la buena herramienta para muchos temas, ¿no? Entonces ahí yo creo que a veces el, o veo el impulso, veo cuando la gente pregunta, oye, ¿qué tipo de trabajos hay? Y no saben programar. Y si digo, mira, claramente yo sé que mi historia es muy afortunada en muchos aspectos, no sé qué tanto se puede aplicar, pero sí veo a mucha gente que se está haciendo licenciatura, maestría, y no la armaron en academia, y sé que en industria, y lo primero que hacen es encontrar un tutorial de machine learning en Python. Si tú solo ofreces poder haber completado ese tutorial y un proyectito, vas a tener mucha competencia. Entonces ahí, en ese sentido, yo creo que Julia puede ser un diferenciador. O sea, puedes decir las cosas que nosotros hacen, yo lo puedo hacer más rápido. Pero digamos como que yo, yo en ese sentido soy muy aventurero. Yo entré a Julia como en constante 0.4 y está en 1.11. Entonces hay gente que no tiene mi perfil de riesgo, ¿no? Yo creo que ya bajó bastante más, está mucho más establecido. No hay, no hay un tema de que vaya a desaparecer en 1, 2 o 5 años, pero digamos Python definitivamente no va a desaparecer, y C menos, y Fortran tampoco. Entonces se va abriendo el campo laboral y cada vez más gente como que al menos ha escuchado, y que Julia también para muchas cosas de análisis de datos dicen Python, R o Julia. Lo que te, lo que jala en un Jupyter Notebook va, igual lo ponemos en un Docker y lo corremos, nos vale. Entonces Como que hay una pesimización de todos los workflows hacia no importa.

Lo que sí veo viendo con el tiempo es que, por ejemplo, Fortran, COBOL, hay lenguajes como estos que terminan encontrando un nicho y aunque desaparecen de otros sitios siguen siendo los reyes de ese nicho específico. Julia, ¿podrías decir que para gente que tiene gran control de su dominio, o sea, del dominio específico en el que se dedican, como por ejemplo puede ser la física, la química, la biología.

Yo creo que si hay un lugar en donde sigue sobreviviendo Julia en 50 años va a ser por su suite de ecuaciones diferenciales, de resolución de ecuaciones diferenciales. O sea, hoy en día, salvo por ecuaciones diferenciales parciales, las cuales son un multiverso más, pero digamos en el universo de ecuaciones diferenciales, Julia no tiene rival. Y es de, tú agarras una tablita con todas las características que tienen todos los solvers, no, cuando tú tienes un paquete, una biblioteca que puede resolver una ecuación diferencial, le voy a llamar un solver. Y entonces tú puedes ir, ah, pues, ¿a qué orden? Si tiene adaptabilidad, si tiene tolerancia, si no es que, si tiene callbacks, si se puede este, si hay error de análisis global, si tiene garantía de estabilidad, si bla bla bla bla bla. Entonces tú puedes hacer una tablita con todos los solvers posibles y qué calidades tienen, ¿no? Y vas llenando la tablita de qué tan bien soportan o no ese feature. Y Julia simplemente le gana a todos los demás por muchísimo, y es gratis y open source y abierto y funciona hoy en día. En cambio, hay muchos otros solvers que solamente cumplen 4 o 5 características y el resto no pueden ni soñar con eso. Entonces el multiverso de ecuaciones diferenciales es donde yo creo que está el verdadero valor. Y aquí viene algo en donde es chistoso, porque qué bueno, no, 99% de la audiencia tal vez no le importan las ecuaciones diferenciales, pero lo que sí digamos como que vale la pena es llevarse el qué bueno que existe esa suite, no, pero a mí qué me da. Más bien es el sistema que permite que exista esa suite, es el mismo que te permite scrapear datos, no, procesar las cadenas de manera bien, que se respeten todo el Unicode, pasarlo a data frames, hacer una limpia, y luego jalar la biblioteca de estadística, jalar la biblioteca de graphs para ver si hay clústeres que se conectan, usar álgebra lineal para ver si con matrices sparse puedes ver cierto tipo de conexiones, le puedes correr el algoritmo de PageRank encima de eso, y luego puedes llamarlo a plotear, y todo esto en tiempo real para millones de datos. Y si lo quieres paralizar, eso se puede. Entonces ya no se vuelve un tema en donde, digamos, Julia es el mejor en una sola cosa. Yo creo que en lo que Julia sí es el mejor lenguaje de programación ahorita es en permitirte componer el código de los demás, ¿no? O sea, mi código funcionando con tu código, con el de alguien más, con el de alguien más, o sea Encimar todos los códigos posibles en Julia es muy, muy, muy fácil. Entonces, esa es una capacidad exponencial. Tu capacidad del código va creciendo en función de qué tanto código puedes ir agarrando de los demás. Técnicamente no es exponencial, pero sí es combinatoria. Entonces, mi capacidad para— o sea, nunca se vuelve a resolver un problema por sí solito. O sea, tal vez si si necesitas el algoritmo de grafos, pero después lo necesitas explotar, después lo necesitas correr con estadísticas, después lo necesitas, no sé, mandar a un servidor web. Todos esos otros pasos, llamar esas herramientas que te permitan analizarlo, con Julia es trivial. Entonces no recuerdo cómo lo fraseó, se llama Bojumil Karaminski, es polaco, es el autor de DataFrames, pero sí es como, sí, qué bueno, o sea, perfecto. No tienes que ser el rey del performance, pero Pero lo que sí está increíble es que puedes correr un modelo macroeconómico, analizar los data frames, correr las estadísticas, plotearlo, hacer grafos, después meterle un sistema de machine learning si quieres. Pero todas estas partes del pipeline, lo que existía antes era esta parte estaba en Ruby, esta parte estaba en Python, esta parte estaba en C, esta parte estaba en no sé qué, y ahora todo puede estar en Julia y con un solo código. Entonces, antes se llamaba una máquina de Rube Goldberg, que sale el yoyo, le pega al dominó, luego se cae la botella, rueda una bola de boliche. Se van todas estas cosas de 70 distintos lenguajes de programación donde todos estos temas están atados por nada más la creencia en el Señor y 3 y 70 scripts en Bash, ¿no? Este, y tener un lenguaje de programación donde constantemente yo estoy preguntándome, oye, oye, ¿y esto funcionará? Entonces voy, lo intento y funciona. Entonces eso se llama el factor sonrisa, creo. Smile factor. Cada vez que se te ocurre, oye, funciona esto, y sí funciona, ahí quédate. Ahí hicieron las cosas bien, ahí lo pensaron muy bien. Entonces a mí me pasa cada rato que estoy programando en Julia, se me ocurre una idea tonta, lo intento y funciona, y digo, ah, esto está hecho con amor.

Bueno, pues ya llevamos más de una hora. Yo creo que hemos hablado suficiente y bastante bien sobre Julia. Yo creo que Muchas de las cosas y muchas de las dudas que tenía ya me las has resuelto. Ya tengo claro cómo ubicar Julia y para qué sirve, y sobre todo las ventajas que ofrece, y más sobre cómo adentrarme en Julia si lo necesitara a través del tutorial, como has dicho, que está en la página web. Le echaré un vistazo y lo leeré, ya te voy comentando. Si quieres decir algo más para terminar.

Tal vez no platiqué sobre la idea de despacho múltiple y por qué es tan fundamental. Tal vez puedo hablar 2 minutos de eso porque creo que todos conocemos una idea de eso. Despacho múltiple no es una idea, es una manera muy, muy, muy fancy de decir la misma idea se puede aplicar a objetos distintos sin preocuparte por a quién le pertenece. Entonces, si yo te digo, oye, vamos a sumar 2 y 3, tú sabes que 5. Si vamos a sumar 2.5 y 3.5, tú sabes que es 6. Si vamos a sumar 1 entre 10 y 2 entre 10, tú sabes que eso es 3 décimos. Si yo te digo, a ver, suma esta matriz con esta matriz, tú sabes que es entrada-entrada. Si yo te digo suma 2 puntos en 2 dimensiones, suma 2 puntos que están en un plano, tú sabes hacerlo entrada-entrada. Entonces, para todos estos casos yo tenía distintos objetos matemáticos. No, yo tenía números enteros, racionales, punto flotante, matrices, no, tales matrices complejas, puntos en 2 dimensiones. Para todos esos, el concepto de sumarlos se extiende en el mundo. Entonces, digamos, ¿qué pasa en otros mundos? En los mundos de Python y de C++, tiene lo que se llama single dispatch. Entonces tú tienes que decir que a una cierta clase le pertenece el operador add no, el underscore underscore add, no. Y entonces sobre ese tú dices a, cuando tú dices a.sum b, sum le pertenece a, o a.add b, add le pertenece a a. Y entonces aquí yo sí te puedo decir que cuando este es un entero sí se puede hacer este método. Y el problema pasa cuando cambias el tipo de b, no. Si tenías el tipo de a, el tipo de b no puede cambiar, tiene que ser un uno solo. Entonces tener los distintos comportamientos para el a dependiendo del tipo de a sí se puede. Ese se llama single dispatch. Entonces si a era una cadena, un número flotante, un número entero, una matriz, tú puedes tener el a.sum y que funcione. Eso puede funcionar. Pero se pone, donde se pone complicado es el a.sum y el, y el b es de un tipo distinto. O sea, ¿cómo mantienes esos distintos comportamientos, ese polimorfismo, cuando los dos tipos de datos pueden variar? Entonces, esa idea de poder tratar de pensar en no me quiero preocupar a quién le pertenece el más, el más es solo el más, el concepto de sumar es solo suma y ya. Pero el concepto de la implementación con base en la combinación de los tipos de datos, eso sí, déjame ser tan libre como quiera. Entonces, en Julia tú puedes tener n distintos datos, todos con combinaciones de tipos distintos, y de todas maneras especificar el comportamiento que quieres. Si yo sumo A, B y C y todos son enteros, haz esto. Si yo sumo A, B y C y todos son matrices, haz esto. Si yo sumo A y B y esos dos son flotantes y el tercero es una cadena, haz esto. O sea, en teoría no hay límite de cuántas combinaciones tú puedes implementar. A este sistema se le llama despacho múltiple y existía en los 80s en Lisp y era muy tedioso y era muy tardado y por eso a la gente no le gustaba. Digamos como que la gran virtud de Julia fue encontrar una manera optimizada de implementar esto por medio del compilador de LLVM, por medio del JIT y por medio del algoritmo de subtyping para encontrar cuál de todos estos tipos es el que vale la pena, y luego dar esa experiencia al usuario. O sea, eran ideitas que están por ahí desperdigadas y no es un concepto ajeno a nosotros, nada más que se encargaron solamente de hacerlo bien. Entonces, ese es, no, una vez que lo empiezas a usar te empiezas a dar cuenta cuántos otros algoritmos simplemente son Multiple dispatch fue implementado mal, de manera ad hoc, no especificado bien, de una manera más chafita.

Y sí, suena interesante. Es casi como el polimorfismo en algunos lenguajes. Sí, aunque vamos, tal y como lo has definido, se ven los matices diferenciales, se ve bastante interesante.

Sí, sí, sí. Entonces, digamos como que Para la gente que venga de Rust, como que entienden que el sistema del borrow checker y de ownership fueron lo que le dieron corazón a todo el lenguaje alrededor de eso. Han diseñado todo el lenguaje alrededor del multiple dispatch, han diseñado todo Julia. Entonces el mundo de Julia sí entras y se ve un poquito distinto ya en sus entrañas, pero como experiencia de usuario de repente dices qué chistoso, todo funciona. Como diseñador es distinto, como usuario es súper amable.

Pues Miguel, muchas gracias por pasarte por aquí y dejarnos todo tu conocimiento. Bueno, parte del conocimiento sobre Julia. Ha estado muy interesante la charla. Y bueno, este es otro capítulo más en Codeadores y nos vemos la semana que viene con otro. Gracias.