Mitchell Hashimoto ให้คำมั่นบริจาค 300,000 ดอลลาร์แก่ Zig Software Foundation

 (mitchellh.com)
1 คะแนน โดย GN⁺ 2024-10-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Mitchell Hashimoto และภรรยาให้คำมั่นบริจาค 300,000 ดอลลาร์แก่ Zig Software Foundation เพื่อสนับสนุนการพัฒนา Zig อย่างเป็นอิสระและการดำเนินงานของมูลนิธิอย่างเปิดเผย
  • เงินบริจาคจะจ่ายเป็นเวลา 2 ปี ปีละ 150,000 ดอลลาร์ โดยเงินงวดแรกได้ส่งมอบแล้ว
  • Hashimoto ติดตาม Zig มาตั้งแต่ปี 2019 เริ่มใช้งานในปี 2021 และตั้งแต่ปี 2022 ก็เขียนบทความพร้อมทั้งมีส่วนร่วมกับ คอมไพเลอร์ อย่างต่อเนื่อง
  • โปรเจกต์เทอร์มินัล Ghostty ที่เปิดตัวในปี 2023 ก็เขียนด้วย Zig และปัจจุบันเวลาส่วนใหญ่ที่เขาใช้เขียนโค้ดหมดไปกับ Zig
  • แม้ Zig ยังต้องใช้เวลาอีกระยะเพื่อไปสู่ความเสถียรและการยอมรับในอุตสาหกรรมที่กว้างขึ้น แต่ Hashimoto มองว่าเป็นโปรเจกต์ที่มีชุมชนแข็งแกร่งและโมเดลเงินทุนที่ยั่งยืน จึงแนะนำให้บริจาคสนับสนุน

คำมั่นบริจาค 300,000 ดอลลาร์

  • Mitchell Hashimoto และภรรยาให้คำมั่นว่าจะบริจาค 300,000 ดอลลาร์ ให้กับ Zig Software Foundation
  • โครงสร้างการจ่ายเงินจะดำเนินเป็นเวลา 2 ปี โดยจ่ายปีละ 150,000 ดอลลาร์
    • เงินงวดแรกได้ส่งมอบแล้ว
  • ZSF กล่าวถึงพันธกิจของมูลนิธิและรายละเอียดการใช้เงินทุนไว้ในประกาศแยกต่างหาก

เหตุผลที่ Hashimoto สนับสนุน Zig

การประเมิน Zig และ ZSF

  • Hashimoto มองว่า Zig เป็นโปรเจกต์ซอฟต์แวร์อิสระที่สามารถสร้าง การเปลี่ยนแปลงและอิทธิพล ได้
  • Zig เริ่มต้นจากโปรเจกต์ที่ทำด้วยความหลงใหล และปัจจุบันก็ยังคงลักษณะนั้นไว้ โดยเขาประเมินว่าการดำเนินงานของโปรเจกต์และชุมชนมีความแข็งแกร่ง
  • เขามองว่าโมเดลเงินทุนมีความโปร่งใสและยั่งยืน ส่วนในเชิงเทคนิคก็ทะเยอทะยานและสร้างสรรค์นวัตกรรม ขณะเดียวกันก็ใช้งานได้จริงและอยู่บนความเป็นจริง
  • แม้ยังต้องใช้เวลาไปถึงความเสถียรและการยอมรับในอุตสาหกรรมที่กว้างขึ้น แต่เขาเห็นว่าเส้นทางและโอกาสที่จะไปถึงจุดนั้นมีความชัดเจน
  • เงินทุนของ ZSF ประมาณ หนึ่งในสาม มาจากการบริจาคของบุคคลทั่วไป และเขาแนะนำให้ผู้ที่สามารถทำได้บริจาคสนับสนุน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-02
ความคิดเห็นบน Hacker News

  • ประโยคที่ว่า “โดยปกติเราจะทำกิจกรรมการกุศลแบบไม่เปิดเผย แต่ด้วยภูมิหลังของผม ผมคิดว่าการสนับสนุน Zig อย่างเปิดเผยอาจช่วยโครงการได้จริง จึงขอยกเว้นกรณีนี้” ทำให้รู้สึกสะดุดใจอย่างประหลาด
    อธิบายให้ชัดเจนยาก แต่ ความสง่างามพื้นฐาน ที่อยู่ในนั้นควรได้รับคำชม

    • ผมก็รู้สึกคล้ายกัน แต่อาจเป็นไปในทางตรงข้าม
      หมายความว่ากิจกรรมการกุศลอื่น ๆ ไม่ได้ประโยชน์จากการสนับสนุนอย่างเปิดเผยหรือ? ถ้าเป็นอย่างนั้นก็สงสัยว่ากิจกรรมเหล่านั้นมีลักษณะอย่างไร แน่นอนว่าการทำบุญด้วยเงินของตัวเอง สุดท้ายก็ทำตามใจได้ แต่ถ้อยคำฟังดูแปลกนิดหน่อย
    • ถ้าการบริจาคเงินพร้อมกับให้ชื่อของตัวเองถูกผูกไว้กับเรื่องนั้นมีคุณค่าในตัวเอง ก็สมเหตุสมผลพอแล้ว
      ในกรณีนี้ การสนับสนุนแบบเปิดเผยนั้นอาจดึง การมีส่วนร่วมเพิ่มเติม ที่ใหญ่กว่ายอดบริจาคของเขาเองก็ได้
    • ผมมองว่าการบอกสั้น ๆ ว่าสนับสนุนสิ่งที่เชื่อ และอธิบายว่าทำไมถึงใส่ใจ เป็นเรื่องธรรมชาติอย่างยิ่ง
    • สงสัยว่าเป็นเพราะเป็นการสนับสนุนแบบเปิดเผย หรือเพราะปกติกิจกรรมการกุศลทำแบบไม่เปิดเผยกันแน่

  • ถ้ามีคนจาก Zig Foundation กำลังอ่านอยู่ ขอแนะนำอย่างยิ่งให้ทำ บอร์ดประกาศงาน
    สำหรับที่ที่มีผู้อ่านเฉพาะด้านอยู่แล้ว มันแทบจะเป็นแหล่งรายได้ฟรี

    • เดี๋ยวผมลองทำดู

  • อาจเป็นคำถามโง่ ๆ แต่ในฐานะเว็บเดเวลอปเปอร์ ผมมักสัมผัสงานระบบ/การเขียนโปรแกรมระดับต่ำเพียงเพราะความอยากรู้อยากเห็น
    เขาว่ากันว่า ถ้าเป็นไปได้ก็ควรย้ายทุกอย่างไปใช้ ภาษาที่ปลอดภัยต่อหน่วยความจำ แต่ Zig ดูเหมือนไม่ได้ให้การรับประกันแบบนั้น ถ้า Zig เป็นภาษาใหม่ การใช้งานหลักก็น่าจะเป็นโปรเจกต์ใหม่ ๆ แล้วถ้าอย่างนั้นไม่ควรเริ่มด้วยภาษาที่ปลอดภัยต่อหน่วยความจำหรือ? ถ้าจุดเด่นของ Zig คือ “ทันสมัยกว่า C และเรียบง่ายกว่า Rust” ผมเข้าใจความน่าสนใจนะ แต่ถ้าขาดความปลอดภัยต่อหน่วยความจำ จุดเด่นนั้นก็อ่อนลงหรือเปล่า?

    • ความปลอดภัยต่อหน่วยความจำเป็นแนวคิดที่มีประโยชน์ แต่ไม่ใช่ยาครอบจักรวาล และไม่ใช่เรื่องขาวดำ
      ถ้าเป้าหมายสุดท้ายมีแค่ความปลอดภัย JavaScript ก็น่าจะเพียงพอแล้ว Rust แบบ safe รับประกันความปลอดภัยต่อหน่วยความจำ จึงเป็นการปรับปรุงครั้งใหญ่ในงาน system programming แต่ก็ไม่ใช่คำตอบสุดท้ายเสมอไป มีการแลกเปลี่ยนขึ้นอยู่กับแอปพลิเคชัน และส่วนตัวผมมองว่าความสามารถในการทำให้ปลอดภัยได้ง่าย สำคัญกว่า ความปลอดภัยที่รับประกัน ปัญหาของ C และ C++ คือการทำให้มันปลอดภัยนั้นยากเกินไป
    • ในพื้นที่ที่ Zig โดดเด่นจริง ๆ ถ้าเขียนโค้ดเดียวกันด้วย Rust ก็น่าจะมี unsafe เยอะ จนโดยพฤตินัยเท่ากับปิดฟีเจอร์ความปลอดภัยต่อหน่วยความจำไป
      จริง ๆ แล้ว Zig ปลอดภัยน้อยกว่า Rust หรือไม่นั้นยังต้องดูกันต่อไป ไม่ว่าจะฝั่งไหน ถ้าจะทำให้โปรแกรมปลอดภัยก็ต้องเขียนเทสต์เยอะ ๆ และ Rust ก็ไม่ได้ลบทุกบั๊กออกไปด้วยเวทมนตร์ ใน Zig ถ้าทดสอบในโหมดดีบักให้เพียงพอ ก็น่าจะจับ บั๊กความปลอดภัยต่อหน่วยความจำ ได้ส่วนใหญ่ ถึงอย่างนั้นถ้าจะสร้างอะไรอย่างเว็บเบราว์เซอร์ ผมคงใช้ Rust
    • แม้แต่ C/C++ ก็เขียนโค้ดที่เร็วมากและปลอดภัยมากได้
      ดูได้จากอุตสาหกรรมเกม หรือภาพรวมอุตสาหกรรมในยุคที่ยังต้องเขียนซอฟต์แวร์ลงดิสก์เพื่อแจกจ่าย ปัญหาในตอนนี้คือความซับซ้อนของภาษาสูงขึ้น และระดับทักษะเฉลี่ยของนักพัฒนาซอฟต์แวร์ลดลง การที่ Google สร้าง Go ก็เพื่อแก้ปัญหานี้ในระดับหนึ่ง และ Rust ก็เป็นอีกภาษาที่วางความปลอดภัยต่อหน่วยความจำไว้เป็นแกนหลักของการออกแบบ อีกเหตุผลที่ Rust เอื้อต่อการเขียนโปรแกรมที่ปลอดภัยกว่าคือมันซับซ้อนน้อยกว่า C++ มาก แม้มันจะค่อย ๆ ซับซ้อนขึ้น แต่โชคดีที่ในชุมชน Rust แนวคิดเรื่อง ความปลอดภัยต่อหน่วยความจำ ฝังรากลึก ดังนั้นต่อให้ภาษาซับซ้อนขึ้น ข้อดีนั้นและนิสัยของนักพัฒนาก็จะยังคงอยู่
      Zig ก็เป็นตัวเลือกที่ดีถ้าให้ความสำคัญกับความปลอดภัย มันทำให้หลายอย่างง่ายขึ้นด้วยไวยากรณ์อย่าง defer และมี target กับเครื่องมือหลายแบบเพื่อจับปัญหาความปลอดภัยต่อหน่วยความจำระหว่างการพัฒนา ไม่ใช่สิ่งที่คอมไพเลอร์บังคับ แต่เป็นการจับตอนรันไทม์ในบิลด์สำหรับพัฒนา/ที่ไม่ใช่ ReleaseFast ถึงอย่างนั้นก็ยังเป็นการปรับปรุงจาก C/C++
    • ผมไม่แน่ใจนักกับการตีตรา Zig ทั้งหมดว่า “ไม่ปลอดภัยต่อหน่วยความจำ”
      มันมี เครื่องมือและการตรวจสอบด้านความปลอดภัยต่อหน่วยความจำ ที่ค่อนข้างหลากหลาย ซึ่ง C ไม่มี ความปลอดภัยเป็นสเปกตรัม C ปลอดภัยน้อยกว่า C++, C++ ปลอดภัยน้อยกว่า Zig, Zig ปลอดภัยน้อยกว่า Rust, Rust ปลอดภัยน้อยกว่า Java และ Java ปลอดภัยน้อยกว่า Python พฤติกรรมที่ไม่กำหนดและความเสียหายของหน่วยความจำยังเป็นไปได้ในทุกภาษา ความต่างอยู่ที่มันเกิดขึ้นได้ง่ายแค่ไหน
    • ผมมองว่าการขาดความปลอดภัยต่อหน่วยความจำทำให้จุดเด่นของ Zig อ่อนลงบางส่วน
      แต่ Zig ยังไม่ใช่ภาษาที่เสร็จสมบูรณ์ จึงยากจะฟันธงในตอนนี้ Zig ก็มีฟีเจอร์ความปลอดภัยต่อหน่วยความจำที่ดีอยู่ และแม้จะไม่ถึงระดับ JavaScript หรือ Rust แต่ก็ไม่เหมือน C ตอนที่เคยตรวจดู ปัญหาใหญ่คือ use-after-free และถ้าแก้เรื่องนี้ไม่ได้ ผมมองว่า Zig ก็ไม่มีอนาคต
      JavaScript เป็นภาษาที่ปลอดภัยต่อหน่วยความจำจริง ๆ แต่รันไทม์และระดับ abstraction ไม่เหมาะกับ system programming ผมคิดว่าสำหรับ system programming ควรมีความปลอดภัยต่อหน่วยความจำเป็นค่าเริ่มต้นแต่มีทางออก และต้องมี abstraction ระดับต่ำที่สูงกว่า virtual PDP-11 ซึ่งคอมไพเลอร์กับ CPU โดยทั่วไปมุ่งเป้ามาแค่ประมาณหนึ่งขั้น ให้โปรแกรมเมอร์คิดสอดคล้องกับโมเดลการทำงานของ CPU ได้โดยไม่จมกับรายละเอียด และต้องทำงานร่วมกับ C ได้ดีมาก
      Rust ทำข้อแรกได้ดี จุดอ่อนคือข้อที่สอง มันมีฟีเจอร์ระดับต่ำ แต่ถูกฝังอยู่ใต้กองความซับซ้อนของฟีเจอร์ภาษา อีกทั้งยังไม่อนุญาตรูปแบบการจัดการหน่วยความจำบางอย่างที่ปลอดภัยโดยสมบูรณ์ ทำให้ต้องใช้ unsafe บ่อยเกินไป หรือบิดโค้ดให้เข้ากับพื้นที่ของคำตอบแทนที่จะเข้ากับโดเมนปัญหา
      Zig อ่อนในข้อแรก มันมีฟีเจอร์ดี ๆ อยู่ แต่ก็มีช่องโหว่ใหญ่ ขณะที่ข้อที่สองค่อนข้างแข็งแรง สิ่งที่อยากเห็นคือ Zig ให้ความปลอดภัยต่อหน่วยความจำพื้นฐาน แต่ให้ได้อย่างยืดหยุ่นกว่า Rust มาก และยังรักษาจุดแข็งด้าน abstraction ระดับต่ำกับการทำงานร่วมกับ C ไว้

  • หลังเห็นข่าวว่าล่าสุดย้ายมาเป็น self-hosting แล้ว ก็รู้สึกว่าเป็นโครงการที่มีประสิทธิภาพเป็นพิเศษ ไม่น่าจะใช้เงินบริจาคอย่างสูญเปล่า

  • “ที่รัก มีภาษาโปรแกรมมิงภาษาหนึ่งที่ฉันชอบมาก ๆ อยากคุยด้วยหน่อย”
    “หืม?…”
    “ฉันชอบภาษานั้นมาก ๆ เลย อยากบริจาคเงินให้สักหน่อย…”
    “……เอาอีกแล้วสินะ……”

    • หรืออาจกลายเป็นแบบนี้ก็ได้
      “ดีเลย! ขึ้น Cirrus SF50 Vision ของเราไปส่งให้ Andrew Kelley ด้วยตัวเองกันเถอะ”

  • แน่นอนว่าเป็นข่าวดี แต่ถ้าจัดวางมุมมองแล้ว เงินจำนวนนี้ก็ประมาณเงินเดือนของ นักพัฒนามากประสบการณ์ที่ทำงานกับคอมไพเลอร์ ราว 0.75~1 คนเท่านั้น
    เดาเอานะ แต่ Microsoft น่าจะใช้เงินกับ TypeScript อย่างเดียวปีละ 10~20 เท่าของจำนวนนี้ และกับ C++/C# ฯลฯ ก็คงมากกว่านั้นมาก

    • มีนักพัฒนาที่ทำเงินได้มากขนาดนั้นอยู่ และในที่อย่าง Microsoft หรือ Mozilla โอกาสก็ยิ่งสูงกว่า แต่ถ้ามองตลาดทั่วโลกและโปรเจกต์คอมไพเลอร์ขนาดเล็ก ๆ ก็น่าจะมี นักพัฒนาคอมไพเลอร์มากประสบการณ์ จำนวนมากที่ทำรายได้น้อยกว่า 150,000 ดอลลาร์ต่อปี
      แน่นอนว่าต้นทุนนักพัฒนาไม่ได้จบแค่เงินเดือน เพียงแต่ผมรู้สึกว่างานที่คล้ายกับนักพัฒนาคอมไพเลอร์ที่ทำงานกับคอมไพเลอร์มาตรฐาน ANSI ในบริษัทเทคโนโลยีขนาดใหญ่ มีเนื้องานจริงค่อนข้างไม่น่าพิสมัยเมื่อเทียบกับงานที่อิสระกว่า จึงมีส่วนของค่าตอบแทนความเสี่ยงปนอยู่มาก
    • บทบาทในโปรเจกต์ที่ค่อนข้างใหม่และมีศักยภาพสูงแบบนี้ อาจเป็นโอกาสที่ค่อนข้างน่าสนใจสำหรับ คนที่มั่นใจใน Zig อยู่แล้ว
      ถ้ามีเงินทุนที่เหมาะสม ก็จะเป็นตัวเร่งที่ทำให้ไม่ต้องทำงานสองจ๊อบหรือทำได้แค่ตอนกลางคืน/สุดสัปดาห์

  • พูดตรง ๆ ว่า Zig น่าคาดหวังมาก
    มันเพรียวและไร้ส่วนเกิน ไม่ใช่ภาษาที่คนหอคอยงาช้างซึ่งไม่สนใจการใช้งานจริงสร้างขึ้นมา และก็ไม่ได้ออกแบบโดยทีมด็อกเตอร์แบบ Haskell แต่ดูเหมือนได้รับแรงบันดาลใจชัดเจนจากไอเดียที่มีประโยชน์ของ Rust หรือ Haskell เป็นต้น การเขียนโค้ดด้วย Zig น่าจะค่อนข้างน่าสนใจ

    • ผมเองก็คาดหวังกับ Zig ในทำนองเดียวกัน
      การรับประกันความปลอดภัยของหน่วยความจำอาจไม่ได้ครอบคลุมเท่า Rust แต่หวังว่าสักวันจะได้เห็น Zig ใน Linux Kernel โปรแกรมเมอร์ C เคอร์เนลรุ่นเก่าอาจปรับตัวเข้ากับ Zig ได้ง่ายกว่า Rust
    • ผมรู้ว่าถ้าแสดงความเห็นแบบนี้ฝั่ง Zig คงไม่ชอบ แต่ถ้าวันหนึ่งสามารถปิด zig fmt ในที่อย่าง vim หรือ VS Code ได้ ผมก็จะกลับมาฝากความหวังกับ Zig อีกครั้ง
      พอ ความชอบด้านสไตล์ ถูกบังคับ มันทำให้รู้สึกขมขื่น เหมือนเป็นท่าทีที่ไม่เคารพนักพัฒนาที่ใช้ภาษาเป็นเครื่องมือ และอาจเป็นสัญญาณว่ามีปัญหาที่ลึกกว่านั้นเรื่องการมีส่วนร่วมของคอมมูนิตี้และความเปิดกว้างต่อมุมมองอื่น ซึ่งดูเหมือนว่า Zig จะมีปัญหานั้นจริง ๆ[0]
      บริษัทที่ต้องการความสม่ำเสมอของโค้ดก็แค่รันลินเตอร์ก็พอ ส่วนโปรเจกต์สุดสัปดาห์ผมไม่สนใจอะไรนอกจากความชอบด้านสไตล์ของตัวเอง นี่เป็นประเด็นว่า Zig เป็นภาษาสำหรับผู้ใหญ่หรือไม่ ถ้าสุดท้ายจะถูกบังคับให้เขียนโค้ดในวิธีใดวิธีหนึ่งอยู่แล้ว ก็ไม่มีเหตุผลอะไรที่จะไม่ใช้ Rust ซึ่งแถมความปลอดภัยของหน่วยความจำมาให้ฟรี ๆ
      [0] https://github.com/ziglang/zig/issues/16270