คำร้องขอหย่ากับ LLVM

• โปรเจกต์ Zig ตั้งเป้าที่จะลบการพึ่งพาไลบรารี LLVM, Clang และ LLD ออกจาก ไฟล์ปฏิบัติการ zig หลัก อย่างสมบูรณ์
• งานที่ยังเหลือแบ่งออกเป็นการลบ LLD, ลบการเรียกใช้ LLVM API, ความคืบหน้าของแบ็กเอนด์ C/x86/wasm/aarch64, การลบซับคอมมานด์และการใช้ preprocessor ที่พึ่งพา Clang, รวมถึงการทำตัวแทนของ zig ar
• แบ็กเอนด์ LLVM สามารถสร้างไฟล์ .bc ได้อยู่แล้ว แต่คอมไพเลอร์ Zig จะไม่มีความสามารถในการคอมไพล์ .bc ให้เป็นไฟล์อ็อบเจ็กต์อีกต่อไป และในกรณีนี้จำเป็นต้อง ติดตั้ง Clang แยกต่างหาก
• ผลที่คาดหวังคือการทำให้การบิลด์จากซอร์สและการบูตสแตรปง่ายขึ้น, หลีกเลี่ยงปัญหาเกี่ยวกับ LLVM/Clang/LLD ของดิสโทร Linux และ Homebrew, และลดขนาดไบนารีจากประมาณ 150 MiB → 5 MiB
• Zig ชูแนวทางว่าจะสามารถพัฒนา optimization pass ของตัวเอง, ดึงโปรเจกต์วิจัยอย่าง alive2 เข้ามา, และเปิดทางให้ Intel, ARM, และผู้ผลิตชิป RISC-V เข้ามามีส่วนร่วมโดยตรง

---

การพึ่งพาที่ต้องการลบออกจากไฟล์ปฏิบัติการ Zig

• เป้าหมายของ issue นี้คือการลบ ไลบรารี LLVM, Clang และ LLD ออกจากโปรเจกต์ Zig อย่างสมบูรณ์
• จุดเชื่อมต่อที่ยังเหลืออยู่สรุปได้เป็นส่วนของ LLD, LLVM, Clang และ zig ar

งานที่ยังเหลือเกี่ยวกับ LLD

• completely eliminate dependency on LLD #8726: ยังมีงานในการลบ การพึ่งพา LLD ออกอย่างสมบูรณ์

งานที่ยังเหลือเกี่ยวกับ LLVM

• ในส่วนของ LLVM มีทั้งการสร้าง LLVM bitcode, อัตราการผ่านการทดสอบของแบ็กเอนด์, และงานลบ LLVM API
• directly output LLVM bitcode rather than using LLVM's IRBuilder API #13265: งานสร้าง LLVM bitcode โดยตรงแทนการใช้ IRBuilder API ของ LLVM
• C backend อยู่ที่ ผ่านการทดสอบ 1742/1792 รายการ, คิดเป็นอัตราผ่าน 97%
• enable the x86 backend by default for debug builds on x86_64-linux #22257: งานเปิดใช้ x86 backend เป็นค่าเริ่มต้นสำหรับดีบักบิลด์บน x86_64-linux
• wasm backend อยู่ที่ ผ่านการทดสอบ 1611/1765 รายการ, คิดเป็นอัตราผ่าน 91%
• 100% behavior tests passing for the aarch64 backend #21172: งานทำให้ behavior test ของ aarch64 backend ผ่าน 100%
• ability to create import libs from def files without LLVM #17807: ความสามารถในการสร้าง import libs จากไฟล์ def โดยไม่ใช้ LLVM
• Avoid LLVM API for setting a module's code model and PIC/PIE levels #21238: งานหลีกเลี่ยงการใช้ LLVM API ในการตั้งค่า code model และระดับ PIC/PIE ของโมดูล
• completely eliminate dependency on LLVM library API calls #25492: งานลบการพึ่งพา การเรียกใช้ LLVM library API ออกอย่างสมบูรณ์

งานที่ยังเหลือเกี่ยวกับ Clang

• ไฟล์ซอร์ส C++ ในรีโพซิทอรี Zig ยังถูกบิลด์ด้วย clang ในขั้นตอนบูตสแตรป
  • src/windows_sdk.cpp: port to Zig #15657: งานพอร์ต src/windows_sdk.cpp ไปเป็น Zig
• zig cc, zig c++, zig translate-c and other subcommands without a clang/llvm dependency in the compiler binary #20875: งานทำให้ zig cc, zig c++, zig translate-c และซับคอมมานด์อื่น ๆ ใช้งานได้โดยไม่ต้องพึ่งพา clang/llvm ภายในไบนารีคอมไพเลอร์
• make resinator use aro's preprocessor instead of clang #17752: งานเปลี่ยนให้ resinator ใช้ preprocessor ของ aro แทน clang
• make mingw .def.in file parsing use aro's preprocessor instead of clang #17753: งานเปลี่ยนให้การพาร์สไฟล์ mingw .def.in ใช้ preprocessor ของ aro แทน clang
• move @cImport to the build system #20630: งานย้าย @cImport ไปไว้ใน build system

ข้อจำกัดของ zig ar และการจัดการไฟล์ .bc

• zig ar: a drop-in llvm-ar replacement #9828: ยังมีงานทำ zig ar ให้เป็น ตัวแทนของ llvm-ar แบบใช้แทนได้ทันที
• แบ็กเอนด์ LLVM สามารถสร้างไฟล์ .bc ได้แล้ว แต่คอมไพเลอร์ Zig จะไม่มีความสามารถในการคอมไพล์ไฟล์ .bc ให้เป็นไฟล์อ็อบเจ็กต์
• หากต้องการรองรับกรณีใช้งานนี้ จำเป็นต้อง ติดตั้ง Clang แยกต่างหาก

การเปลี่ยนแปลงที่คาดหวังจากการลบการพึ่งพา

• บั๊กฝั่ง Zig ทั้งหมดจะอยู่ในขอบเขตความรับผิดชอบของโปรเจกต์ Zig เอง
• กระบวนการบิลด์คอมไพเลอร์จากซอร์สและการบูตสแตรปจะง่ายขึ้น และระบบโฮสต์จะต้องมีเพียง C compiler เท่านั้น
• ดิสโทร Linux และตัวจัดการแพ็กเกจอย่าง Homebrew จะไม่ต้องรับมือกับปัญหาที่เกี่ยวข้องกับ LLVM, Clang และ LLD อีกต่อไป
• ขนาดไบนารีของคอมไพเลอร์ Zig จะลดลงจากประมาณ 150 MiB เหลือ 5 MiB
• ความเร็วในการคอมไพล์อาจเพิ่มขึ้นหลายหลัก
• Zig จะสามารถพัฒนา optimization pass ของตัวเองเพื่อผลักดันขีดความสามารถระดับแนวหน้าของวงการคอมพิวติ้ง
• จะสามารถดึงโปรเจกต์วิจัยอย่าง alive2 เข้ามาได้
• สามารถกระตุ้นการมีส่วนร่วมโดยตรงจากผู้มีส่วนได้ส่วนเสียที่ต้องการ machine code ที่ดีกว่าบน CPU ของตนเอง เช่น Intel, ARM และผู้ผลิตชิป RISC-V

[alstjr7375]

จะสามารถทำการปรับแต่งประสิทธิภาพหรือรองรับแพลตฟอร์มต่าง ๆ ได้เท่ากับ LLVM ไหม..

[GN⁺]

ความคิดเห็นจาก Hacker News

• Andrew เป็นคนที่เฉียบคมมาก พอประกาศเป็นเป้าหมายแล้วก็ดูเหมือนว่าทีมจะทำสำเร็จในที่สุด
  แต่ในมุมของคนที่ไม่ได้เข้าใจความยากลำบากของ Zig กับ LLVM มากนัก การตัดสินใจนี้ดูเหมือนเป็นการเบนความสามารถของทีมไปที่ เครื่องมือประกอบรอบข้างอย่าง binutils มากกว่าตัว Zig เอง
  ตอนเห็นแค่พาดหัวก็นึกว่ากำลังจะทิ้งคอมไพเลอร์เสียอีก และสำหรับโปรเจกต์อย่าง Zig ก็ยังดูเหมือนจะได้ประโยชน์มากจากการคง LLVM ไว้
  ถึงอย่างนั้น แนวคิดที่จะเขียนโค้ดจำนวนมากใน LLVM ใหม่ด้วย Zig แทน C++ ก็ทั้งเท่และทะเยอทะยานมาก อาจเรียกได้ว่าทะเยอทะยานพอๆ กับความพยายามของ Lattner ตอนสร้าง LLVM
  แต่โค้ดที่เผลอทำให้เกิด ความซับซ้อนเชิงเวลาแบบกำลังสอง ก็คงเลี่ยงได้ยากสำหรับ Zig เช่นกัน หากมันได้รับความนิยมและมีประโยชน์มากพอๆ กับ LLVM

  • ทำให้นึกถึงประโยคหนึ่งที่เคยอ่านจากเอกสารจัดการโครงการที่ดูเหมือนจะเป็นเอกสารไม่เป็นทางการของ NASA
    ใจความประมาณว่า “ถ้าภารกิจอวกาศไม่ได้ใช้จรวดส่งเดิมซ้ำ โปรเจกต์นั้นก็จะกลายเป็นโปรเจกต์พัฒนาจรวดส่ง และอย่างอื่นที่คิดว่าเป็นแกนหลักของภารกิจก็จะกลายเป็นเรื่องรองไปทั้งหมด”
    อีกส่วนที่จำได้คือมีเงื่อนไขนำว่า “แทนที่จะยอมประนีประนอมให้เข้ากับจรวดส่งที่มีอยู่เดิม อาจคิดว่าการสร้างจรวดส่งให้เหมาะกับภารกิจเฉพาะจะถูกกว่าและมีประสิทธิภาพกว่า”
  • ทำให้นึกถึงบทสัมภาษณ์ล่าสุดของ Chris Lattner เรื่องความสำเร็จของ Swift เขามองว่าปัจจัยสำคัญคือ สามารถเริ่มผสมใช้ Swift ได้ ในโปรเจกต์ Objective-C ขนาดใหญ่โดยไม่ต้องเขียนอะไรใหม่ทั้งหมด
    ส่วนหนึ่งของความสำเร็จของ Rust ก็อยู่บนความเข้ากันได้ลักษณะคล้ายๆ กันกับ C/C++
    นึกภาพยากว่า Zig จะประสบความสำเร็จได้หากไม่มีความสามารถแบบเดียวกัน และเพราะงั้นจึงหวังว่าจะไม่ดันหมุดหมายนี้ต่อไปแบบเดิม
  • มันต่างจาก LLVM มาก อย่างน้อยในบริบทที่ Apple เข้ามารับช่วงโปรเจกต์นั้น แทบไม่มีทางเลือกอื่นเลย
    เพราะ GCC ไม่ยอมเปิดทางหรือไม่ตั้งใจจะทำสิ่งที่ Apple ต้องการหรือจำเป็นต้องใช้
  • ไม่ถึงกับเป็น “สิ่งที่ประกาศเป็นเป้าหมาย” มันยังเป็นแค่ ข้อเสนอที่ยังไม่ถูกรับเข้า
  • binutils ใกล้เคียงกับการเป็น ชุดเครื่องมือสารพัดประโยชน์ สำหรับจัดการฟอร์แมตโค้ดไบนารีแบบพกพาได้มากกว่า และคอมไพเลอร์ก็ไม่ได้ต้องการครึ่งหนึ่งของสิ่งเหล่านั้น โดยเฉพาะส่วนที่รองรับของเก่า
    ถ้าโฟกัสแบบ TCC งานส่วนใหญ่ก็น่าจะไปอยู่ที่การสร้างโค้ดสำหรับหลายสถาปัตยกรรม

• ตรงนี้มีปัญหาอยู่สองอย่าง อย่างหนึ่งคือ การสร้างโค้ด และอีกอย่างคือ การบูตสแตรป
  จากประสบการณ์ ส่วน optimization pass ของคอมไพเลอร์นั้นเขียนง่ายและสนุก ต้องอ่านเปเปอร์ถึงจะเข้าใจการจัดสรรรีจิสเตอร์กับรูปแบบ SSA ก็จริง แต่โค้ดที่ค่อยๆ ขัดเกลา IR ผ่าน optimization pass หลายๆ ตัวนั้นเขียนได้สนุก
  คุณสามารถสร้าง optimization pass คุณภาพสูงได้โดยไม่ต้องมี LLVM แต่ขั้นตอนที่ทำให้ IR กลายเป็นภาษาเครื่องจริงๆ นั้นเป็นงานน่าเบื่อธรรมดาๆ เว้นแต่คุณจะชอบรายละเอียดสารพัดแบบของการเข้ารหัสคำสั่ง x86-32/64 สำหรับคำสั่งอย่าง “mov [eax+8*ebx], 123”
  ถ้าจะ optimize ขนาดไบนารี คุณอยากมานั่งวัดไหมว่าบนแพลตฟอร์มไหน “push eax; push eax; push eax” สั้นกว่า “add rsp,12” เรื่องนี้ยังเป็นแค่โลกของ x86 เท่านั้น และถ้าคูณด้วยสถาปัตยกรรมที่ไม่ใช่ x86 ซึ่งสำคัญน้อยกว่าสำหรับนักพัฒนาส่วนใหญ่ ขอบเขตงานก็จะใหญ่ขึ้นมาก
  แถมยังมีโอกาสสูงมากที่บั๊กใหญ่ในตัวสร้างโค้ดของสถาปัตยกรรมที่ไม่ค่อยมีคนใช้จะไม่ถูกค้นพบไปอีกหลายปี
  อีกปัญหาคือการบูตสแตรป คำถามคือจะใช้ตัวอะไรคอมไพล์ Zig compiler ที่เขียนด้วย Zig? เช่น คุณอาจใช้ Zig compiler ฉบับมินิมอลที่ไม่ optimize ซึ่งเขียนด้วย C มาคอมไพล์ Zig compiler ได้
  แต่ถ้ามันไม่ optimize คุณก็ต้องเอา Zig compiler ที่ optimize แล้วมาคอมไพล์ Zig compiler ซ้ำอีกที แม้จะไม่ใช่ปัญหาที่แก้ไม่ได้ แต่กระบวนการ build ที่ยาวและซับซ้อนเสี่ยงจะไล่ผู้ร่วมพัฒนาที่อาจสนใจออกไป

  • ดูเหมือนบทความนี้จะพูดถึงปัญหาการบูตสแตรป: https://ziglang.org/news/goodbye-cpp/
  • Zig บูตสแตรปด้วย C backend อยู่แล้ว ดังนั้นปัญหาที่สองจึงไม่ใช่ปัญหา

• Zig เคยโปรโมตหนักว่าคอมไพล์ C และอาจรวมถึง C++ ได้ แต่ตอนนี้กลับจะ ถอด LLVM ออกทั้งหมด ก็ดูรุนแรงพอสมควร
  เว้นแต่ว่าจะมีคนเข้ามาช่วยรองรับเพิ่มขึ้นอีกมาก ไม่อย่างนั้นก็ดูมีโอกาสต่ำมากที่จะเข้าใกล้ระดับการรองรับแพลตฟอร์มแบบ LLVM
  จะเพิ่ม backend ของตัวเองให้คนที่ต้องการใช้ก็พอเข้าใจได้ แต่การเอา LLVM ออกไปเลยดูใจร้อนเกินไป

  • ถ้างานเริ่มทำไปแล้วก็อาจเรียกว่าใจร้อนได้ แต่เหมือนข้อเสนออื่นๆ ที่ยังไม่มีป้าย “accepted” ใน issue tracker ตอนนี้มันยังเป็นแค่ช่วงเปิดให้ถกเถียงและเสนอทางคัดค้านเท่านั้น
    ตอนนี้เป็นช่วงที่ทีมกำลังรวบรวมฟีดแบ็ก เรียนรู้ use case ที่จะได้รับผลกระทบ และประเมินความเป็นไปได้ ดังนั้นจึงแทบจะตรงข้ามกับคำว่าใจร้อนมากกว่า
  • ถ้าอ่านเนื้อหาใน issue ที่ลิงก์ไว้ จะเห็นว่าไม่ได้ลบ LLVM backend ออกทั้งหมด แต่แค่ แยกออกจากไบนารีหลัก และถ้าในระบบมี LLVM ติดตั้งอยู่ก็ยังใช้เป็น backend ได้ง่ายเหมือนเดิม
    การต้อง bundle สำเนา LLVM ขนาด 100MB+ ทั้งที่กรณีทั่วไปไม่ได้ต้องใช้ ก็ดูแปลกอยู่เหมือนกัน เลยถือว่าพอฟังขึ้น และถ้าเป็นนักพัฒนาก็มักติดตั้งไว้อยู่แล้วด้วย
    แต่ก็อาจยากที่จะรับประกันว่า Zig ที่ติดตั้งไว้จะทำงานกับ LLVM เวอร์ชันของระบบได้ถูกต้อง ต้องรอดูต่อไป
  • มันยังคงส่งออก LLVM bitcode อยู่ เพียงแต่จะไม่พึ่งพา ไลบรารีของ LLVM อีกต่อไป
    https://github.com/ziglang/zig/issues/13265
  • ผมก็เข้าใจไปแบบนั้นเหมือนกัน
    ช่วงหลังผมอ่านเรื่อง Zig มากขึ้น และยังลองใช้มันเป็นวิธีคอมไพล์ C++ ด้วย LLVM แบบง่ายๆ โดยไม่ต้องไปปวดหัวกับ system package ความสามารถในการค่อยๆ ย้ายจาก C/C++ ไป Zig เป็นจุดขายใหญ่เลย
    มันดูฉับพลันและคาดไม่ถึงมาก จะถูกหรือผิดสำหรับโปรเจกต์นี้ผมไม่รู้ แต่จากมุมมองของผมมันรู้สึกโผล่มาแบบไม่มีปี่มีขลุ่ยจริงๆ
  • ผมใช้ Zig เป็น คอมไพเลอร์ C++ ในโปรเจกต์ Rust เพราะมันเป็นวิธีทำ cross-compile บน GitHub Actions ที่เจ็บปวดน้อยที่สุด

• อีกด้านหนึ่งก็เคารพความตั้งใจแบบละเอียดรอบคอบที่จะลด dependency แต่ราคาที่ต้องจ่ายก็ดูหนักพอสมควร
  การสูญเสียความเข้ากันได้กับ C++ เท่ากับทำให้ข้อดีที่แฟน Zig รอบตัวผมพูดถึงบ่อยที่สุดแทบหายไป
  ส่วนการสูญเสียประสิทธิภาพ แม้จะเป็นแค่ชั่วคราว ก็เป็นอีกประเด็นหลักที่พวกเขาพูดถึงควบคู่กันเสมอ

  • ดูเหมือนว่าปฏิกิริยาส่วนใหญ่จะคัดค้านข้อเสนอนี้
    เผื่อคนที่อ่านผ่านๆ นี่ไม่ใช่สิ่งที่ตัดสินใจแล้ว แต่เป็นแค่ ข้อเสนอ

• ตลอดราว 4 ปีที่ผ่านมา ฉันเขียนโปรเจกต์ฝังตัวและไลบรารีทั้งหมดด้วย Zig แล้วตอนนี้ สถาปัตยกรรมที่รองรับระดับ tier 1 หลายตัวจะหายไปเฉย ๆ เหรอ?
  ภาษาก็เป็นของฝั่งนั้น จะทำอย่างที่ต้องการก็ได้ แต่ถ้าเป็นแบบนั้นก็น่าจะปรับภาพลักษณ์ให้สอดคล้องกันด้วย

  • มันจะหายไปจริง ๆ เหรอ?
    น่าจะกลายเป็นว่าการรองรับระดับ tier 1 แบ่งเป็นสองประเภท คือ tier 1 ที่รองรับในตัว กับ tier 1 ที่รองรับผ่าน LLVM backend แบบเลือกใช้ได้
    ถ้ามีสถาปัตยกรรมไหนที่ได้ tier 1 อยู่แล้ว ก็ไม่เห็นเหตุผลว่าการเปลี่ยน LLVM backend ให้เป็น dependency แบบเลือกใช้ได้จะทำให้การรองรับนั้นหายไป
    อย่างที่ Andrew เขียนไว้ในข้อเสนอ วิธีนี้อาจเป็นหนทางให้รองรับสถาปัตยกรรมที่พบไม่บ่อยได้ดีขึ้นด้วย ถ้าเป็น Zig backend สำหรับสถาปัตยกรรมโปรเซสเซอร์ที่น่าสนใจ ฉันยินดีทำ แต่จะไม่ไปมีส่วนร่วมกับ LLVM เด็ดขาด การทำงานกับ C++ ไม่ใช่งานอดิเรกที่อยากทำ
  • นี่หมายถึงจะเอา LLVM ออก แล้วสร้างทุกอย่างที่ LLVM ทำขึ้นมาใหม่ด้วยวิธีของตัวเองเหรอ?
    แล้วข้อดีคืออะไร? มันไม่ใช่ การสิ้นเปลืองทรัพยากร เหรอ?
  • Zig ยังไม่ถึง 1.0 ก็ไม่ใช่เรื่องปิดบังอะไร จะโทษฝั่งนั้นทั้งหมดก็คงไม่ได้ แต่ถึงอย่างนั้นมันก็ดูเป็นข้อเสนอที่ค่อนข้างหักดิบ
  • ตอนนี้ยังอยู่แค่ขั้นข้อเสนอเท่านั้น GitHub issue ก็มีไว้เพื่อโพสต์กรณีใช้งานทั้งที่เห็นด้วยและไม่เห็นด้วยเป็นหลัก และยังไม่ได้ Accepted
  • นี่ยังเป็นแค่ข้อเสนอ ดังนั้นถ้ามีคนออกความเห็นมากพอ ซึ่งตอนนี้ก็มีหลายคนทำอยู่แล้ว ฉันคิดว่าทีมแกนหลักก็น่าจะปรับแนวทางได้

• DLang มีคอมไพเลอร์อยู่ 3 ตัว
  gdc ใช้ backend ของ GNU Compiler Collection, ldc ใช้ LLVM backend, และ dmd ใช้ตัวสร้างโค้ด x86 ที่ฉันเขียนไว้สำหรับ Zortech/Symantec/Digital Mars
  แต่ละตัวมีข้อดีข้อเสียและกลุ่มเป้าหมายต่างกัน แต่ ภาษา D ที่รองรับนั้นเหมือนกัน
  โดยรวมแล้วผู้ใช้ชอบมีตัวเลือก และบางคนก็ใช้มากกว่าหนึ่งตัวด้วย

  • นี่เป็นความต่างด้านแนวทางที่น่าสนใจ D ดูเหมือนมีคอมไพเลอร์ที่แยกจากกันโดยสมบูรณ์ แต่ Zig ดูเหมือนกำลังไปในทางที่คอมไพเลอร์ Zig หลักจะ รองรับ LLVM เป็น backend หากติดตั้งไว้
    ถ้าเข้าใจถูก ฉันชอบแนวทางของ Zig
  • อีกภาษาหนึ่งที่มีหลายคอมไพเลอร์คือ Common Lisp มีคอมไพเลอร์ระดับพร้อมใช้จริงราวสิบตัว ทั้งแบบเชิงพาณิชย์และส่วนใหญ่เป็นฟรี
    มันมีประโยชน์มาก เพราะระหว่างพัฒนาคุณใช้คอมไพเลอร์ที่คอมไพล์เร็วที่สุดได้ และตอนออกรีลีสสุดท้ายก็ใช้คอมไพเลอร์ที่มีรันไทม์เร็วที่สุดหรือใช้หน่วยความจำน้อยที่สุดได้
    และถ้ามี ข้อกำหนดของภาษา ที่คอมไพเลอร์ทุกตัวทำตาม ก็จะช่วยรับประกันได้ว่าภาษามีเสถียรภาพและจะไม่พังจากข้างล่างแบบไม่ทันตั้งตัว
    แน่นอนว่าภาษาแบบ Zig ที่ยังเปลี่ยนสิ่งที่ต้องการได้เพื่อทำให้ภาษาสอดคล้องกันมากขึ้น สะอาดขึ้น และทรงพลังขึ้น ก็มีข้อดีเหมือนกัน แต่ทุกวันนี้ฉันให้คุณค่ากับเสถียรภาพแบบนั้นมากกว่าเยอะ เพราะจะได้โฟกัสกับการสร้างคุณค่าจริงให้ผู้ใช้ แทนที่จะต้องคอยวิ่งตามเครื่องมือพัฒนาอยู่ตลอด
  • การมีตัวเลือกสำหรับผู้ใช้ระดับสูงเป็นข้อดี แต่ การที่ต้องเลือก นั้นเองเป็นข้อเสียใหญ่ในความเห็นฉัน
  • ฉันเข้าใจว่าผู้ใช้ชอบมีตัวเลือก แต่ถ้า Zig ตั้งเป้าการยอมรับในวงกว้างระยะยาว ฉันไม่คิดว่า DLang จะเป็นตัวอย่างที่ดี

• หนึ่งในเหตุผลหลักที่ Zig น่าสนใจสำหรับฉันคือมันสามารถเสียบแทนคอมไพเลอร์ C/C++ ได้ทันที
  เพื่อน ๆ บอกว่าบน Windows นั้นติดตั้ง Zig เป็นคอมไพเลอร์ C/C++ ได้ง่ายกว่าทางเลือกอื่น ๆ
  ถ้าข้อเสนอนี้ถูกรับไปใช้ ฉันคิดเป็นการส่วนตัวว่าความนิยมของ Zig จะตกลงไปอยู่ระดับเดียวกับ Hare หรือภาษาเฉพาะกลุ่มสุดโต่งอื่น ๆ
  กว่าจะทำให้เพื่อนร่วมงานยอมลองใช้ Zig สักครั้ง ฉันยังต้องส่งบทความที่บอกว่า Uber ใช้มันในโปรดักชันเลย ถ้ามันไม่ได้มีคุณค่าในทันทีต่อโปรเจกต์เดิม เพื่อนร่วมงานก็คงไม่คิดซ้ำเป็นรอบที่สองด้วยซ้ำ
  ถึงอย่างนั้นฉันก็เข้าใจที่มาของข้อเสนอ เวลาในการคอมไพล์ของ LLVM อาจรู้สึกแย่มาก และถ้ามี bytecode ของตัวเองก็อาจทำเทคนิคการเพิ่มประสิทธิภาพเจ๋ง ๆ ได้ด้วย การจัดการบั๊กของ LLVM ก็แทบเป็นงานที่แตะยากมาก และฉันก็เคยเห็นเรื่องนี้ใน ecosystem ของ Julia
  ถ้าคำแนะนำของฉันมีน้ำหนักบ้าง ฉันคิดว่า Zig ควร 1) ใช้ custom bytecode สำหรับ debug build เพื่อให้ build เร็วและดีบักได้เร็ว และ 2) ใช้ LLVM สำหรับ release build เพื่อให้ประสิทธิภาพรันไทม์เร็ว
  ถ้าทำข้อ 1) ได้พร้อมกับคงการรองรับการ cross-compile ของ C/C++ เอาไว้ เช่น ส่งต่อเฉพาะส่วนนั้นให้ LLVM ก็อาจเป็นจุดประนีประนอมที่ดีที่สุด แม้จะมีภาระแลกเปลี่ยนเรื่องต้องดูแลโค้ด backend เพิ่มก็ตาม

  • ในฐานะคนหนึ่งที่จัดการบั๊ก LLVM ใน ecosystem ของ Julia ขอบอกว่าใช่เลย
    มันต้องใช้ทักษะอีกชุดหนึ่งที่ต่างจากงานกับคอมไพเลอร์ Julia ระดับสูง และบางครั้งการรวมบั๊กฟิกซ์กลับขึ้นไป upstream ก็ใช้เวลานาน
    แต่ในความเป็นจริง เรามีความสัมพันธ์ที่ดีและทำงานร่วมกับ upstream ได้อย่างมีประสิทธิผลมาก และถ้าเราตัดสินใจจะเลิกใช้ LLVM โปรเจกต์ก็คงทำอะไรได้น้อยกว่านี้มาก
    โดยเฉพาะการรองรับ GPU และ HPC เช่น PPC ต่างพึ่งพา LLVM
    เพราะแบบนั้นเราจึงยืนยันจุดยืนให้ build Julia ให้เข้ากับ patchset/fork ของเรา และไม่ลงทุนเวลาไปกับบั๊กที่เกิดจาก Julia build ที่ไม่ได้ใช้แพตช์เหล่านั้น โดยเฉพาะ build จากดิสโทรที่เจอบ่อย

• จากมุมมองของคนที่เฝ้าดูงานทำ backend ที่ไม่ใช่ LLVM ของภาษาอื่น ๆ ข้อเสนอที่ลิงก์มานี้ให้ความรู้สึก หยิ่งผยอง แรงเกินไป
  ถ้าคนเขียนไม่ใช่คนนั้น ฉันคงคิดว่าเป็น GitHub issue ที่มือใหม่ Zig เขียนลวก ๆ
  มันประเมินปริมาณงานที่ต้องทำต่ำเกินไป ลดทอนงานทั้งหมดที่ใส่เข้าไปใน LLVM แบบกลาย ๆ และทุกประโยคก็แฝงความมั่นใจปนความเป็น macho ว่า “แน่นอนว่าเราทำได้ถูกกว่า เร็วกว่า และดีกว่า” น่าผิดหวังมาก
  ก่อนหน้านี้ฉันเคารพงานของ Andrew มากจริง ๆ เลยพยายามมองในแง่ดีว่าเขาอาจเขียนแบบรีบ ๆ หรือเขียนสด ๆ จนไม่ทันระวังว่ามันจะอ่านออกมาเป็นแบบนี้
  แต่ข้อความนี้ไม่ได้ทำให้รู้สึกเชื่อมั่น หรือทำให้มองข้อเสนอนี้ด้วยใจที่เปิดกว้างขึ้นเลย

  • ฉันไม่รู้อะไรเกี่ยวกับ LLVM backend เลย แต่ไลบรารีที่พยายามแก้ปัญหาของผู้ใช้ให้ครบ 100% มักจะลงเอยด้วยการใช้งานยากและช้ากว่าทางเลือกที่ปรับมาเฉพาะทางกว่า
    Webpack และ esbuild เป็นตัวอย่างของเรื่องนี้

• ช่วงเวลาที่เหมาะจะสร้างอะไรสักอย่างโดยไม่มี LLVM คือเมื่อหลายปีก่อน แต่ตอนนี้ถ้าตัด ความสามารถด้าน C++ ออกไป มันอาจเป็นจุดจบของ Zig ได้เลย
  ฉันแปลกใจที่แทนที่จะค่อย ๆ เอาออก กลับไม่ได้ประกาศแผนว่าจะเขียนคอมไพเลอร์ C++ ของตัวเองด้วย Zig

  • แค่เขียน parser สำหรับ C++ ก็เป็นโปรเจกต์ขนาดมหึมาแล้ว
    ฉันยังไม่แน่ใจเลยว่าคนคนหนึ่งที่เริ่มตอนวันเกิดอายุครบ 18 จะเขียนคอมไพเลอร์ C++ ได้หรือไม่ อาจมีเวลาไม่พอตลอดชีวิตที่เหลือให้สร้างคอมไพเลอร์ที่ใช้งานได้ด้วยซ้ำ

• Zig อยากเป็น C ตัวใหม่ของโลก มากกว่าจะอยากเป็น C++ ตัวใหม่ของโลก
  จากข้อเสนอนี้ก็เห็นได้ว่า การคอมไพล์ข้ามแพลตฟอร์มสำหรับ C จะยังคงได้รับการรองรับต่อไป
  การเลือกแบบนี้อาจจะถูกต้องก็ได้ ตอนนี้ C ยังถูกใช้อย่างมากในโลกของระบบฝังตัว และในพื้นที่นั้น LLVM ทำได้ไม่ดีนัก
  ถ้าฉันเป็น Zig ก็คงอยากเล็งไปที่ไมโครคอนโทรลเลอร์ทั้งหมด และนี่คือเส้นทางเดียวที่เป็นจริงในการทำให้สำเร็จ