John Carmack: el análisis automático de Goose lleva el lenguaje de "mucho se puede hacer así" a "básicamente todo"

Tengo curiosidad, para alguien más familiarizado con Goose: ¿cómo representas un número arbitrario de valores de tamaño dinámico? Si tienes un número fijo de stacks, parece que solo un número fijo de valores puede cambiar de tamaño en un momento dado.

Por ejemplo, ¿cómo representarías una tabla hash donde los valores son strings y, de forma aleatoria, el programa inserta o elimina un string aleatorio?

Esto no parece algo que puedas representar fácilmente. La única forma que se me ocurre es mantener un stack que contenga todos tus strings y compactarlo periódicamente.

Edito: Quizá también podrías tener un stack separado para strings de varios tamaños. Uno para strings de menos de 8, 16, ... bytes. Pero a esas alturas básicamente estás implementando tu propio malloc a mano.

Edito: Dicho esto, ¡creo que Goose es muy guay! Antes he tenido que hacer a mano un montón de cosas similares en Rust para acelerar la gestión de memoria

"Hilos que no comparten nada. Un worker se compila como un programa separado con su propia memoria, y los valores planos cruzan colas tipadas como un memcpy. Las carreras de datos, los locks, los atomics y los memory orderings no existen en el lenguaje."

Eso me recuerda a los Isolates de Dart - https://dart.dev/language/isolates

Me parece recordar que los chicos de ML fueron por este camino. Creo que lo llamaban regions.

Por lo poco que leí en la literatura, me parece recordar que había suficientes programas con bastante más uso de memoria como para que decidieran que este enfoque era un callejón sin salida.

¿Alguien sabe más detalles?

"¡Eso se ve realmente genial! El análisis automático y el uso de múltiples data stacks y campos redimensionables lo llevan de "mucho trabajo se puede hacer así" a "básicamente todo se puede".

Las referencias relativas y la validación de estructuras binarias integrada también permiten el memory mapping directo de estructuras de datos y el uso inmediato de datos de red. El "parsing" de datos de archivos y de red a menudo es 100x más lento de lo que necesita ser." - John Carmack

¡Esto parece muy interesante! Yo escribo sobre todo en lenguajes con garbage collection (hasta el punto de que todavía escribo algo a mano...) así que soy solo un espectador en los debates sobre gestión de memoria, pero a menudo me ha llamado la atención que la gestión del heap es más un arte que una ciencia. La idea de tratar la memoria más como stacks me pareció intuitiva de inmediato. También me fascina la implementación de hilos, aunque no tengo conocimientos suficientes para reflexionar sobre los posibles beneficios/costes frente a otros enfoques de concurrencia.

Me pregunto si el nombre del lenguaje se inspiró en la forma en que vuelan los gansos en formación, con las aves de atrás ahorrando energía al volar dentro de la sombra aerodinámica de los líderes, y turnándose según sea necesario. Si es así, es una metáfora muy bonita para el modelo de gestión de memoria.

También me impresionó la documentación. Como sabemos, la documentación generada por IA tiende a ser bastante mediocre, pero el autor claramente ha invertido tiempo en hacerla legible, de modo que la relevancia y la razón de ser de las decisiones de diseño proporcionan el contexto que un programador curioso necesita para entender por qué las cosas están implementadas de una manera particular.

Realmente aprecié los ejemplos detallados, que van desde teoremas algorítmicos simples hasta un pequeño juego. De nuevo, no tengo la experiencia para valorar el lenguaje frente a otros, pero me llamó la atención lo legible que era el código y lo fácil que resultaba seguir el flujo de las tareas. ¡No tener que pensar en clases siempre es un plus!

En fin, normalmente recibo la propuesta de un nuevo lenguaje con desapego […]

Goose es bastante guay. La idea es que no necesitas hacer representables todos los programas: un lenguaje para un propósito restringido está bien. Mientras puedas especificar estáticamente el número de regiones de memoria que pueden crecer, puedes usar Goose. Sin embargo, como no hay garbage collection, probablemente tendrás que tener cuidado con el uso de memoria mientras el programa se ejecuta. Es decir: los stacks pueden volverse demasiado grandes si sigues haciéndolos crecer, incluso cuando los datos antiguos ya no se usan.

Aun así, para un gran número de programas —como las aplicaciones orientadas a datos— probablemente sea un buen encaje. Podría funcionar bien con sistemas de juego entity-component siempre que reutilices la memoria antigua…

¿Cómo funcionaría esto en el terreno de wasm? Es una pregunta un poco mal planteada, porque deja fuera mucho contexto —wasm— dónde, cómo, qué implementación, pero por lo que entiendo a grandes rasgos, la mayor parte de wasm es de 32 bits ejecutándose en un navegador. Para que esto funcione, necesitará un espacio de direcciones virtuales real de 64 bits (o 48 bits). El host, siendo el navegador, u otra cosa, puede proporcionarlo, pero...

Si el host necesita cargar varios de estos .wasm, compilados con goose, entonces también tendrá que ejecutarlos en instancias (del navegador) separadas (o quizá así es como funciona wasm por defecto —no estoy seguro).

Simplemente me hizo pensar: el lenguaje está preparado para traducirse a workers de javascript, porque en realidad es de un solo hilo por naturaleza con comunicación entre hilos (o, usando el término de Dart, "isolates"), lo que los hace perfectos para el navegador; ahora la única pregunta es el diseño de memoria.