Show HN: Lenguaje de programación Wyzer

Artículo original ↗ Discusión en Hacker News ↗

Un nuevo lenguaje de sistemas inspirado en Rust llamado Wyzer está llamando la atención por su intento de unificar reglas de propiedad en memoria, hilos y redes mediante tipos lineales/afines, conteo de referencias estilo Perceus y “programación coreográfica” para generar código distribuido. Los comentaristas se sienten intrigados por la promesa de programas sin interbloqueos, sin GC y multi-nodo, pero señalan repetidamente que el README y el sitio actuales ocultan u omiten ejemplos concretos de estas ideas centrales, haciendo que el lenguaje parezca “Rust sin borrow checker”. Muchos ven un gran potencial —especialmente dada la juventud del autor— pero argumentan que aún es demasiado pronto para una adopción general hasta que haya documentación más clara, ejemplos realistas distribuidos y con mucha memoria, y un tratamiento explícito de compensaciones como el rendimiento del conteo de referencias y el manejo de ciclos.

Recepción general

  • A muchos les parece impresionante la idea y la ambición, especialmente dada la edad del autor, y les gusta el tono claro, no escrito por IA.
  • Otros lo ven como “solo otro lenguaje parecido a Rust” y son escépticos de que llegue a ser más que un proyecto personal.
  • Varias personas dicen explícitamente que el concepto de coreografía es realmente interesante una vez que lo entienden.

Sintaxis y documentación

  • La sintaxis se describe ampliamente como conservadora y familiar (parecida a C/Java/TypeScript/Rust), lo que muchos ven de forma positiva.
  • Varios comentaristas critican el README y el sitio por enterrar las ideas novedosas (programación coreográfica, modelo de memoria estilo Perceus) detrás de sintaxis básica y archivos markdown dispersos.
  • Se piden:
    • Más ejemplos y mejor organizados (especialmente programas no triviales, estructuras de datos y casos distribuidos).
    • Un directorio examples/.
    • Un README de arriba hacia abajo que empiece con las características únicas.
  • Algunos enlaces (sitio de documentación) están rotos actualmente o “en desarrollo”, lo que frustra a quienes llegan temprano.

Programación coreográfica

  • Varias personas no pueden encontrar ejemplos concretos en el repo; los tests disponibles se describen como triviales.
  • Una vez explicado en el hilo, la coreografía se presenta como:
    • Una forma de alto nivel de especificar pasos globales de comunicación (envío+recepción como un único constructo atómico).
    • Los compiladores los “proyectan” a código de endpoint, dando libertad frente a interbloqueos por construcción para los programas compilados.
  • Preguntas planteadas:
    • Cómo se garantiza en la práctica la libertad frente a interbloqueos, especialmente para sistemas distribuidos complejos.
    • Comparaciones con tipos de sesión, lenguajes MPI/PGAS, compiladores sensibles a la arquitectura y “funciones de servidor” en frameworks web modernos.
    • Cómo distinguir llamadas locales de remotas y manejar latencia/tiempos de espera.

Modelo de memoria y rendimiento

  • Wyzer usa ideas lineales/afines más conteo de referencias estilo Perceus; se presenta como “seguridad de memoria sin GC de rastreo”.
  • Los comentaristas preguntan:
    • Cómo se manejan los ciclos (fugas, recolectores de ciclos o restricciones de tipos).
    • Si múltiples propietarios causan problemas sutiles de rendimiento.
  • Un subhilo importante debate si la recolección de basura es intrínsecamente más lenta o menos predecible, con argumentos matizados sobre distintos diseños de GC.

Madurez y posicionamiento del proyecto

  • Algunos sugieren que el proyecto se mostró demasiado pronto; faltan aún documentación central, ejemplos distribuidos y programas realistas.
  • Se sugiere enfatizar:
    • La “regla de una sola propiedad” (memoria/hilos/redes), pero también aclarar sus límites.
    • Casos concretos en los que Wyzer detecta o previene problemas más allá de Rust u otros sistemas.