โหมดดีบักตั้งค่าให้ใช้แบ็กเอนด์ x86 แบบโฮสต์ตัวเองเป็นค่าเริ่มต้น

 (ziglang.org)
1 คะแนน โดย GN⁺ 2025-06-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตอนนี้สำหรับเป้าหมาย x86_64 จะใช้ แบ็กเอนด์ x86 ของ Zig ที่โฮสต์ตัวเอง เป็นค่าเริ่มต้นในโหมดดีบัก
  • ทำได้ทั้ง ผ่านการทดสอบการทำงานมากกว่า และคอมไพล์ได้เร็วกว่าแบบเดิมที่อิง LLVM
  • การนำแบ็กเอนด์ของตัวเองมาใช้ช่วยให้ Zig ลดเวลาคอมไพล์ลงอย่างมาก และเพิ่มประสิทธิภาพของงานบางประเภท
  • มีการเสริมความสามารถหลายด้าน เช่น ระบบบิลด์ที่เพิ่งปรับปรุง, การขยายการรองรับ BSD ตระกูลต่าง ๆ, และการปรับปรุงรันไทม์ UBSan
  • เน้นจุดแข็งเฉพาะของ Zig ผ่านการปรับแต่ง ไลบรารีมาตรฐาน และเครื่องมือของตัวเอง

สรุปข่าวสำคัญล่าสุด

8 มิถุนายน 2025 – แบ็กเอนด์ x86 แบบโฮสต์ตัวเอง เปลี่ยนเป็นค่าเริ่มต้นในโหมดดีบัก

  • สำหรับเป้าหมาย x86_64 ตอนนี้จะใช้ แบ็กเอนด์ x86 ของ Zig ที่โฮสต์ตัวเอง โดยอัตโนมัติ
    • ก่อนหน้านี้ใช้ LLVM เพื่อแปลงจากบิตโค้ดเป็นไฟล์อ็อบเจ็กต์
    • ส่วน Windows ยังต้องทำงานเพิ่มเติมกับ COFF linker จึงยังชะลอการเปลี่ยนแปลงนี้ไว้
  • แบ็กเอนด์ x86 ของ Zig ผ่าน การทดสอบการทำงาน 1,987 รายการ แสดงความเสถียรที่แข็งแกร่งกว่าแบ็กเอนด์ LLVM (1,980 รายการ)
    • แม้ว่าการทดสอบทั้งหมดจะมี 2,084 รายการ แต่บางส่วนซ้ำกับการทดสอบของ LLVM เอง จึงตรวจเพิ่มเติมเฉพาะตอนทดสอบแบ็กเอนด์ของตัวเอง
  • เหตุผลหลักที่ Zig มุ่งพัฒนา ตัวสร้างโค้ดของตัวเอง คือเพื่อให้ความเร็วในการบิลด์เหนือกว่า LLVM อย่างชัดเจน
    • จากผลเบนช์มาร์ก zig build-exe hello.zig -fllvm (ใช้ LLVM) มีเวลาเฉลี่ยในการบิลด์ 918ms ขณะที่แบ็กเอนด์ของตัวเองทำได้ 275ms
    • ทั้งการใช้หน่วยความจำ, CPU cycles, จำนวนคำสั่ง, cache misses และด้านอื่น ๆ ล้วนมีประสิทธิภาพ ดีขึ้นอย่างมาก
    • เวลาในการบิลด์โปรเจ็กต์ขนาดใหญ่อย่างตัวคอมไพเลอร์ Zig เองก็ลดลงจาก 75 วินาทีเหลือ 20 วินาที
  • ต่อจากนี้มีแผนทำ การขนานการสร้างโค้ดแบบสมบูรณ์ เพิ่มความสามารถด้านลิงก์ และพัฒนาแบ็กเอนด์ aarch64
    • การเพิ่ม Legalize pass แบบใหม่จะช่วยเร่งงานฝั่ง aarch64 ด้วย
  • ผู้ใช้สามารถทดลองการเปลี่ยนแปลงล่าสุดได้ผ่าน บิลด์ล่าสุดของ master branch ของ Zig

6 มิถุนายน 2025 – วิดีโอแนะนำระบบบิลด์

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

20 พฤษภาคม 2025 – เพิ่มการรองรับเป้าหมาย FreeBSD และ NetBSD

  • หลังรวม Pull Request #23835 และ #23913 แล้ว zig cc และ zig build สามารถบิลด์ไบนารีสำหรับ เป้าหมาย FreeBSD 14.0.0+ และ NetBSD 10.1+ ได้
    • กลยุทธ์การ ดึงข้อมูล libc และไลบรารีที่เกี่ยวข้อง ซึ่งเดิมใช้กับ glibc ได้ถูกขยายไปใช้กับระบบตระกูล BSD ด้วย
    • ไฟล์ abilists ที่สร้างขึ้นจะถูกแจกจ่ายไปพร้อมกับ Zig ทำให้ระหว่างการคอมไพล์ข้ามแพลตฟอร์มสามารถ สร้างไลบรารีสตับ (stub) ที่ตรงกับแต่ละไลบรารี libc ได้อย่างแม่นยำ
    • ยังมีการจัดส่ง system headers และ libc headers ตาม เวอร์ชัน OS ล่าสุด มาพร้อมกันด้วย
    • OpenBSD, Dragonfly BSD, SerenityOS, Android และ Fuchsia ก็เป็นเป้าหมายการรองรับเช่นกัน

9 เมษายน 2025 – เว็บไซต์ทางการของ Zig บิลด์ด้วย Zine แบบสแตนด์อโลน

  • เว็บไซต์ทางการของ Zig เปลี่ยนมาใช้โครงสร้างที่บิลด์ด้วย Zine แบบสแตนด์อโลน
    • พัฒนาจากสคริปต์บิลด์เดิมมาเป็นไฟล์ปฏิบัติการเดี่ยว
    • ทางโครงการระบุว่านี่เป็นจังหวะที่ดีในการลองใช้งานด้วยตัวเอง

ข่าวการออกรีลีสและการปรับปรุงฟีเจอร์

  • รีลีส 0.14.0 จะเปิดให้ใช้งานในเร็ว ๆ นี้ และมีการนำการปรับปรุงที่น่าสนใจหลายอย่างเข้ามาแล้ว
  • การปรับปรุง C interop และ รันไทม์ UBSan (Undefined Behavior Sanitizer) ทำให้ข้อผิดพลาด SIGILL ที่ก่อนหน้านี้คลุมเครือ ถูกแทนที่ด้วยข้อความผิดพลาดที่ชัดเจนและมีประโยชน์มากขึ้น
    • ตัวอย่างเช่น สามารถระบุตำแหน่งและสาเหตุของ signed integer overflow ได้อย่างชัดเจน ช่วยเพิ่มประสิทธิภาพในการดีบักอย่างมาก
  • ข้อจำกัดของ UBSan ที่ยังเหลืออยู่:
    • ยังไม่รองรับการตรวจสอบ dynamic type และ lifecycle ที่เกี่ยวข้องกับ C++ vptr
    • การระบุตำแหน่งที่แม่นยำของแอตทริบิวต์อย่าง assume_aligned, __nonnull ฯลฯ ยังไม่สมบูรณ์

7 กุมภาพันธ์ 2025 – นวัตกรรมใน debug allocator และ SmpAllocator

  • มีการออกแบบ debug allocator ใหม่ รองรับการรับรู้ขนาดเพจขณะรันไทม์และรวมการปรับแต่งหลายด้าน
    • ลดการสร้าง memory map, ตัดการทำ memset 0xaa/0x00 ซ้ำโดยไม่จำเป็น, และนำโครงสร้างข้อมูลสำหรับการค้นหาและต้นไม้แบบทริปออก
    • เก็บเมทาดาทาแบบอินไลน์ภายในเพจ ทำให้เขียนการตรวจสอบและข้อผิดพลาดขณะคอมไพล์ได้ง่ายขึ้น
    • มี ความอ่านง่ายและบำรุงรักษาได้ดีกว่า malloc แบบ C เดิม
  • มีการพัฒนา SmpAllocator ที่ปรับให้เหมาะกับสภาพแวดล้อมแบบ concurrent เพื่อเพิ่มประสิทธิภาพการจัดสรรหน่วยความจำในสภาพแวดล้อม multi-thread ให้สูงสุด
    • มีการพิสูจน์ผลจริงจากเบนช์มาร์กเปรียบเทียบกับ glibc ทั้งด้าน ความเร็วและประสิทธิภาพการใช้ทรัพยากร
    • ส่งผลให้ Zig ถูกมองว่าเป็นจุดเปลี่ยนสำคัญที่ยกระดับประสบการณ์ใช้งานเหนือกว่า C และ libc

24 มกราคม 2025 – มอบสภาพแวดล้อมดีบักเฉพาะสำหรับ Zig

  • Jacob ได้พัฒนา LLDB fork สำหรับ Zig เพื่อเสริมการรองรับการดีบักของแบ็กเอนด์แบบโฮสต์ตัวเอง
    • มีเอกสารวิกิสำหรับวิธีบิลด์และใช้งาน LLDB fork
    • นักพัฒนาที่ใช้แบ็กเอนด์ของ Zig เองจะใช้งานเครื่องมือนี้เพื่อดีบักได้อย่างละเอียดมากขึ้น

บทสรุป

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

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

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

 
GN⁺ 2025-06-09
ความเห็นจาก Hacker News

  • เท่าที่ฉันเข้าใจ Zig กำลังพัฒนาฟีเจอร์ต่าง ๆ ทุกวันเพื่อทำให้ประสบการณ์ฝั่งนักพัฒนาดีขึ้น ตัวอย่างเช่นล่าสุดก็มี PR นี้ ก่อนหน้านี้ Zig ก็เคยมีแผนพัฒนา hot code swapping อยู่แล้ว และด้วยความเร็วในการพัฒนาแบบนี้ก็คาดว่าใน x86_64 ฟีเจอร์นี้น่าจะทำได้ภายใน 1 ปี ความไม่สะดวกที่ฉันรู้สึกมากที่สุดส่วนตัวคือความเร็วของ comptime เคยมีการทดลองรัน DSL brainF** ตอนคอมไพล์ ซึ่งช้ามากจริง ๆ (แต่ก็เป็นการทดลองที่สนุก) เลยสงสัยว่าส่วนนี้ของคอมไพเลอร์จะได้รับการปรับปรุงเมื่อไร และก็ตื่นเต้นมากกับแบ็กเอนด์ใหม่ ๆ รวมถึงอยากลองทำแบ็กเอนด์ URCL ของตัวเองสำหรับ Zig ด้วย 😉

    • เรื่องการปรับปรุงประสิทธิภาพของ comptime นั้น รู้อยู่แล้วว่าต้องทำอะไร และเมื่อหลายปีก่อนก็เคยเริ่มทำ branch ที่เกี่ยวข้องไว้แล้ว แต่ส่วนนี้ต้องรีเวิร์กโค้ด semantic analysis ในระดับที่มีนัยสำคัญ จึงเป็นหนึ่งในงานสำคัญที่ยังต้องแข่งขันกับลำดับความสำคัญอื่น ๆ

    • hot code swapping เป็นฟีเจอร์ที่จะเปลี่ยนเกมมากในวงการพัฒนาเกม สิ่งที่น่าทึ่งคือใน Zig มันถูกวางแผนให้รองรับได้พื้นฐานเพียงผ่าน compiler flag ซึ่งเป็นสิ่งที่แทบทำไม่ได้เลยกับ clang

    • ยังไม่ได้ลงลึกกับ URCL มากนัก แต่สิ่งนี้กำลังพาฉันไปสู่โพรงกระต่ายอีกอันหนึ่ง ทำให้นึกภาพสถานการณ์ประหลาดสุด ๆ ที่ IR ซึ่งถูกสร้างมาสำหรับ Minecraft กลายเป็น target การคอมไพล์จริงของภาษา

    • สงสัยว่าการสร้าง custom backend นั้นง่ายแค่ไหน ยังไม่ได้ลองทำเอง แต่ก็อยากทดลองทำแบ็กเอนด์ที่รับ AIR แล้วสร้างรายงาน memory safety ได้ เช่นตรวจการใช้ค่าที่ไม่ได้กำหนด, stack pointer escape, use-after-free, double free, alias xor mut เป็นต้น

    • สงสัยเหมือนกันว่า comptime ช้าจริงจนเป็นปัญหาหรือไม่ ฉันกำลังทำไลบรารี JSON-RPC โดยใช้ comptime หนักมากตอนคอมไพล์เพื่อ dispatch JSON ไปยังฟังก์ชันตามต้องการ เพราะด้วย static type ที่เข้มแข็งของ Zig จึงไม่สามารถ dispatch แบบไดนามิกไปยังฟังก์ชันที่มีพารามิเตอร์ตามอำเภอใจตอนรันไทม์ได้ เลยจำเป็นต้องสร้างการแมปชนิดของฟังก์ชันตอนคอมไพล์แทน สิ่งที่กังวลคือแบบนี้โค้ดที่ผ่าน comptime จะถูกคัดลอกสำหรับแต่ละฟังก์ชัน ทำให้ขนาดไบนารีโตขึ้นอย่างหลีกเลี่ยงไม่ได้

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

  • มีการกล่าวว่าในโปรเจกต์ใหญ่ระดับ Zig compiler เวลา build ลดจาก 75 วินาทีเหลือ 20 วินาที
    ฉันอยากรู้มากว่าจากนี้จะปรับปรุงไปได้ไกลแค่ไหน รู้สึกว่านักพัฒนา Zig ฉลาดมาก ๆ
    สงสัยว่าระบบ package management เป็นแบบไหน ก่อนหน้านี้เคยพยายามทำแอป QuickJS + SDL3 ด้วย Zig แต่สุดท้ายแพ้ความซับซ้อนของ C++ เลยไปใช้ Rust แทน ยังอยากลองอีกครั้งกับ Zig

    • package management ของ Zig ค่อนข้าง manual กว่า Rust โดยดึง URL ของแพ็กเกจจาก CLI โดยตรง แล้ว import โมดูลใน build script ข้อดีของวิธีนี้คือสามารถใช้ archive อะไรก็ได้เป็น dependency ได้ง่าย และแพ็กเกจ C library สำหรับ Zig หลายตัวก็เป็นแค่การผูกเข้ากับ release แบบ untouched (tarball) จาก build script โดยตรง แต่สำหรับมือใหม่อาจจะซับซ้อนนิดหน่อย
      สำหรับ SDL3 มีทั้ง native Zig wrapper (https://github.com/Gota7/zig-sdl3) และ https://github.com/castholm/SDL ที่เรียบง่ายกว่า โดยเป็นการทำ C library/API ให้ใช้งานในสไตล์ Zig
      QuickJS รองรับเฉพาะ C API (https://github.com/allyourcodebase/quickjs-ng) เท่านั้น
      Zig ทำให้การใช้แพ็กเกจ C โดยตรงง่ายมาก แต่เพราะระบบ type เข้มงวด เวลาจัดการ API อาจต้องทำ type cast บ่อย

    • dmd D compiler สามารถคอมไพล์ตัวเองในโหมด debug ได้ในเวลาประมาณ 18.4 วินาที
      ซีพียูของฉันเป็น AMD Athlon 64 X2 (4400+) รุ่นเก่ามาก แต่เร็วพอจนยังไม่เคยอัปเกรดเลย
      (มีรายการข้อมูล CPU แบบละเอียดประกอบ)

    • สงสัยว่ามีไกด์สำหรับ build Zig ให้เสร็จใน 20 วินาทีเพื่อให้ development cycle เร็วขึ้นไหม ก่อนหน้านี้ตอน build Zig เคยเจอหลาย stage โดยเฉพาะการ bootstrap จาก WASM ซึ่งใช้เวลานานมาก

    • น่าทึ่งมากที่ Zig ยังสามารถคอมไพล์ตัวเองได้ใน 75 วินาทีทั้งที่ยังใช้ LLVM อยู่

  • ไม่ได้ตั้งใจจะเรียกร้องเกินเลยจาก Zig เลย และก็รู้ดีว่าเป็นโอเพนซอร์ส แต่สิ่งที่สนใจมากที่สุดคือกำหนดการออก 1.0 ที่สมจริง
    Zig เป็นภาษาที่เกือบจะมีทุกอย่างที่ฉันอยากได้จากภาษา low-level อย่างสมบูรณ์แบบ และตอนนี้ก็รอแค่ให้มันเสถียร
    อีกทั้งยังชื่นชมปรัชญาการออกแบบแบบมินิมัลลิสต์ของ Zig อย่างจริงใจ

    • เท่าที่ทราบ โปรเจกต์ใช้งานจริงอย่าง tigerbeetle มักจะล็อกใช้เวอร์ชัน release และใช้ nightly เพื่อการทดลองเท่านั้น

  • ในฐานะมือใหม่มาก ๆ สงสัยว่า Zig มีข้อได้เปรียบอะไรเมื่อเทียบกับภาษาอื่น ฉันเข้าใจมันว่าเป็น C ที่ทันสมัยกว่า แต่อยากรู้ว่าความ “ทันสมัย” นั้นหมายถึงอะไรบ้าง

    • นี่คือข้อดีบางอย่างที่นึกออกทันที
      • ระบบ build แบบรวมศูนย์โดยไม่ต้องประกอบหลายเครื่องมือและหลายภาษาเข้าด้วยกัน
      • มี slice ที่รู้ความยาวชัดเจน แทนอาร์เรย์ของ C ที่เสี่ยง buffer overflow
      • มี optional type ที่ชัดเจนและไม่ยอมให้มี null pointer โดยปริยาย (ถ้าต้องการจะต้องแสดงใน type อย่างชัดเจน)
      • มี enum, tagged union และบังคับ exhaustive check ใน switch
      • การจัดการ error ชัดเจน (ค่อนข้างสไตล์ Rust) ถ้าฟังก์ชันสามารถคืน error ได้ ผู้เรียกจะมองข้ามไม่ได้ ไม่เหมือน C ที่ปล่อยผ่านการไม่ตรวจค่าที่คืนมาได้ แม้จะน่าเสียดายที่ยังไม่มีไวยากรณ์มาตรฐานสำหรับคืนทั้ง error และข้อมูลพร้อมกัน
      • มีบล็อก defer, errdefer สำหรับทำงาน cleanup อัตโนมัติเมื่อฟังก์ชันคืนค่าหรือเกิด error
      • ใช้ comptime และ type reflection (@typeInfo ฯลฯ) ในการสร้างโค้ดแทน macro
      • ผู้เรียกเป็นผู้จัดการ allocator เองโดยตรง (จึงมีอำนาจตัดสินใจเรื่องตำแหน่งและวิธีจัดสรรหน่วยความจำมากขึ้น)
      • หากใช้ GeneralPurposeAllocator (สำหรับมือใหม่) จะติดตาม memory leak ได้ง่ายขึ้น
        ฉันไม่ค่อยคุ้นกับ C และรู้สึกว่าหลายอย่างใน C ทั้งไม่สมเหตุสมผลและไม่ตรงสัญชาตญาณจน low-level programming ดูเข้าถึงยากเสมอ แต่ Zig เป็นภาษาตัวแรกที่ทำให้ฉันรู้สึกสนุกและสนใจงาน systems programming จริง ๆ

  • สงสัยว่ามีไกด์สำหรับ build Zig ให้เสร็จภายใน 20 วินาทีไหม อยากให้ development cycle เร็วขึ้น แต่เคยรู้สึกว่าการ build stage1/2/3 ใช้เวลานานมากจนมีส่วนร่วมได้ไม่ง่าย

  • ถ้า build hello world ใน Zig ด้วย zig init แล้วได้ขนาด 9.3MB การใช้แฟลก -Doptimize=ReleaseSmall จะลดเหลือ 7.6KB
    ต่างกันเกิน 1000 เท่าจากการเปลี่ยนแฟลกเพียงตัวเดียว

    • จริง ๆ แล้ว 82% ของความต่างนั้นมาจาก debug information
      -OReleaseSmall -fno-strip จะได้ 580KB และ -ODebug -fstrip อาจลงมาเหลือ 1.4MB
      Zig backend สำหรับ x86 มอบประสบการณ์ดีบักที่ดีกว่ามากผ่าน LLDB fork สำหรับ Zig โดยเฉพาะ
      ตอนนี้จำไม่ได้ว่าระหว่างดีบัก logic ของ comptime สามารถดูแบบ step-by-step ได้หรือยัง แต่เพิ่งเป็นประเด็นที่มีการคุยกันเมื่อไม่นานมานี้

  • คิดว่า Julia อาจคุ้มที่จะพิจารณาใช้ Zig เป็นคอมไพเลอร์เพื่อแลกกับข้อได้เปรียบด้านประสิทธิภาพ และยังจำความกังวลของนักพัฒนา Julia ที่กลัว performance regression ทุกครั้งที่ออกรุ่นใหม่ได้ดี

    • Julia ผูกกับ LLVM ค่อนข้างแน่นในทางปฏิบัติ หลายส่วนของ ecosystem พึ่งพา LLVM intrinsics, autodiff (Enzyme), การคอมไพล์สำหรับ GPU เป็นต้น
      ตัวคอมไพเลอร์เองกำลังถูกทำให้ retarget ได้มากขึ้น และส่วนนี้ก็ยังเป็นหัวข้อวิจัยที่คึกคักอยู่
      ในอนาคตอาจจินตนาการได้ว่า Zig จะเป็นคอมไพเลอร์ทางเลือกสำหรับบางส่วนของภาษา

    • มีความเห็นว่า LLVM เองก็เป็น public API ของ Julia ไปแล้ว จริง ๆ ก็มีมาโครอย่าง @code_llvm ที่แสดง IR ออกมาตรง ๆ ด้วย

    • แน่นอนว่าน่าจะช่วยลดเวลา compile ได้ แต่ฝั่ง Julia เองก็ยังมีงานต้องทำอีกมาก
      เช่น ทำ compile cache ให้ละเอียดขึ้น, เครื่องมือป้องกัน invalidation, เอา world splitting optimization ออก, ใช้ multithreading ในคอมไพเลอร์ให้มากขึ้น, precompile อัตโนมัติสำหรับบาง signature หรือฟีเจอร์ compile/hot swap แบบ lazy เป็นต้น

  • นี่เป็นความก้าวหน้าครั้งใหญ่ของ Zig และน่าจะกลายเป็นจุดสร้างความแตกต่างหลักเมื่อเทียบกับ Rust ในอนาคต อีกอย่างคือ ฉันเป็นคนเขียนโค้ดเรนเดอร์ส่วนใหญ่ของเครื่องมือวิเคราะห์ประสิทธิภาพนี้เอง และก็ดีใจที่โค้ดของฉันถูกใช้อย่างแพร่หลายบนอินเทอร์เน็ต
    ลิงก์โปรเจกต์ poop

    • Rust เองก็มีความพยายามคล้ายกันโดยใช้ cranelift
      ดู rustc_codegen_cranelift

  • คิดว่านี่แหละคือหนึ่งในเงื่อนไขตั้งต้นสำหรับการนำ async/await กลับเข้ามาใน Zig อีกครั้ง
    FAQ ทางการของ Zig เรื่อง async ก็น่าอ่านเช่นกัน

    • ส่วนนี้เคลียร์กันหมดแล้ว และภายใน 2-3 เดือนข้างหน้าน่าจะมีอัปเดตที่น่าสนใจออกมา ตอนนี้กำลังรีเวิร์กระบบ I/O ทั้งหมดใหม่ราวกับสร้าง standard library ขึ้นมาใหม่

    • จากลิงก์ดูเหมือนว่า async อาจจะไม่กลับมาอีกเลย หรืออย่างน้อยก็คงยังเป็นไปไม่ได้จนถึงปี 2028