Siete runtimes async, siete respuestas distintas para el mismo programa
A Design Space Exploration of Async/Await
El mismo programa asíncrono que lanza una escritura de log en segundo plano produce cuatro salidas diferentes en siete runtimes modernos, y ninguna coincide en tres variaciones. Los autores analizan nueve dimensiones de diseño —como Eagerness, Extent, Destruction o Cancellation— y las formalizan en un cálculo central para explicar por qué lenguajes como Swift, Python+Trio o JavaScript divergen incluso en ejemplos mínimos.
En el artículo mostramos que, entre los siete runtimes, no hay dos que produzcan la misma salida para tres variaciones de este simple programa.
- spankalee
¡Vaya, esto es realmente útil y oportuno!
Estoy construyendo un nuevo lenguaje con async/await y tuve que tomar muchas de estas decisiones, pero no tenía un marco tan organizado en el que basarme. Me alegra ver claramente que elijo mayormente Trio con un poco de JavaScript.
La página de documentación de async de mi lenguaje (Zena): https://zena-lang.dev/guide/async/ Creo que podría hacer una pasada e intentar señalar los puntos de decisión de manera más explícita.
Por si sirve de algo, encontré muy convincente esta publicación sobre cancelación del autor de Trio: https://vorpus.org/blog/timeouts-and-cancellation-for-humans... y basé el diseño de cancelación de Zena en ella.
Edición para agregar: Desearía que esto incluyera el AbortSignal de JavaScript en la sección de Cancelación. No porque sea bueno, sino porque pasar tokens de cancelación es un patrón que existe. También está la dimensión de quién puede cancelar y, como AbortSignal, si las tareas tienen que optar por comprobaciones de cancelación.
- biorach
Durante mucho tiempo ha estado claro que había decisiones fundamentales de implementación que importaban entre los runtimes async, pero ¿_nueve_ dimensiones de diseño? Vaya.
Creo que async es engañoso en el sentido de que parece un aspecto autocontenido y relativamente sencillo de un lenguaje. Pero hay muchas decisiones de diseño que tomar y todas tienen amplias implicaciones.
Además, creo que las implicaciones de muchas de estas dimensiones no se entienden completamente y que colectivamente todavía estamos tratando de entender cómo se desarrollan en las implementaciones. Súmale a esto la naturaleza sutil de algunas de las implicaciones más las combinaciones...
Creo que una buena comparación es el ámbito léxico frente al dinámico en los lenguajes de programación. Esta es una dimensión de diseño que se debatió durante una o dos décadas en los primeros años del diseño de lenguajes de programación. Solo con el tiempo, y la experiencia adquirida al trabajar con implementaciones concretas, quedó claro que el ámbito léxico debería ser la opción por defecto y el ámbito dinámico debería restringirse a varios nichos.