Mitchell Hashimoto promete donar USD 300.000 a la Zig Software Foundation

 (mitchellh.com)
1 puntos por GN⁺ 2024-10-02 | 1 comentarios | Compartir por WhatsApp
  • Mitchell Hashimoto y su esposa prometieron donar USD 300.000 a la Zig Software Foundation, apoyando públicamente el desarrollo independiente de Zig y la operación de la fundación
  • La donación se entregará a lo largo de 2 años, con USD 150.000 por año, y el primer desembolso ya fue realizado
  • Hashimoto venía siguiendo Zig desde 2019, comenzó a usarlo en 2021 y desde 2022 ha seguido escribiendo sobre el tema y haciendo contribuciones al compilador
  • Ghostty, el proyecto de terminal que presentó en 2023, también está escrito en Zig, y actualmente la mayor parte de su tiempo de programación la dedica a Zig
  • Aunque a Zig todavía le queda camino por recorrer en estabilidad y adopción más amplia en la industria, Hashimoto lo ve como un proyecto con una comunidad sólida y un modelo de financiamiento sostenible, y recomienda donar

Compromiso de donación de USD 300.000

  • Mitchell Hashimoto y su esposa se comprometieron a donar USD 300.000 a la Zig Software Foundation
  • El pago está estructurado para realizarse a lo largo de 2 años, con USD 150.000 cada año
    • El primer desembolso ya fue entregado
  • La ZSF aborda la misión de la fundación y los usos concretos de los fondos en un anuncio aparte

Por qué Hashimoto apoya a Zig

  • Hashimoto ha seguido el proyecto Zig desde alrededor de 2019, y en 2021 compartió públicamente sus expectativas sobre el proyecto
  • Empezó a usar Zig a fines de 2021, y desde comienzos de 2022 empezó a escribir artículos relacionados con Zig y a contribuir al compilador
  • Desde entonces, ha continuado haciendo decenas de contribuciones de código al repositorio de Zig
  • El proyecto de terminal Ghostty, presentado en 2023, fue escrito en Zig, y actualmente Hashimoto dedica la mayor parte de su tiempo de programación a Zig

Evaluación de Zig y la ZSF

  • Hashimoto ve a Zig como un proyecto de software independiente capaz de generar cambio e impacto
  • Zig comenzó como un proyecto impulsado por la pasión y aún mantiene ese carácter; considera que la operación del proyecto y su comunidad son sólidas
  • Ve su modelo de financiamiento como transparente y sostenible, y, en lo técnico, como ambicioso e innovador, pero también práctico y realista
  • Aunque todavía se necesita tiempo para alcanzar estabilidad y una adopción más amplia en la industria, considera que el camino y la oportunidad para lograrlo son claros
  • Aproximadamente un tercio de los fondos de la ZSF proviene de donaciones individuales, y recomienda donar a quienes puedan hacerlo

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-10-02
Opiniones en Hacker News

  • La frase “nuestra filantropía normalmente es privada, pero por mi trayectoria creo que un apoyo público a Zig puede ayudar de verdad al proyecto, así que hago una excepción” me llegó de una forma curiosa
    Es difícil expresarlo con precisión, pero hay una decencia básica ahí que merece reconocimiento

    • Yo sentí algo parecido, aunque quizá en el sentido opuesto
      ¿Quiere decir que el apoyo público no ayuda a otras actividades filantrópicas? Si es así, me dio curiosidad saber qué tipo de actividades son. Claro, si uno hace caridad con su propio dinero, al final puede hacerlo como quiera, pero la forma de expresarlo sonó un poco curiosa
    • Si donar dinero y ponerle el propio nombre tiene valor en sí mismo, tiene bastante sentido
      En este caso, ese apoyo público podría atraer contribuciones adicionales mayores que el monto de su propia donación
    • Me parece completamente natural decir de forma simple que apoyas algo en lo que crees y explicar por qué te importa
    • Me pregunto si es por el apoyo público, o porque la filantropía normalmente es privada

  • Si alguien de Zig Foundation está leyendo, recomiendo mucho crear una bolsa de trabajo
    En un lugar con lectores de un nicho específico, es casi una fuente de ingresos gratis

    • Yo lo hago

  • Puede ser una pregunta tonta, pero como desarrollador web normalmente solo me acerco a la programación de sistemas/de bajo nivel por curiosidad
    Se suele decir que, siempre que sea posible, hay que migrar todo a lenguajes con seguridad de memoria, pero Zig no parece ofrecer esas garantías. Si Zig es un lenguaje nuevo, su uso principal serán proyectos nuevos; entonces me pregunto si no deberían empezar con un lenguaje con seguridad de memoria. Si la ventaja de Zig es “más moderno que C y más simple que Rust”, entiendo el atractivo, pero ¿no se debilita esa ventaja si le falta seguridad de memoria?

    • La seguridad de memoria es un concepto útil, pero no es una panacea ni una dicotomía
      Si el objetivo final fuera solo la seguridad, JavaScript habría bastado. Rust seguro garantiza seguridad de memoria, así que es una gran mejora en programación de sistemas, pero no siempre es la respuesta definitiva. Hay compromisos según la aplicación, y personalmente creo que es más importante que la seguridad sea fácil de lograr que tener seguridad garantizada. El problema de C y C++ era que hacerlos seguros era demasiado difícil
    • En las áreas donde Zig realmente brilla, si escribieras el mismo código en Rust probablemente terminarías con mucho unsafe, lo que en la práctica equivale a desactivar las funciones de seguridad de memoria
      Todavía habrá que ver si Zig es realmente menos seguro que Rust. En cualquier caso, para hacer que un programa sea seguro hay que escribir muchas pruebas, y Rust no elimina mágicamente todos los bugs. En Zig, si pruebas lo suficiente en modo debug, probablemente puedas atrapar la mayoría de los bugs de seguridad de memoria. Aun así, si fuera a hacer algo como un navegador web, creo que usaría Rust
    • También se puede escribir código muy rápido y muy seguro en C/C++
      Basta ver la industria de los videojuegos, o la industria en general en la época en que el software tenía que grabarse en discos para distribuirse. El problema actual es que la complejidad de los lenguajes aumentó y el nivel promedio de habilidad de los desarrolladores de software bajó. Que Google creara Go fue, en cierta medida, para resolver este problema, y Rust es otro lenguaje que puso la seguridad de memoria en el centro de su diseño. Otra razón por la que Rust favorece escribir programas más seguros es que es mucho menos complejo que C++. Aunque se está volviendo cada vez más complejo, por suerte en la comunidad de Rust el concepto de seguridad de memoria está profundamente arraigado, así que aunque el lenguaje se complique, esa ventaja y los hábitos de los desarrolladores seguirán presentes
      Zig también es una buena opción si valora la seguridad. Simplifica con sintaxis como defer y ofrece varios targets de ejecución y herramientas para detectar problemas de seguridad de memoria durante el desarrollo. El compilador no lo impone; se detecta en runtime en compilaciones de desarrollo/no ReleaseFast, pero aun así es una mejora frente a C/C++
    • No estoy seguro de que tenga sentido etiquetar a Zig entero como “inseguro en memoria”
      Tiene bastantes herramientas y verificaciones de seguridad de memoria que C no tiene. La seguridad es un espectro. C es menos seguro que C++, C++ es menos seguro que Zig, Zig es menos seguro que Rust, Rust es menos seguro que Java y Java es menos seguro que Python. El comportamiento indefinido y la corrupción de memoria siguen siendo posibles en todos; la diferencia es qué tan fácil es que ocurran
    • Creo que la falta de seguridad de memoria debilita en parte las ventajas de Zig
      Aun así, Zig todavía no es un lenguaje terminado, así que es difícil afirmarlo ahora. Zig tiene buenas funciones de seguridad de memoria, y aunque no está al nivel de JavaScript o Rust, tampoco es igual que C. La última vez que revisé, el uso después de liberar memoria era un problema grande, y si no logran resolverlo, creo que Zig no tiene futuro
      JavaScript sí es un lenguaje realmente seguro en memoria, pero su runtime y su nivel de abstracción no son adecuados para programación de sistemas. Para programación de sistemas, creo que se necesita algo que sea seguro en memoria por defecto, pero con vías de escape, y con una abstracción baja, apenas un nivel por encima del PDP-11 virtual al que en general han apuntado los compiladores y las CPU. Debe permitir que el programador piense según el modelo de ejecución de la CPU sin quedar enterrado en los detalles, y también debe tener una interoperabilidad muy buena con C
      Creo que Rust logró bien lo primero. Su debilidad es lo segundo. Tiene capacidades de bajo nivel, pero están enterradas bajo una pila de complejidad de funciones del lenguaje. Además, no permite algunos patrones de gestión de memoria que son completamente seguros, por lo que hay que usar unsafe demasiado seguido o retorcer el código para ajustarlo al espacio de la solución, no al dominio del problema
      Zig es débil en lo primero. Tiene buenas funciones, pero también huecos grandes. En cambio, es bastante fuerte en lo segundo. Lo que me gustaría es que Zig ofreciera seguridad de memoria por defecto, pero de una forma mucho más flexible que Rust, y que mantuviera sus ventajas de baja abstracción e interoperabilidad con C

  • Al ver la noticia reciente de que pasaron a autoalojamiento, me dio la impresión de que es un proyecto especialmente eficiente, que no va a desperdiciar las donaciones

  • “Amor, hay un lenguaje de programación que me gusta muchísimo y quiero hablarte de él”
    “¿Sí?…”
    “Me gusta tanto, tanto ese lenguaje, que quiero donar algo de dinero…”
    “……Ahí vas de nuevo……”

    • O también podría pasar así:
      “¡Me parece bien! Subámonos a nuestro Cirrus SF50 Vision y vayamos a entregárselo en persona a Andrew Kelley”

  • Sin duda es una buena noticia, pero para ponerlo en perspectiva, esta cantidad equivale más o menos a entre 0.75 y 1 salario anual de un desarrollador experimentado que trabaja con compiladores
    Es una conjetura, pero Microsoft probablemente gasta cada año entre 10 y 20 veces eso solo en TypeScript, y mucho más en C++/C#, etc.

    • Hay desarrolladores que ganan tanto, y es más probable en lugares como Microsoft o Mozilla, pero si se mira el mercado global y los proyectos pequeños de compiladores, seguramente hay muchos desarrolladores experimentados de compiladores que ganan menos de 150 mil dólares al año
      Claro que el costo de un desarrollador no termina en el sueldo. Aun así, sentí que los puestos similares al de un desarrollador de compiladores que trabaja en un compilador estándar ANSI dentro de una gran empresa tecnológica suelen incluir una buena dosis de “pago por riesgo”, porque el trabajo real puede ser bastante desagradable en comparación con tareas más libres
    • Un rol en un proyecto relativamente nuevo y de alto potencial como este puede ser una oportunidad bastante atractiva para alguien que ya está convencido de Zig
      Con el financiamiento adecuado, puede servir como catalizador para no tener que tener dos trabajos ni limitarse a trabajar de noche o los fines de semana

  • Francamente, Zig me genera muchas expectativas
    Es ágil y sin adornos innecesarios, y no es un lenguaje creado por gente en una torre de marfil a la que no le importa la usabilidad real. Tampoco fue diseñado por un equipo de doctores como Haskell, aunque claramente parece haberse inspirado en ideas útiles de Rust, Haskell y otros. Escribir código en Zig suena bastante interesante

    • A mí también me entusiasma Zig de manera similar
      Quizá sus garantías de seguridad de memoria no sean tan completas como las de Rust, pero me gustaría ver Zig algún día en el Linux Kernel. Tal vez los programadores veteranos de C del kernel se adapten más fácilmente a Zig que a Rust
    • Sé que a la comunidad de Zig no le gustará esta opinión, pero volveré a entusiasmarme con Zig cuando se pueda desactivar zig fmt en lugares como vim o VS Code
      Cuando se imponen las preferencias de estilo, queda un sabor amargo. Se siente como una actitud que no respeta a los desarrolladores que usan el lenguaje como herramienta. También podría ser una señal de problemas más profundos en torno a la participación de la comunidad y la apertura a otros puntos de vista, y Zig realmente parece tener esos problemas[0]
      Si una empresa necesita consistencia en el código, basta con ejecutar un linter; en mis proyectos de fin de semana no me importa nada más que mis propias preferencias de estilo. La cuestión es si Zig es o no un lenguaje para adultos. Si de todos modos me van a obligar a programar de una forma específica, no hay razón para no usar Rust, que además te da seguridad de memoria gratis
      [0] https://github.com/ziglang/zig/issues/16270