บทสัมภาษณ์ Andrew Kelley ผู้สร้าง Zig

 (youtube.com)
2 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Zig มุ่งเป็นภาษาระดับระบบที่คงประสิทธิภาพและการควบคุมแบบ C ไว้ พร้อมลด footgun และจุดอ่อนด้านการดีบัก และยังคงตระหนักถึง CPU และหน่วยความจำโดยตรง
  • จุดแตกต่างหลักคือ toolchain โดยตั้งเป้าให้สามารถสั่งบิลด์ด้วย zig build เพียงคำสั่งเดียวได้ ไม่ว่าจะรันบน OS ใดและจะบิลด์ไปยัง OS ใดก็ตาม โดยไม่พึ่งพาระบบแวดล้อมของระบบปฏิบัติการ
  • การเลื่อนเวอร์ชัน 1.0 เป็นทางเลือกเพื่อไม่ให้สัญญาเรื่อง ความเข้ากันได้ย้อนหลัง เร็วเกินไป และด้วยโครงสร้างองค์กรไม่แสวงหากำไรแบบ 501(c)(3) จึงสามารถโฟกัสกับการปรับปรุงระยะยาวได้
  • Zig Software Foundation มีรายรับ 670,000 ดอลลาร์สหรัฐ ในปี 2024 และมีโครงสร้างผู้สนับสนุนที่หลากหลาย พร้อมย้ายจาก GitHub ไปยัง Codeberg โดยให้ความสำคัญกับการทำงานของ CI เป็นลำดับแรก
  • สำหรับ issue และ pull request มีนโยบาย no LLM, no AI โดยมองว่าการมีส่วนร่วมจาก AI ทำลายเวลาสำหรับการรีวิวและการให้คำแนะนำ จนกลายเป็นคุณค่าติดลบ

จุดเริ่มต้นของ Zig และการออกแบบภาษา

  • ที่มาของการถือกำเนิด

    • Andrew Kelley ลองใช้ JavaScript, Go, Rust และ C++ ตามลำดับเพื่อสร้าง digital audio workstation แต่เห็นว่าแต่ละภาษามีข้อจำกัดในการสร้างประสบการณ์ผู้ใช้แบบที่ต้องการ
    • เขามองว่า JavaScript อยู่ในระดับสูงเกินไปภายในเบราว์เซอร์ จนยากจะใช้ความสามารถของคอมพิวเตอร์ได้อย่างเต็มที่
    • Go มีปัญหาเรื่องการทำงานร่วมกับไลบรารี C และสำหรับงานเรียลไทม์อย่างเสียงที่ต้องประมวลผลให้เสร็จภายในเวลาที่กำหนด garbage collector อาจทำให้เกิด glitch หรือ skip ได้ จึงไม่เหมาะสม
    • Rust ในช่วงก่อน 1.0 นั้นทำให้ผ่านกฎต่าง ๆ ได้ยาก แม้เปลี่ยนเล็กน้อยก็อาจทำให้เกิดข้อผิดพลาดตอนคอมไพล์ต่อเนื่องกัน และหลังจากใช้เวลาหนึ่งเดือนปรับการเรนเดอร์ฟอนต์ให้ถูกต้องแล้ว ก็ยังรู้สึกว่าเดินหน้าต่อได้ยาก
    • C++ แม้ช่วงแรกจะมีประสิทธิผล แต่การพิมพ์ผิดหรือความผิดพลาดเล็กน้อยอาจนำไปสู่บั๊กหน่วยความจำเสียหายที่ต้องดีบักเป็นสัปดาห์ และแม้จะใช้ “C-style C++” ที่อาศัย C++ compiler กับ C linker ปัญหา footgun ก็ยังคงอยู่
    • จุดตั้งต้นของ Zig คือมุมมองที่ว่าจะไม่ประนีประนอมกับประสบการณ์ผู้ใช้โดยยึดตาม สิ่งที่คอมพิวเตอร์สามารถทำได้โดยพื้นฐาน ไม่ใช่ตามขอบเขตที่ toolchain อนุญาต

  • เหตุผลที่มองว่าสามารถมาแทน C ได้

    • มองว่า Zig ดีกว่า C เพราะไม่ต้องทิ้งพลังของ C แต่ปรับปรุงข้อบกพร่องและจุดอ่อนของ C
    • ความพยายามอื่นในการแทน C มักต้องยอมทิ้งบางอย่างที่ C มี แต่ Zig ทำทุกอย่างที่ C ทำได้ พร้อมลด footgun และเพิ่มความสามารถในการดีบัก
    • ใน C นั้น signed integer มีเพียง integer แบบเพื่อการ optimize และ unsigned integer มีเพียงความหมายแบบ wraparound แต่ Zig ให้เลือกได้ทั้ง signed/unsigned ว่าจะใช้ wraparound หรือรับประกันว่าไม่มี overflow จึงถูกอธิบายว่า “เป็น C ยิ่งกว่า C”
    • หากจะมาแทน C ได้ ก็ต้องเขียนโค้ดที่นำกลับมาใช้ซ้ำได้ในทุกที่ ไม่ว่าจะเป็นเคอร์เนลระบบปฏิบัติการ อุปกรณ์ embedded วิดีโอเกม หรือ WebAssembly และเมื่อ Zig ให้ความสามารถและความเสถียรระดับ C ได้ ผู้คนก็ย่อมเลือกสิ่งที่มีประสิทธิภาพดีกว่าและบั๊กน้อยกว่า

  • ความต่างจาก Rust

    • ความแตกต่างหลักระหว่าง Rust กับ Zig คือ ระบบชนิดข้อมูล
    • Rust ต้องอธิบายกฎต่าง ๆ ด้วย meta-language เช่น พารามิเตอร์ของฟังก์ชันรองรับ clone หรือไม่ รองรับอินเทอร์เฟซใด และส่งชนิดข้อมูลแบบใดได้บ้าง
    • Zig ไม่มีอุปกรณ์แบบนั้น แต่ส่ง concrete type โดยตรง หรือส่ง generic type ที่ทำงานคล้าย C++ template
    • มี trade-off ที่ว่าโค้ด Rust มีการรับประกันจากระบบชนิดข้อมูลมากกว่า ขณะที่โค้ด Zig มีความเรียบง่ายในการอ่านมากกว่า
    • Rust เดินต่อจากสไตล์ RAII แบบใกล้เคียง C++ โดยธรรมชาติจะไปในทิศทางที่ออบเจ็กต์อ้างอิงออบเจ็กต์อื่น และเมื่อจำนวนการอ้างอิงเป็น 0 ก็ถูกรื้อทำลายโดยอัตโนมัติ
    • Zig ทำให้ allocator มีความชัดเจนมากกว่ามาก แม้จะทำ reference counting ได้ แต่ก็ต้องเขียนโค้ดส่วนนั้นอย่างชัดเจน
    • ใน Zig มักใช้วิธีจัดสรรหน่วยความจำที่ออกแบบให้เหมาะกับแอปพลิเคชัน เช่น ใช้ arena allocator เพื่อรวมการจัดสรรแล้วทิ้งทั้งหมดพร้อมกัน ใช้ general-purpose allocator กับแนวทางเชิงวัตถุ หรือสร้างแนวทางผสมสำหรับงานเฉพาะ
    • วิธีเขียนโค้ดโดยคิดว่าอยากให้ CPU ทำอะไรแล้วทำให้มันทำตามนั้นตรง ๆ เป็นสิ่งที่มองว่าเป็นธรรมชาติกว่าใน Zig เมื่อเทียบกับ Rust

  • ฟีเจอร์เด็ดและ toolchain

    • ฟีเจอร์เด็ดของ Zig คือ toolchain
    • มันเป็นชุดซอฟต์แวร์ที่ไม่ขึ้นกับระบบ โดยทำงานได้ไม่ว่าจะรันบนระบบปฏิบัติการใด และสามารถบิลด์โค้ดไปยังระบบปฏิบัติการใดก็ได้
    • ระดับความยากในการ hack โปรเจ็กต์ดูได้จากว่าใน README ต้องติดตั้ง system package จำนวนมากหรือไม่ ขั้นตอนต่างกันตามระบบปฏิบัติการหรือไม่ ต้องรันคำสั่งหลายคำสั่งเพื่อจัดสภาพแวดล้อมหรือไม่ และต้องใช้ Docker หรือฮาร์ดแวร์เฉพาะหรือไม่
    • เกณฑ์ที่ดีที่สุดคือ หนึ่งบรรทัด, หนึ่ง dependency, ใช้ได้เสมอสำหรับทุกคน และขั้นตอนการบิลด์ใน README ของโปรเจ็กต์ Zig ควรมีเพียง zig build ก็พอ

  • กฎของภาษาและอินเทอร์เฟซ IO

    • กฎที่มองตัวแปรที่ไม่ได้ใช้เป็นข้อผิดพลาดตอนคอมไพล์ช่วยจับบั๊กระหว่างการรีแฟกเตอร์ขนาดใหญ่และประหยัดเวลาได้ และต้นทุนของการเพิ่มคอมเมนต์เพื่อทิ้งตัวแปรก็ไม่สูง
    • ด้วยการรองรับจากทีม ZLS ในเอดิเตอร์ หากเปิดการตั้งค่าไว้ก็สามารถ discard ตัวแปรที่ไม่ได้ใช้อัตโนมัติได้ และถ้ากลับมาใช้อีกก็สามารถลบ discard ออกได้
    • อินเทอร์เฟซ IO reader / IO writer ใหม่เป็น abstraction สำหรับการเขียนโค้ดที่นำกลับมาใช้ซ้ำได้เพียงครั้งเดียว เช่น ไลบรารีโหลดภาพหรือโค้ดซีเรียลไลซ์ data format
    • เป้าหมายคือแยกเป็นแพ็กเกจโดยรับ reader สำหรับข้อมูลที่อ่านเข้า และ writer สำหรับข้อมูลที่ส่งออก เพื่อให้หลายแอปพลิเคชันใช้ logic เดียวกันได้
    • หากการอ่านและเขียนเกิดขึ้นใต้ abstraction layer คอมไพเลอร์อาจเข้าใจ logic ได้ยากขึ้นและทำ optimization ได้ไม่ดี จนสูญเสียประสิทธิภาพ
    • มองว่าการออกแบบที่รวม buffer ไว้ภายในอินเทอร์เฟซเป็นจุดสมดุลที่ดีที่สุด ซึ่งทำให้คอมไพเลอร์สร้างโค้ดที่ดีได้พร้อมกับบรรลุการนำกลับมาใช้ซ้ำ

กรณีการใช้งาน, 1.0, และทิศทางหลัง LLVM

  • กรณีการใช้งานจริง

    • Zig ถูกนำเสนอว่าเป็นภาษาที่ใช้เมื่อคุณต้องการควบคุมคอมพิวเตอร์ได้อย่างสมบูรณ์ ดึงประสิทธิภาพและการใช้หน่วยความจำออกมาให้ได้มากที่สุด และสร้างประสบการณ์ผู้ใช้ที่น่าสนใจ
    • Ghostty เป็นเทอร์มินัลอีมูเลเตอร์ที่สร้างโดย Mitchell Hashimoto และถูกประเมินว่าเป็นโปรเจ็กต์ที่ดีในด้านคุณภาพโค้ด การดูแลชุมชน และการทดสอบแบบ fuzz
    • TigerBeetle เป็นฐานข้อมูลธุรกรรมทางการเงิน โดยเลือกสร้างฐานข้อมูลเฉพาะทาง แทนกลยุทธ์แบบนำ OLTP ไปวางบนฐานข้อมูลเชิงสัมพันธ์อย่าง PostgreSQL และถูกอธิบายว่า “เร็วกว่าเป็นพันเท่า” เมื่อเทียบกับแนวทางนั้น
    • TigerBeetle จัดสรรหน่วยความจำทั้งหมดที่จะใช้ล่วงหน้าตั้งแต่เริ่มรัน แล้วไม่ทำ dynamic allocation อีก จึงคงค่า latency ให้คาดการณ์ได้และสม่ำเสมอ
    • Bun เป็น JavaScript engine ที่ใช้ JavaScriptCore และไลบรารี C++ หลายตัว โดยโค้ดส่วนเชื่อมต่อเขียนด้วย Zig
    • เข้าใจว่า Bun เพิ่งถูกขายให้ Anthropic เมื่อไม่นานมานี้ และมองว่าผลจากเรื่องนี้ทำให้มีคนจำนวนมากขึ้นที่อยากใช้ Zig สำหรับงาน AI
    • Uber ใช้ Zigcc เป็น C compiler เพื่อ cross-compile โค้ด C ที่โค้ด Go พึ่งพาอยู่ไปพร้อมกัน และนำไปใช้กับการบิลด์สำหรับ ARM64

  • เหตุผลที่ 1.0 ล่าช้า

    • แม้ Zig จะผ่านมากว่า 10 ปีแล้วยังไม่มี 1.0 แต่ก็มองว่า 1.0 โดยเนื้อแท้คือ คำสัญญาเรื่องความเข้ากันได้ย้อนหลัง และมีความหมายต่างกันไปในแต่ละโปรเจ็กต์
    • มีการเปรียบเทียบว่า Go แทบไม่แตะตัวภาษาอยู่นานหลัง 1.0 ส่วน Rust ติดป้าย 1.0 ค่อนข้างเร็ว แต่ก็ยังเปลี่ยนภาษาได้มากพอสมควรผ่าน edition โดยยังรักษาความเข้ากันได้ย้อนหลังไว้
    • Zig Software Foundation ไม่ใช่สตาร์ตอัป แต่เป็นองค์กรไม่แสวงหากำไรแบบ 501(c)(3) จึงไม่มีแรงกดดันจากนักลงทุน ไม่มีแผนขายกิจการหรือ exit และมีเวลาปรับปรุงในระยะยาว
    • เมื่อติดป้าย 1.0 ก็อยากให้มันเป็น “ผลลัพธ์ของความใส่ใจที่ไม่ประนีประนอม” โดยไม่ติดอยู่กับการตัดสินใจที่แย่ซึ่งรีบล็อกไว้เร็วเกินไป
    • สำหรับ “worse is better” มองว่าแค่ถ้อยคำก็ไม่สมเหตุสมผลในเชิงภาษา และ Zig มุ่งไปที่ more with less
    • ตั้งเป้าทำให้ฟีเจอร์ comptime ที่มีความซับซ้อนไม่มาก สร้างประโยชน์ได้สูง และสร้าง toolchain ที่สามารถคอมไพล์ไปยังระบบปฏิบัติการและสถาปัตยกรรมที่ต่างกันโดยสิ้นเชิงได้ด้วยแฟล็กเดียว
    • แม้จะเชื่อแน่ว่าการยอมรับจะพุ่งขึ้นมากเมื่อ 1.0 ออกมา แต่เป้าหมายคือการสร้างภาษาสำหรับอีก 50 ปีข้างหน้า
    • มองว่าในการออก 0.16 รุ่นถัดไป จะเริ่มเห็นผลลัพธ์ของการตัดสินใจเหล่านี้

  • เหตุผลที่ถอยออกจาก LLVM

    • เหตุผลที่ถอยออกจาก LLVM คือการตัดสินว่าควรหลีกเลี่ยงการมี dependency สำคัญต่อผลิตภัณฑ์หลัก
    • ยกตัวอย่างเกมอาร์เคดแข่งขัน 10 คน Killer Queen ที่นักพัฒนาใช้ Unity สำหรับฟิสิกส์เอนจิน จนกระทั่งการเปลี่ยนแปลงเล็กน้อยหรือการแก้บั๊กในฟิสิกส์เอนจินก็ทำให้ความรู้สึกของการเล่นแบบแข่งขันเปลี่ยนไป ส่งผลให้ไม่สามารถอัปเดตไปใช้ Unity เวอร์ชันใหม่ได้
    • มองว่าการมี dependency กับผลิตภัณฑ์หลักเป็นความผิดพลาด และสำหรับ Zig ก็เห็นว่านี่คือกระบวนการแก้ไขเรื่องนี้ในส่วนที่เกี่ยวกับ LLVM
    • LLVM ถูกเปรียบเหมือน “ล้อช่วยพยุงจักรยาน” และหลังจากสร้าง Zig มานานกว่า 10 ปี ก็ได้เรียนรู้เรื่องการพัฒนาคอมไพเลอร์มากขึ้นจนมองว่าตอนนี้ถอดล้อช่วยพยุงออกและแข่งขันกับ LLVM ได้แล้ว
    • ใน x86 backend ของตัวเอง สามารถทำ incremental compilation ได้ แม้กับ codebase ขนาดใหญ่ระดับล้านบรรทัด โดยหลังแก้ไขแล้วได้ไบนารีใหม่ในเวลา ต่ำกว่า 50ms

  • ชื่อและเส้นทางการเรียนรู้

    • ชื่อ Zig มาจากการมองหาคำสั้น ๆ ที่เมื่อค้นหา “Zig programming language” แล้วจะไม่มีผลลัพธ์เลย และได้ชื่อนี้ระหว่างใช้สคริปต์ Python พิมพ์คำสุ่มออกมา
    • มาสคอตอีกัวนาถูกเรียกว่า “ziguana”
    • สำหรับผู้เริ่มต้น แนะนำ Ziglings อย่างมาก
    • Ziglings ประกอบด้วยแบบฝึกหัดชุดหนึ่งที่มีโค้ดซึ่งเกือบทำงานได้แต่แทรกปัญหาไว้ และให้เรียนรู้ฟีเจอร์ใหม่ของภาษาผ่านการแก้โปรแกรมที่พัง
    • การย้ายจาก C ไป Zig นั้นราบรื่นเป็นพิเศษ และทุกอย่างที่ทำได้ใน C ก็ทำได้ใน Zig เช่นกัน แต่มี footgun น้อยกว่า
    • หากเกิด segmentation fault ใน C โดยทั่วไปมักจะไม่มีข้อความอะไรนอกจาก “segmentation fault” และต้องพึ่งความสามารถในการใช้ดีบักเกอร์ แต่ใน Zig คุณจะได้รับ stack trace แบบเต็มที่ชี้ไปยังแต่ละบรรทัดของโค้ด
    • การจะเรียน Zig เป็นภาษาโปรแกรมภาษาแรกหรือไม่นั้นขึ้นอยู่กับแต่ละคน แต่สำหรับคนที่อยากเรียนรู้ว่าคอมพิวเตอร์ทำงานอย่างไร ก็ถือเป็นภาษาที่ดีเพราะช่วยให้ได้เรียนรู้ทั้ง CPU และหน่วยความจำ

การดำเนินงานของมูลนิธิ การกำกับดูแล และการเลือกแพลตฟอร์ม

  • โครงสร้างการเงินและผู้สนับสนุน

    • รายได้รวมของ Zig Software Foundation ในปี 2024 อยู่ที่ 670,000 ดอลลาร์
    • แหล่งรายได้มีความหลากหลาย ทั้งจากผู้สนับสนุนรายบุคคลและเงินบริจาคจากหลายบริษัท จึงเป็นโครงสร้างที่ไม่มีฝ่ายใดฝ่ายหนึ่งสามารถบังคับทิศทางการพัฒนาได้
    • หากผู้สนับสนุนบางรายเรียกร้องว่า “ให้ทำสิ่งนี้” ก็สามารถปฏิเสธได้ และแม้ผู้สนับสนุนคนนั้นจะหยุดให้เงิน ก็ยังมองว่าสามารถอยู่รอดได้
    • ผู้สนับสนุนสามารถมีอิทธิพลได้เพียงในแบบเดียวกับคนอื่น ๆ เช่น การเข้าร่วม bug tracker การส่ง pull request และการพูดคุยในช่องทางพัฒนา โดยไม่มีช่องลับพิเศษที่ให้ลำดับความสำคัญสูง
    • เงินเดือนประจำปีของ Andrew Kelley อยู่ที่ 154,000 ดอลลาร์ โดยระบุว่าคณะกรรมการชุดแรกกำหนดจากเงินเดือนมัธยฐานของวิศวกรซอฟต์แวร์อาวุโสในเมืองที่ก่อตั้งองค์กรไม่แสวงหากำไรนี้
    • มูลนิธิมีพนักงาน 1 คน และผู้รับจ้างที่ได้รับค่าตอบแทนแบบเต็มเวลาประมาณ 5 คน โดย 91% ของรายได้ปีก่อนถูกจ่ายให้ผู้รับจ้างที่ทำงานในโครงการ
    • หากมีข้อเสนอให้เงินแบบไม่มีเงื่อนไข 100 ล้านดอลลาร์ ก็จะรับได้ แต่จะไม่นำไปใช้เพื่อขยายตัว และจะนำไปฝากธนาคารเพื่อให้ไม่ต้องระดมทุนอีกเป็นเวลา 100 ปี
    • ปัจจุบันเขากำลังบริหารทีม 5 คน และระบุว่าหากเกิน 10 คนภาระอาจมากเกินไป และไม่ได้คิดจะเป็นผู้จัดการขององค์กรขนาด 100 คน

  • 501(c)(3) และความโปร่งใส

    • มีการแยกให้ชัดว่า 501(c)(3) แตกต่างจาก 501(c)(6)
    • 501(c)(6) คือ business league โดยยก Rust Foundation เป็นตัวอย่างของรูปแบบที่บริษัทอย่าง Amazon, Netflix, Microsoft และ Meta บริจาคเพราะมีผลประโยชน์ร่วมกันในความสำเร็จของ Rust
    • 501(c)(3) ไม่อนุญาตให้วิ่งเต้นทางการเมืองของรัฐบาล และมีอยู่เพื่อพันธกิจตามคำประกาศภารกิจเท่านั้น ไม่ใช่เพื่อผลประโยชน์ของผู้ประกอบการ
    • บทความบล็อกที่เปิดเผยรายรับและรายจ่ายอย่างละเอียดไม่ใช่ข้อบังคับ แต่เป็นความโปร่งใสโดยสมัครใจ และมองว่าช่วยทั้งเรื่องความน่าเชื่อถือและการระดมทุน เพราะตัวชี้วัดต่าง ๆ ออกมาดี

  • เหตุผลที่ออกจาก GitHub และโซเชียลมีเดีย

    • เหตุผลที่ออกจาก Reddit และ Twitter คือการโพสต์บนเว็บไซต์เหล่านั้นยิ่งมีความเกี่ยวข้องน้อยลงเรื่อย ๆ เหมือนการโพสต์บน Slashdot หรือ Digg และต้องการใช้เวลากับการตลาดให้น้อยที่สุดในฐานะวิศวกรซอฟต์แวร์
    • มองว่าการโฟกัสกับงานอีเวนต์แบบพบหน้ากันและ meetup เป็นการลงทุนที่ดีกว่าสำหรับการเติบโตของชุมชน มากกว่าโซเชียลมีเดียที่อัลกอริทึมควบคุมสิ่งที่มองเห็นหรือบังคับให้ต้องปฏิสัมพันธ์กับพวก troll
    • เหตุผลที่ย้ายที่เก็บหลักของ Zig จาก GitHub ไปยัง Codeberg ในช่วงปลายปี 2025 คือ GitHub ไม่สามารถให้ผลลัพธ์จาก continuous integration ได้อย่างถูกต้องอีกต่อไป หรือพูดง่าย ๆ คือ “มันใช้งานไม่ได้”
    • หลังย้ายไป Codeberg แล้ว เซิร์ฟเวอร์ continuous integration ก็กลับมาทำงานได้อีกครั้ง
    • การออกจาก GitHub Sponsors เป็นการตัดสินใจที่ยาก เพราะอาจสูญเสียแหล่งรายได้ แต่ตัดสินใจว่าหากจะเขียนซอฟต์แวร์ สิ่งสำคัญสูงสุดคือ CI ต้องทำงานได้
    • หลังออกจาก GitHub แล้ว เขาระบุว่าสถานะการเงิน “ไม่มีปัญหาเลย”
    • Zig เป็นซอฟต์แวร์ภายใต้ไลเซนส์ MIT และมองว่าเป็นการบริจาคแบบไม่มีเงื่อนไขให้กับโลกของซอฟต์แวร์ ขณะที่การสนับสนุนก็เป็นการบริจาคแบบไม่มีเงื่อนไขเช่นกัน
    • เหตุผลที่เลือก Codeberg คือโดยเนื้อแท้แล้วคล้ายกับ GitHub จึงย้ายได้ง่าย และเป็น องค์กรไม่แสวงหากำไรของเยอรมนี
    • มองว่า code forge ไม่ใช่เครื่องมือการตลาดของโครงการ และผู้คนไม่ได้ค้นพบภาษาจาก GitHub หรือ Codeberg แต่จากประกาศต่าง ๆ, meetup, วิดีโอ YouTube และกลุ่ม meetup อย่าง Zigday

  • BDFL และการกำกับดูแลระยะยาว

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

  • เกณฑ์ความสำเร็จ

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

นโยบาย AI, เครื่องมือพัฒนา, และอนาคตของการเขียนโปรแกรม

  • นโยบาย no LLM, no AI contribution

    • Zig มีนโยบาย no LLM, no AI ที่เข้มงวดสำหรับ issue และ pull request
    • เขามองว่าการมีส่วนร่วมจาก AI “ยังคงเป็นขยะเหมือนเดิม” และไม่เพียงไม่มีคุณค่า แต่ยังสร้างคุณค่าติดลบเพราะแย่งเวลาในการรีวิว
    • ปัจจุบันมี pull request ที่เปิดอยู่มากกว่า 200 รายการ และเวลาในการรีวิวคือคอขวดระหว่างทีมพัฒนาขนาดเล็กกับผู้มีส่วนร่วมจำนวนมาก
    • เขามองว่าการมีส่วนร่วมที่สร้างด้วย AI มักเผยรูปแบบเดิม ๆ คือหลังรีวิวไปไม่กี่รอบ ผู้มีส่วนร่วมกลับไม่เข้าใจเนื้อหานั้นเอง แล้วนำ feedback จากการรีวิวไปแปะในแชต ก่อนจะเอาคำตอบที่ได้กลับมาขัดเกลาให้ดูเหมือนเป็นคำพูดของตัวเอง
    • เหตุผลหลักของการทำ code review และการรับ contribution คือการเป็นพี่เลี้ยง โดยมีเป้าหมายเพื่อช่วยให้ผู้มีส่วนร่วมเติบโตจนภายหลังกลายเป็นสมาชิกทีมหลักหรือเป็นผู้มีส่วนร่วมที่มีคุณค่ามากขึ้น
    • “contributor poker” คือกระบวนการตัดสินใจว่าจะลงทุนเวลากับใคร เพื่อทำให้เขากลายเป็นโปรแกรมเมอร์และผู้มีส่วนร่วมที่ดีขึ้นภายใต้เวลาที่จำกัด
    • เขามองว่าคนที่ใช้ AI จะอยู่ในกลุ่มผู้มีส่วนร่วมแบบครั้งเดียวที่ไม่น่าลงทุนเวลาด้วยเสมอ เพราะไม่ได้เรียนรู้และแทบไม่มีโอกาสกลายเป็นสมาชิกทีมหลัก
    • โปรเจกต์ Zig เป็นโปรเจกต์ด้านการศึกษาด้วยเช่นกัน และการให้คำแนะนำกับนักเรียนรวมถึงการสอนถือเป็นส่วนหนึ่งของภารกิจ
    • หากจะ “อนุญาตเฉพาะ AI PR ที่ดี” ก็ต้องมีคนมาตัดสิน แต่การแบนทั้งหมดเป็นนโยบายที่บังคับใช้ได้ง่ายกว่า
    • เขายอมรับว่าการตรวจจับว่าเนื้อหาถูกสร้างโดย AI หรือไม่นั้นไม่ง่ายเสมอไป และอาจมีบางส่วนเล็ดลอดเข้ามาได้ แต่เมื่อรีวิว pull request จำนวนมาก ก็มีหลายกรณีที่ชัดเจนขึ้นจากการตอบสนองต่อ feedback ซึ่งไม่ใช่พฤติกรรมแบบที่มนุษย์แสดงออก

  • ไลเซนส์ MIT และการฝึก AI

    • โค้ดเบสของ Zig ใช้ไลเซนส์ MIT และสำหรับคนที่ไม่คุ้นกับไลเซนส์ซอฟต์แวร์ มันแทบจะใกล้เคียงกับ public domain
    • สามารถนำไปใช้ได้เกือบทุกวัตถุประสงค์ ต้องคงข้อความไลเซนส์ไว้เมื่อคัดลอกโค้ด ไม่มีการรับประกัน และไม่สามารถเรียกร้องความรับผิดชอบจากฝั่ง Zig ต่อปัญหาที่เกิดขึ้นได้
    • เป็นเรื่องชวนย้อนแย้งที่บริษัทใหญ่สามารถนำโค้ด Zig ไปใช้ฝึก AI ได้ แต่กลับห้ามไม่ให้ AI มามีส่วนร่วมกับ Zig
    • เขายึดมั่นอย่างชัดเจนว่า Zig คือของขวัญที่มอบให้โลกโดยไม่มีเงื่อนไข จึงมองว่าไม่เป็นไรหากถูกนำไปใช้ฝึก AI
    • เขาไม่ได้ลองมากพอด้วยตัวเองว่า LLM จะลำบากกับโค้ด Zig มากกว่า Python หรือ JavaScript หรือไม่ แต่ Mitchell Hashimoto บอกว่าใช้ AI coding อย่างกว้างขวางใน Ghostty
    • มีคนที่ใช้ชื่อบนหน้าจอว่า Rocker ซึ่งสร้างเครื่องมือให้ AI ทำงานกับ Zig ได้ดีขึ้น และบอกว่าประสบความสำเร็จ

  • vibe coding และอนาคตของการเขียนโปรแกรม

    • การทำโปรเจกต์ระยะยาว เรียนรู้ทักษะ และอ่านเรื่องการแก้ปัญหาที่เกิดขึ้นระหว่างทาง เป็นสิ่งที่กระตุ้นจินตนาการ ทำให้คิดได้ว่าตัวเองจะสร้างอะไรได้บ้าง และทั้งสอนอะไรบางอย่างรวมถึงสร้างความเชื่อมโยงทางอารมณ์
    • เขามองว่าบล็อกแนวvibe coding ที่เล่าว่า “ลองใช้ Claude เวอร์ชันนี้หรือ OpenAI เวอร์ชันนั้นแล้วมันทำได้ดีอย่างน่าทึ่ง” ไม่ได้สร้างแรงบันดาลใจ
    • เขาเน้นว่ามาตรฐานคุณภาพซอฟต์แวร์ไม่ควรเป็นแค่ “น่าทึ่งที่ไม่มีบั๊ก” แต่ควรเป็นความสมบูรณ์แบบแบบไม่ประนีประนอม
    • เขาเคยลอง vibe coding ในการคุยส่วนตัวกับ Richard Feldman และมองว่าเทคโนโลยีนี้น่าสนใจอย่างเป็นพื้นฐาน
    • แต่ในขณะเดียวกันก็รู้สึกต่อต้านอย่างมากต่อการที่มีบริษัทราวสี่แห่งควบคุมมันจากศูนย์กลาง และมีอำนาจควบคุมโมเดลกับพฤติกรรมของมันอย่างสมบูรณ์
    • เขาบอกว่าไม่ต้องการเปลี่ยนจากการเขียนโค้ดด้วยคอมพิวเตอร์และไฟฟ้าของตัวเอง ไปสู่การใช้การเขียนโปรแกรมแบบปิดซอร์สบนคอมพิวเตอร์ของคนอื่นผ่านเครือข่ายโดยจ่ายค่าสมาชิกรายเดือน
    • เขาบอกว่ามีบางคนจ่ายถึงเดือนละ300 ดอลลาร์ และมองว่าข้อเสนอแบบนี้สำหรับตัวเองนั้นบ้าสิ้นดี
    • เขามองว่าอีก 10 ปีหรือ 20 ปีข้างหน้า มนุษย์ก็จะยังเขียนโค้ดต่อไป และการเขียนโค้ดยังสนุก รวมถึงอย่างน้อยก็จะคงอยู่ในฐานะงานอดิเรกเสมอ
    • เขามองว่าแอปที่ดีที่สุดบนมือถือและคอมพิวเตอร์คือแอปที่คนสร้างขึ้นเป็นงานอดิเรกในเวลาว่าง และความต้องการเสรีภาพ ซอฟต์แวร์เสรี/โอเพนซอร์ส รวมถึงการเป็นเจ้าของอุปกรณ์ของตัวเองจะไม่หายไปไหน

  • สภาพแวดล้อมการแก้ไขและเครื่องมือรีแฟกเตอร์

    • จำเป็นต้องมีสภาพแวดล้อมการทำงานที่ยืดหยุ่นและทนทานซึ่งยังคงแก้ไขโค้ดได้ต่อให้ไวยากรณ์ของ Zig เปลี่ยนไป
    • เครื่องมือขั้นสูงอย่าง tree-sitter และ language server มักตั้งอยู่บนสมมติฐานว่าต้องมี syntax tree หรือภาษาที่เสถียร ดังนั้นถ้าภาษาเสีย เครื่องมือเหล่านี้ก็อาจพังตามไปด้วย
    • โดยส่วนตัวเวลาเขียน Zig เขาใช้เทอร์มินัลกับ Vim มากกว่าสภาพแวดล้อมที่ซับซ้อน และ Vim ก็ทนต่อการเปลี่ยนแปลงได้ดีมาก
    • ZLS ย่อมาจาก Zig language server เป็น implementation ของ Language Server Protocol สำหรับ Zig และเป็นโปรเจกต์ภายนอกที่ไม่ได้ดำเนินการโดย Zig Software Foundation
    • แม้เว็บไซต์ Zig จะแนะนำผลิตภัณฑ์ของ JetBrains แต่ Andrew Kelley ไม่เคยใช้ เพราะผลิตภัณฑ์ของ JetBrains เป็นซอร์สปิด
    • เขามองว่าเครื่องมือรีแฟกเตอร์ระดับสูงในอดีตจาก JetBrains หรือ Eclipse อย่างการ extract function, การจัดเรียงพารามิเตอร์ของฟังก์ชันใหม่, หรือการ rename ชื่อแบบทั้งระบบนั้นเป็นสิ่งที่ดี
    • ในระยะยาว เขาต้องการเครื่องมือรีแฟกเตอร์คล้ายภาษา queryที่สามารถทำการเปลี่ยนแปลงขนาดใหญ่โดยอาศัยข้อมูลชนิดและเบาะแสอื่น ๆ
    • สำหรับงานที่ขอบเขตชัดเจนอย่างการเปลี่ยนชื่อตัวแปร หากมีเครื่องมือที่เชื่อถือได้จัดการ ก็สามารถมั่นใจผลลัพธ์ได้ 100% มากพอที่จะสร้าง commit โดยไม่ต้องรีวิว
    • แต่ถ้าขอให้เครื่องมือ AI ทำงานเดียวกัน ก็ยังต้องกลับมาตรวจโค้ดอยู่ดี จึงใช้เวลานานกว่าและเป็นตัวเลือกที่แย่กว่าเครื่องมือรีแฟกเตอร์ที่เชื่อถือได้

แรงจูงใจส่วนตัวและมุมมองต่อโอเพนซอร์ส

  • แรงจูงใจและความยากลำบากในการทำ Zig ต่อไป

    • แรงผลักดันในการทำ Zig มาจากความรักที่มีต่อคอมพิวเตอร์ และความต้องการทำให้คอมพิวเตอร์รับใช้ผู้คน
    • Zig ถูกอธิบายว่าเป็น ของขวัญในแง่ดี ที่เชื่อว่าภาษาโปรแกรมและทูลเชนที่ยอดเยี่ยมจะนำไปสู่ผลลัพธ์เช่นนั้น
    • การทำให้ผู้ใช้พึงพอใจและสร้างประสบการณ์ผู้ใช้ที่ทรงพลังให้ความอิ่มเอมอย่างมาก และเปรียบความรู้สึกของการสร้างซอฟต์แวร์ที่ดีกับความรู้สึกที่นักดนตรีได้รับเมื่อแสดงบนเวที
    • ส่วนที่ยากที่สุดถูกยกให้เป็นเรื่อง ภาษีและงานเอกสาร ที่จำเป็นต่อการดำเนินองค์กรไม่แสวงหากำไร
    • แม้จะเป็นสิ่งจำเป็นเพื่อให้ดำเนินงานได้อย่างถูกต้องตามกฎหมายและรับเงินบริจาคก้อนใหญ่ได้ แต่ตอนนี้ Andrew Kelley เป็นผู้รับผิดชอบงานนั้นเอง
    • บางวันเขาทำงานบัญชี บางวันเขาเขียนโปรแกรม และเขามองว่าวันที่ได้เขียนโปรแกรมคือวันที่ดี
    • การเปลี่ยนแปลงอินเทอร์เฟซ IO reader / IO writer ใน Zig 0.15 เป็นผลจากการค้นหาจุดที่เหมาะสมที่สุด การออกแบบ API การทดสอบ และการเปรียบเทียบกับภาษาโปรแกรมอื่นเพื่อหาแนวทางใหม่ แต่หลังจากนั้นต้องใช้เวลา 6 เดือนในการแก้ไข standard library และโปรเจ็กต์ต่าง ๆ ใน ecosystem

  • ภาวะหมดไฟและคำแนะนำ

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

  • โปรเจ็กต์ที่ชื่นชมและความหลากหลายของเบราว์เซอร์

    • โปรเจ็กต์แรกที่เขาชื่นชมคือ Linux
    • เขามองว่าโลกที่มีแต่ระบบปฏิบัติการแบบปิดผูกขาดจะย่ำแย่กว่านี้มาก และ Linux ไม่เพียงเป็นประโยชน์ต่อชุมชนนักพัฒนาซอฟต์แวร์เสรีและโอเพนซอร์สเท่านั้น แต่ยังดีต่อเศรษฐกิจด้วย เพราะทำให้ประเทศและบริษัททั่วโลกสามารถสร้างธุรกิจได้ฟรี
    • อันดับสองคือ Blender ซึ่งเขาประเมินค่าสูงในฐานะโปรเจ็กต์โอเพนซอร์สและองค์กรไม่แสวงหากำไรที่ถูกใช้งานอย่างมืออาชีพ และยังแข่งขันรวมถึงเอาชนะบริษัทที่มีเงินและกำลังคนด้านพัฒนาจำนวนมากได้
    • อันดับสามคือ VLC โดยเขาย้อนความว่าเมื่อก่อนตอนมีส่วนร่วมกับ FFmpeg องค์กร VLC เป็นผู้รับผิดชอบค่าเดินทางไปงาน VideoLAN Dev Days ให้กับผู้ที่มีส่วนร่วมกับ VLC หรือไลบรารีที่เกี่ยวข้อง
    • เหตุผลที่เขาใช้ Firefox คือความกังวลเรื่องความหลากหลายของเบราว์เซอร์
    • หลัง Microsoft ยุติ Internet Explorer เบราว์เซอร์หลักที่เหลืออยู่มีเพียง Chromium, Safari และ Firefox และเขามองว่าการที่ Chromium ครองตลาดเกือบทั้งหมดเป็นปัญหาสำหรับเว็บ
    • เขาระบุว่าช่วงหลังมานี้ไม่พอใจกับ Mozilla และรู้สึกว่ามีการเสื่อมถอยอยู่มาก ทั้งที่เป็นองค์กรไม่แสวงหากำไร และดูเหมือนมีหลายกรณีที่เป้าหมายไม่สอดคล้องกับผู้ใช้
    • Chromium มี Google, Safari มี Apple ส่วน Firefox ดูเหมือนอยู่ในช่วงขาลง ทำให้ทางเลือกมีไม่มาก และเขามองว่ายังไม่รู้ว่าควรทำอย่างไรจนกว่าโปรเจ็กต์เบราว์เซอร์ใหม่ ๆ จะเติบโตเต็มที่

  • ถ้าย้อนกลับไปปี 2015 จะยังเริ่ม Zig หรือไม่

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

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

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

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs
  • อยากให้คนที่อยู่นอก Zig Software Foundation ได้เห็น ความหลงใหลและปรัชญา ที่ Andrew และทีมแกนหลักมีขณะผลักดันโปรเจกต์นี้ไปข้างหน้า
    จะโทษ JetBrains ที่ทำให้บทสัมภาษณ์ดูเร้าอารมณ์ขึ้นเพื่อหวังให้ไวรัลก็ไม่ได้ แต่สุดท้ายแล้วคำถามที่ดีที่สุดกลับไม่ใช่เรื่อง Zig ปะทะ Rust หากเป็นคำถามเกี่ยวกับ Zig ในฐานะสิ่งที่สร้างขึ้นด้วยความเป็นองค์กรไม่แสวงหากำไร ความยั่งยืน และความรัก
    คิดว่า Andrew แสดงให้โลกเห็นด้านความเป็นมนุษย์ที่ลุกไหม้อย่างเงียบ ๆ อยู่เบื้องหลังโปรเจกต์นี้ได้ดีมาก
    • พูดตามตรงก็ไม่คิดว่า JetBrains จะชี้นำไปในทางยั่วยุมากนัก
      วิดีโอนี้ดูเหมือนจะมุ่งไปที่ คนที่อยากรู้จัก Zig และคนที่สนใจการบริหารโปรเจกต์ มากกว่าคนที่ใช้ Zig มาเยอะพอสมควรอยู่แล้ว และแค่หยิบประเด็นที่ผู้ชมกลุ่มนั้นน่าจะอยากรู้ออกมาโดยไม่หลบเลี่ยง
      คนสัมภาษณ์เองก็ปล่อยให้คำพูดของ Andrew สื่อออกมาเองมากกว่าจะคอยเติมเชื้อไฟ และสำหรับบทสัมภาษณ์รูปแบบนี้ก็ถือว่ารอบคอบมาก
      แต่ก็แอบขำกับคำที่เลือกใส่เป็นซับไตเติลเหมือนกัน เพราะไม่แน่ใจว่าจะมีคนที่สนใจ Zig แต่ไม่รู้จัก Linux หรือไม่เข้าใจความหมายของ abstraction มากแค่ไหน
      โดยรวมแล้วประทับใจมาก ทั้งในแง่วิธีนำเสนอ Zig และในแง่ภาพลักษณ์ของทีมการตลาด JetBrains
  • ช่วงประมาณกลางวิดีโอ Andrew พูดถึงเครื่องมือที่ผมสร้างขึ้นมาเพื่อช่วยเรื่องการใช้ Zig กับ AI เผื่อใครอยากลอง เครื่องมือนั้นคือ zigdoc: github.com/rockorager/zigdoc
    โดยพื้นฐานแล้วมันคือเครื่องมือสำหรับดูเอกสารของ Zig standard library และ dependency ที่พบใน build graph ผ่านทาง command line
  • ชอบมากตรงช่วงไม่กี่วินาทีท้ายวิดีโอที่ Andrew บอกว่าเขา มีความสุข
  • คำว่า “งานที่ทำด้วยใจรักแบบไม่ประนีประนอม” นี่ใช่เลย
    กรอบความคิดแบบ ไม่เร่งออก 1.0 นั้นน่าดึงดูด แต่ Zig ก็ถือว่าโชคดีที่มีผู้ใช้ซึ่งยอมรับแรงสั่นสะเทือนจากการเปลี่ยนแปลงใน ecosystem
  • ฝั่ง embedded ใช้ C เป็นเครื่องมือหลักมาหลายปี
    ไม่ใช่ C++ แต่เป็น C ล้วน ๆ
    ผมลังเลมาตลอดว่าโปรเจกต์ embedded ถัดไปจะใช้ Zig หรือ Rust ดี แต่ตอนนี้เริ่มรู้สึกว่า “ถึงเวลาแล้ว”
    สำหรับผม บทสัมภาษณ์นี้อาจเป็นจุดเปลี่ยนสำคัญได้เลย และมันมี บรรยากาศโดยรวม ที่ชวนให้เห็นพ้องอย่างแรง
  • ชอบคำตอบเรื่อง เหตุผลที่ Zig พยายามก้าวออกจาก LLVM มาก
    มันอธิบายได้ดีว่าส่วนไหนที่เกี่ยวข้องกับความสามารถหลักของ Zig และเป็นจุดที่ทีมควรมีอำนาจควบคุมมากขึ้น