Mi programa Erlang favorito (2013)

• Con el alcance de notas proporcionado, no es posible determinar cuál es el programa Erlang del título ni por qué es importante
• El texto verificable consiste principalmente en fragmentos de script de Shell y una breve frase de corrección
• El script recorre archivos *.png.png.meta del directorio actual y extrae la parte anterior al primer punto del nombre del archivo
• El comando que realmente se ejecuta es git mv $i $j.png.meta, y el comando para cambiar $j.png.png por $j.png solo se imprime
• Como se omitió el fragmento original 5-104, no es posible verificar la afirmación central relacionada con el título ni la explicación del código Erlang

---

Contenido verificable

• Con el alcance proporcionado, es difícil determinar la identidad de “mi programa Erlang favorito”, la razón de esa preferencia o la estructura del código
• El fragmento de código verificable es un script de Shell para renombrar archivos que comienza con #!/bin/sh
  • Recorre archivos *.png.png.meta
  • Usa j="${i%%.*}" para extraer la parte anterior al primer punto del nombre del archivo
  • git mv $i $j.png.meta sí se ejecuta realmente
  • git mv $j.png.png $j.png solo se muestra con echo
• Aparece la frase “Actually you don't need the really do this. It should have been water the plants.”, que puede leerse como una corrección indicando que la instrucción o ejemplo anterior en realidad no era necesario y que debería haber sido “water the plants”
• Al final se mencionan juntos Joe Armstrong y Jeremy Ruston

Contexto que limita la evaluación

• Varios fragmentos están compuestos por metadatos de estado/barra lateral de TiddlyWiki, datos Base64 que parecen ser JPEG/PNG y contenido vacío, lo que dificulta extraer hechos del cuerpo principal
• Las notas proporcionadas no incluyen información clave como el funcionamiento del programa Erlang, su código, motivos de diseño, ejemplos, cifras, flujo de trabajo o argumentos principales
• El fragmento del script de Shell también se proporciona solo de manera parcial y sin explicación alrededor, por lo que no se puede determinar con certeza de qué tarea forma parte

Rango omitido

• En la entrada se indica explícitamente que los fragmentos originales 5-104 fueron omitidos por límites de longitud/costo
• Este resumen refleja únicamente el rango de notas proporcionado y no cubre los detalles ni la conclusión del texto completo

[GN⁺]

Opiniones de Hacker News

• Si el cierre de servidor F pudiera recibir, además de sus propios mensajes, el mensaje {become, F}, se podría seguir convirtiendo el servidor en nuevos comportamientos.
  Es un tema totalmente distinto, pero me quedó el recuerdo de haber hablado con Joe en una conferencia de Erlang. Siempre estaba entusiasmado con la tecnología y estaba dispuesto a conversar con cualquiera. Le entristecía que Windows se volviera peor y menos usable año tras año, y dijo que algún día, para ver un archivo, habría que mirar anuncios durante un rato para desbloquearlo; casi le está atinando. Windows 11 ya tiene anuncios, y para quitarlos hay que buscar a propósito en la configuración, así que para Windows 13 parece que de verdad será así.

  • En casa uso Linux y en el trabajo Windows, y más que los anuncios, lo que más me sorprendió es que en Windows aparecen con mucha más frecuencia problemas raros que antes solo veía en Linux antiguo.
    Cosas como que un audífono suene mucho más fuerte que el otro, que una app de Microsoft se cierre de forma extraña, que una página de documentación de Windows no abra en ningún navegador y haya que usar un sitio de archivo, o que de pronto no detecte un monitor externo que antes funcionaba bien, o que la pantalla parpadee. Office básicamente te empuja a guardar en la nube en vez de localmente, pero yo preferiría que los archivos fueran local-first y que la nube fuera un respaldo. WSL es bastante tosco, pero aun así es casi la única razón por la que puedo usar Windows.
    Siempre escuché que Joe era una gran persona, y me hace sentido. Cuando estaba aprendiendo a programar por mi cuenta, leí su libro de Erlang, y su espíritu juguetón, humildad e imaginación me influyeron mucho. Aunque casi no terminé usando Erlang, sus escritos cambiaron mi forma de pensar sobre el código, y ojalá la cultura de las matemáticas, la ingeniería de software y las ciencias de la computación aceptara más el espíritu juguetón y la humildad.
  • Lo del primer párrafo en realidad es una capacidad del modelo de actores. No sabía antes que también se pudiera hacer en BEAM.
  • La publicidad intrusiva de Windows 11 no es algo nuevo. Ya está también en Windows 10.

• Un video breve de 35 minutos que explica por qué BEAM es distinta de otras máquinas virtuales como JVM o Node: https://www.youtube.com/watch?v=pO4_Wlq8JeI

  • Vi una charla similar, The Soul of Erlang and Elixir, y fue excelente; cada vez que la veo me vuelve a entusiasmar.

• Extraño a Joe. Su entusiasmo contagioso por hacer que la computación fuera mejor dejó una huella profunda en mi yo joven y en la forma en que hoy abordo la tecnología.

• universal_server() -> receive {become, F} -> F() end.
  Sinceramente, no termino de entender el poder de este universal_server. Ojalá alguien pudiera explicarlo.

  • Si conoces Go, es parecido a una goroutine que espera a que alguien le envíe una función anónima para ejecutarla.
    En Erlang se lanzan muchos procesos para resolver problemas, y la mayoría de esos procesos esperan mensajes. La diferencia importante es que los procesos de Erlang pueden ejecutarse sin fricciones también en máquinas remotas. Este proceso recibe un mensaje en forma de tupla con el átomo become y una función, y cuando cualquier otro proceso le envía ese mensaje, “se transforma” en esa función.
    Es decir, puedes reemplazar la lógica del bucle de espera por la lógica del protocolo que quieras. Como ejemplo, se puede poner este bucle en varias máquinas y enviarles una función que implementa un protocolo gossip, pero igual podrías enviarles un mensaje para que se conviertan en un cliente BitTorrent. Joe era un genio y una persona muy amable, y Erlang es una de las creaciones técnicas más hermosas que he visto. Te hace ver la concurrencia de una forma completamente nueva.
  • Para explicarlo un poco más, la palabra clave receive se parece a una instrucción switch sobre mensajes entrantes, pero en realidad es pattern matching.
    Por ejemplo, puedes crear un servidor de factorial que reciba {From, N} y devuelva el resultado con From ! factorial(N). ! es el operador que envía el resultado al proceso de retorno.
    El código de prueba levanta universal_server, lo convierte en un servidor de factorial con Pid ! {become, fun factorial_server/0}, y luego envía {self(), 50} para recibir el factorial de 50. Una gran ventaja de Erlang es el paralelismo distribuido y las actualizaciones de código en caliente, y aquí se ve como sobrescribir el bucle de recepción de universal_server con el bucle de recepción de factorial_server. Aunque creo que las actualizaciones reales de código en caliente no funcionan exactamente de esta manera.
  • Normalmente hay que escribir el código sabiendo de antemano para qué se va a usar el servidor.
    Pero en Erlang puedes crear una red distribuida de servidores Erlang y dejar los servidores como recursos de cómputo de propósito general que pueden hacer lo que el cliente quiera. El código viene del cliente; no hace falta pedirle al administrador del sistema que instale binarios en todas las máquinas, basta con pasar una función y la máquina remota la invoca.
  • La clave es que puede transformarse en cualquier tipo de servidor que quieras.
    El cliente entrega la función real que ejecutará el servidor, y el proceso de Erlang se convierte en ese servidor con base en esa función. Si además se considera la capacidad de hot reloading de Erlang, esta estructura simple se vuelve todavía más potente. Un proceso de Erlang es un recurso de cómputo que espera trabajo, y si ese trabajo consiste en ejecutar un servidor completo, resulta bastante genial.
  • La estructura de Erlang es peculiar: tanto la máquina virtual como el lenguaje están construidos sobre la idea de que muchos procesos pequeños funcionan al mismo tiempo y cada proceso espera en un bucle infinito para interpretar los mensajes que le llegan.
    Por eso, un proceso puede convertirse en cualquier cosa según el código que le envíes. Si debe controlar un microondas, luego hacer cómputo cuántico y al día siguiente predecir el ganador de un partido de fútbol, le envías el código necesario para cada tarea y lo ejecuta tal cual.

• Paso mucho tiempo explicando por qué BEAM es especial y por qué la concurrencia de Erlang/Elixir y similares es distinta de la concurrencia de Go o Java.
  Creo que de ahora en adelante bastará con enlazar al programa favorito de Erlang de Joe y a este hilo de HN.

• Esta entrada de blog también se trató en una excelente charla reciente: https://youtu.be/pQ0CvjAJXz4

  • Es una charla que cubre y explica muy bien cada etapa de la arquitectura de sistemas Erlang distribuidos, tolerantes a fallos y de alta disponibilidad.
  • Me pregunto si es ese sistema en el que cada paciente se representa con un proceso de Erlang.

• Solo tengo una comprensión de alto nivel del lenguaje Erlang y no he programado directamente en él, pero me da curiosidad por qué es necesario este código
  universal_server() -> receive {become, F} -> F() end.
  Me parece que bastaría con ejecutar F() directamente en la máquina remota. Como la máquina virtual remota ya tendría que tener el código de F, quizá este ejemplo significa que se serializa y se envía el código de F. Si se encargara de manejar boilerplate común, entendería su utilidad, pero ahora parece que solo espera el mensaje become F y luego ejecuta F()

  • Este código es genial, pero puede que no sea muy idiomático ni algo que se vea a menudo en código de producción real. Aun así, a Joe le gustaba explorar y experimentar
    Aquí F es un closure, así que puede incluir no solo código, sino también las variables capturadas y el entorno del momento en que se creó. Al llamar a F(), se ejecuta ese código y puede acceder al entorno circundante que existía cuando se creó F
    En Erlang se pueden enviar closures a través de la red a otros nodos Erlang. Sin embargo, el código de los módulos a los que hace referencia el closure debe estar en todos los nodos. En código de producción, como dices, lo más probable es que se llame directamente al módulo F y se pasen los argumentos de forma explícita; esto se parece más a una demostración elegante de lo que es posible
  • Gracias al diseño funcional de Erlang, F() puede convertirse en un contexto de nivel superior tan bueno como cualquier contexto anterior, y eso es genial
    Puedes hacer que las solicitudes existentes se procesen naturalmente con la lógica anterior, mientras que las nuevas comienzan con la lógica nueva, y al final la lógica anterior puede ser recolectada por el garbage collector
  • Es cierto que la máquina virtual remota ya tiene que tener el código de F, pero también se puede enviar código a la máquina virtual remota
    Por ejemplo, en Elixir puedes obtener el nombre del módulo y el binario de bytecode BEAM con Code.compile_string. Luego puedes enviar ese bytecode a otra máquina virtual, cargarlo en la máquina virtual remota con :rpc.call('node@remote_host', :code, :load_binary, [the_module_name, "filename_doesnt_really_matter", binary_code]) y después ejecutarlo con spawn('node@remote_host', my_module, my_function, [args])
  • El programa citado estaba pensado para ejecutarse en una máquina remota, y la máquina remota deserializa el programa que debe ejecutar
    Aquí F es una variable que representa el nuevo programa serializado y enviado como mensaje entre procesos; en este caso, también se transmite por la red

• También hay una clase en la que Joe explica cómo escribir un servidor básico en Erlang: https://gioorgi.com/2015/erlang-lesson1/
  La transcribí a mano y le agregué un poco más de explicación; muestra el poder que tienen los lenguajes asíncronos como Erlang/Elixir frente a otros lenguajes. Lamentablemente, hoy en día no se usan mucho

• Últimamente estoy muy metido en Julia, y parece que tomó prestadas bastantes ideas de Erlang para su modelo distribuido
  También en Julia se puede reproducir con bastante facilidad este tipo de servidor improvisado que funciona casi mágicamente entre varios nodos. No estoy totalmente seguro, pero me cuesta creer que el módulo Distributed de Julia no se haya inspirado al menos un poco en Erlang
  Me encanta Erlang y ojalá tuviera más oportunidades de usarlo, pero también es bueno ver cómo sus conceptos se filtran a otras plataformas

  • Creo que en la comunidad de Julia estaríamos del mismo lado al intentar convencer con lecciones como let it crash, derivadas de la filosofía de Erlang sobre el reporte de errores