Buz – ฟอร์กของ Bun ที่รองรับ Zig รุ่นล่าสุดและ incremental build ต่ำกว่า 1 วินาที

 (ziggit.dev)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Buz เป็นฟอร์กระยะเริ่มต้นที่แยกมาจากคอมมิตก่อนหน้าการเขียน Bun ใหม่ด้วย Rust โดยกำลังพัฒนาให้เป็น ทางเลือกทดแทนที่เข้ากันได้ บน Zig รุ่นล่าสุด
  • โครงการได้ย้ายกราฟการบิลด์ทั้งหมด รวมถึงซอร์สที่ vendoring ของ JavaScriptCore ไปไว้ใน build.zig และใช้แพตช์ขนาดเล็กกับ Zig เพื่อทำให้ incremental build ต่ำกว่า 1 วินาที
  • ได้นำเทสต์สำหรับฟีเจอร์ใหม่และการแก้บั๊กจาก Bun เวอร์ชัน Rust มาใช้ แต่ยังมีเทสต์ที่ไม่ผ่านอีกมาก จึงต้องตามฟีเจอร์ upstream และการเปลี่ยนแปลงของ JavaScriptCore ต่อไป
  • มีการ ลบโค้ดที่ไม่ได้ใช้งานกว่า 11,000 บรรทัด และแก้บั๊กหลายจุดระหว่างปรับบางส่วนของ implementation ให้ทันสมัยขึ้นโดยยึด Zig standard library มากขึ้น
  • ยังไม่พร้อมใช้งานในโปรดักชัน และมีเป้าหมายระยะยาวที่จะลดหนี้ทางเทคนิคโดยใช้ทั้ง LLM และการกำกับดูแลโดยมนุษย์ เพื่อสร้าง โค้ดเบสที่ดูแลรักษาได้ดีแม้ไม่ต้องพึ่ง LLM

เป้าหมายของโครงการและสถานะการพัฒนา

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

การพอร์ตไปยัง Zig รุ่นล่าสุดและ incremental build

  • พอร์ต Bun ไปยัง Zig upstream ปัจจุบัน และใช้แพตช์ขนาดเล็กกับ Zig เพื่อรองรับ incremental rebuild
  • รวมกราฟการบิลด์ทั้งหมดไว้ใน build.zig รวมถึงซอร์สที่ vendoring ของ JavaScriptCore
  • ด้วยการตั้งค่านี้ เวลาสำหรับ incremental build ลดลงเหลือ ต่ำกว่า 1 วินาที ทำให้รอบการพัฒนาทดลองทำได้เร็วขึ้น
  • ในโปรเจ็กต์มี Zig master submodule ที่ใช้แพตช์ incremental build รวมอยู่ด้วย
  • และยังสามารถบิลด์ได้ตามปกติบนคอมมิต Zig upstream 2b1c663 ในเวลานั้น

การทดสอบความเข้ากันได้และการตาม upstream

  • ได้นำเทสต์ที่เพิ่มเข้ามาใน Bun เวอร์ชัน Rust มาใช้ ซึ่งมีเทสต์สำหรับตรวจสอบ ฟีเจอร์ใหม่และการแก้บั๊ก อยู่จำนวนมาก
  • ยังมีเทสต์อีกมากที่ยังไม่ผ่าน จึงต้องตาม Bun upstream ต่อไป
  • ดำเนินการจัดระเบียบโค้ดและ ลดหนี้ทางเทคนิค ควบคู่ไปกับการรักษาความเข้ากันได้ของฟังก์ชัน
  • รวมถึงต้องติดตามการเปลี่ยนแปลงของ JavaScriptCore อย่างต่อเนื่องด้วย

การจัดระเบียบและทำโค้ดเบสให้ทันสมัย

  • ลบโค้ดที่ไม่ได้ถูกใช้งานใน Bun เลยออกไป กว่า 11,000 บรรทัด
  • เขียนและปรับบางส่วนของโค้ดให้ทันสมัยขึ้น พร้อมเพิ่มการใช้ Zig standard library
  • ระหว่างการจัดระเบียบและปรับให้ทันสมัย ก็ได้แก้บั๊กหลายจุดไปพร้อมกัน
  • มองว่าโค้ดเบสเดิมของ Bun มีขนาดราว 600,000 บรรทัด และกว่าจะจัดให้เป็นระเบียบได้ จำเป็นต้องเขียนระบบย่อยใหม่อีกจำนวนมาก

แนวทางการใช้ LLM และการรับคอนทริบิวชัน

  • มีแผนจะ ใช้ LLM อย่างกว้างขวาง เพื่อจัดระเบียบโค้ดเดิมที่ซับซ้อน โดยใช้ร่วมกับการกำกับดูแลโดยมนุษย์และแนวปฏิบัติการพัฒนาที่ดีกว่าเดิม
  • จะยังไม่รับคอนทริบิวชันที่มนุษย์เขียนเอง จนกว่าจะเห็นว่าโค้ดเบสถูกจัดระเบียบดีพอ
  • ให้ความสำคัญกับการลดหนี้ทางเทคนิคและการเขียนโค้ด Zig ที่เป็นธรรมชาติเป็นอันดับแรก พร้อมตั้งเป้าให้โค้ดเบสสามารถออกเป็น ทางเลือกทดแทนที่เข้ากันได้กับ Rust Bun 1.4.0 ภายในไม่กี่สัปดาห์หรือไม่กี่เดือน
  • ต้องการความช่วยเหลือจากนักพัฒนาที่สามารถใช้ Sol หรือ Fable ได้
  • ในระยะยาว ต้องการสร้างโค้ดเบสที่ดูแลรักษาได้ง่ายโดยไม่ต้องพึ่ง LLM และยกระดับทักษะด้าน Zig ไปพร้อมกัน

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

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

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News
  • ข้อเท็จจริงที่น่าสนใจที่สุดของฟอร์กนี้คือมันพิสูจน์ว่า Bun เองก็สามารถบิลด์ได้เร็วตั้งนานแล้ว
    ตอนนี้ Zig incremental compilation ยังไม่รองรับ aarch64 และ binary patching ก็ทำได้แค่บน Linux linker แต่การรองรับแพลตฟอร์มหลักน่าจะเป็นแค่เรื่องของเวลา
    • พอนึกถึงกระแสดราม่ารอบการฟอร์กคอมไพเลอร์ Zig เพื่อเร่งความเร็วในการบิลด์ ก็แปลกใจที่นี่ไม่ใช่คอมเมนต์บนสุด
      ความจริงที่ว่า ทีมคนเดียวทำบิลด์ 1 วินาทีได้ แสดงว่าบิลด์ที่ช้าเป็นผลจากแนวปฏิบัติการพัฒนาที่ไม่ใส่ใจ และเวลาที่ใช้ไปกับการทำฟอร์กก็คือการจัดสรรทรัพยากรที่ผิดทางโดยสิ้นเชิง
  • เอาโค้ดที่ LLM ทำพังมาจัดระเบียบใหม่ด้วย LLM อีกตัว เหมือนเราไปถึงจุดสูงสุดของเทคโนโลยีในปี 2026 แล้ว
    • จนถึงตอนนี้ มนุษย์ก็จัดการโค้ดที่มนุษย์ทำพังมาตลอดอยู่แล้ว ดังนั้นมันก็ไม่ได้ขัดแย้งในเชิงตรรกะ
    • ผลลัพธ์ของ LLM จะดีได้เท่ากับ ความสามารถของผู้ใช้ ที่สั่งมัน
    • ผมยังสงสัยเรื่อง AI แต่ก็พร้อมจะใช้ ถ้า LLM สามารถเก็บงานผลลัพธ์ของตัวเองได้จริง นี่อาจเปลี่ยนเกมได้เลย
    • ผมก็คิดเหมือนกัน แต่ถัดจากนั้นเขาก็บอกทันทีว่า มนุษย์จะเป็นคนคุมเกม, ลด technical debt และเขียนโค้ด Zig แบบที่ยืดหยุ่น เพื่อให้ได้ codebase ที่แทน Rust Bun 1.4.0 ได้ภายในไม่กี่สัปดาห์หรือไม่กี่เดือน
      สุดท้ายก็ดูเหมือนหมายถึงการสั่งให้มากขึ้นหรือสั่งให้ดีขึ้น โครงสร้างโค้ดก็ดูจะเป็นเรื่องรสนิยมด้วย เมื่อวานผมเพิ่งคุยแบบงง ๆ กับเพื่อนที่ยืนกรานว่าการจัดการ HTTP request หนึ่งครั้งต้องใช้ backend process ถึงสี่ตัว
    • ตั้งแต่แรกมันก็ไปในทิศทางนี้อยู่แล้ว พอผลลัพธ์จาก LLM ที่พังและมีแค่รูปร่างเหมือนซอฟต์แวร์ แต่ มนุษย์อ่านหรือเข้าใจไม่ได้ กลายมาเป็นโค้ด สุดท้ายโค้ดทั้งหมดก็เลี่ยงไม่ได้ที่จะถูกสร้างขึ้นมา เพื่อให้เครื่องอ่านและเขียน
      ยุคที่มนุษย์เข้ามาแทรกแซงเป็นเพียงช่วงเปลี่ยนผ่านชั่วคราวตั้งแต่แรก
  • น่าทึ่งที่แค่การลบ โค้ดตาย 11,000 บรรทัด ออกจาก Bun และปรับให้ทันสมัยขึ้นด้วยการใช้ standard library มากขึ้น ก็แก้บั๊กได้ตั้งมากมาย
    มันเป็นเรื่องปกติในโปรเจกต์ใหญ่หรือว่าผมแค่ไม่เคยรู้มาก่อน
    • ทั้งหมดมี 600,000 บรรทัด ดังนั้นโค้ดตายคิดเป็น ประมาณ 1.8% ยิ่ง codebase ใหญ่ก็ยิ่งต้องมองภาพกว้างเพื่อจะตัดสินว่าโค้ดไม่ได้ถูกใช้งานจริงหรือไม่ และเมื่อเวลาผ่านไปการเปลี่ยนแปลงที่ห่างไกลกันก็อาจทำให้เกิดโค้ดตายได้ จึงยิ่งพบได้บ่อย
      ยังไม่ชัดว่าเป็นโค้ดที่เห็นชัดแบบ if (false) { dead_code(); } หรือเป็นโค้ดที่ dynamic dispatch ไปถึงได้แต่ตามตรรกะแล้วไม่มีวันถูกเรียก ถ้าเป็นอย่างแรก 1.8% ก็ถือว่าสูง แต่ถ้าเป็นอย่างหลังก็อาจต่ำก็ได้ และหลายโปรเจกต์ก็มีโค้ดที่แทบไม่มีวันรันจริงสะสมอยู่หลัง feature flag เก่า ๆ
      โค้ดตายจำนวนน้อยอย่าง utility ง่าย ๆ หรือ generated code อาจปล่อยไว้ได้ แต่บางครั้งการลบมันก็ทำให้เกิดการลบต่อเนื่องและการทำให้ง่ายลงเป็นลูกโซ่
    • ที่บริษัทเก่า ผมเคย ย่อคอมโพเนนต์ 10,000 บรรทัดให้เหลือ 2,000 บรรทัด พร้อมแก้บั๊กสำคัญทั้งหมด
      พูดตามตรงมันไม่ใช่โค้ดตายเสียทีเดียว แต่พอจัดการ abstraction ที่ผิดพลาดเล็ก ๆ จุดหนึ่ง โอกาสในการเก็บงานต่อก็จะเปิดตามมาเรื่อย ๆ จนสุดท้ายเหลือซอฟต์แวร์ที่ทำเฉพาะสิ่งที่ตั้งใจจะให้ทำ codebase มักพองตัวขึ้นตามเวลา ดังนั้นในขนาดของ Bun การเจอแค่ 11,000 บรรทัดกลับน่าประหลาดใจกว่า
    • คอมไพเลอร์ Zig ใช้ lazy compilation จึงไม่ตรวจจับฟังก์ชันตายที่ไม่ได้ถูกเรียกจากที่ไหนเลยในฟังก์ชันที่คอมไพล์แล้ว
    • ถ้าดูจากวิธีพัฒนาของ Bun มันมีน้อยกว่าที่คิด และน่าจะยังเหลืออยู่ใน codebase มากกว่านี้อีกมาก
    • กลับกัน ผมว่าการแปลกใจกับโค้ดตายระดับนี้ใน codebase ขนาดใหญ่ต่างหากที่น่าแปลก มันมีปริมาณพอ ๆ กับ PR ขนาดปกติแค่ประมาณ 10 อันเท่านั้น
  • อยากรู้จริง ๆ ว่าต้องมีประสบการณ์เขียนโปรแกรมมากแค่ไหนถึงจะมองว่า โค้ดตาย 11,000 บรรทัด เป็นเรื่องผิดปกติขนาดนั้น
    • ผมมีประสบการณ์เกิน 10 ปี ผมหมายถึง โค้ดตายแบบชัดเจน ที่ไม่มีที่ไหนเรียกใช้งานเลย และสงสัยว่ามีโปรเจกต์อื่นมากขนาดนี้เหมือนกันหรือเปล่า
  • ทุกโปรเจกต์ที่เขียนโค้ดแบบ agent-centric จะมีการสั่นแบบ ติ๊กต็อก ระหว่างการพัฒนาฟีเจอร์กับการดูแลโค้ด
    ช่วงติ๊กคือเพิ่มฟีเจอร์อย่างรวดเร็วให้ได้เวอร์ชันที่ถูกต้องแต่รกสุด ๆ ส่วนช่วงต็อกคือย่อยและจัดระเบียบผลลัพธ์เพื่อปรับปรุงประสิทธิภาพ ความสามารถในการดูแลรักษา และความเปราะบางต่อการเปลี่ยนแปลง
    ผมมักใช้เวลา 1 วันทำแอปที่ใช้งานได้ด้วย vibe coding แล้วใช้เวลาอีก 1 สัปดาห์ทำให้มันกลายเป็นโปรเจกต์ที่เพิ่มฟีเจอร์ต่อได้โดยไม่พังเหมือนบ้านไพ่ ก่อนมี AI ก็คล้ายกัน แต่ developer มืออาชีพมี mental model ของระบบที่แข็งแรงกว่าและทำงานช้ากว่า จึงไม่ได้สลับรุนแรงขนาดนี้
    • สุดท้ายก็ต้องเปิดดูโค้ดด้วยตัวเองว่า logic ไม่ได้ถูกทำซ้ำกระจัดกระจายไปทั่ว และ ดูแลรักษาได้จริงหรือไม่
      โมเดลสำหรับเขียนโค้ดมีแนวโน้มสูงที่จะเลือกทางลัดที่ทำลาย encapsulation หรือคัดลอกโค้ดที่ไม่ควรถูกทำซ้ำ
  • ผมอยากเรียกสิ่งนี้ว่า การเขียนโปรแกรมเพื่อโชว์ประสิทธิภาพ ผมชอบประสิทธิภาพและอยากให้เวลา build ใกล้ 0 วินาทีเหมือนกัน แต่ตอนนี้เราน่าจะเข้าสู่ช่วงผลตอบแทนลดลงแล้ว และคอขวดปัจจุบันคงไม่ใช่เวลา build
    • นักพัฒนา Bun คงไม่เห็นด้วย เพราะพวกเขาเจอกับการรอนานด้วยตัวเองในสถานการณ์ที่ใช้ incremental compilation ไม่ได้: https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
      ในโปรเจกต์ใหญ่ เราเสียเวลารอหลาย ๆ นาทีทุกครั้งที่รันทดสอบหรือตรวจ semantic error ไม่ได้ ดังนั้น เวลา build คือคอขวดที่ชัดเจน
    • สำหรับโปรเจกต์แบบนี้ การ build ให้เร็วเป็นสิ่งจำเป็น และผมมองว่าเป็นขั้นสำคัญที่ช่วยให้ดูแลรักษาได้ง่ายขึ้น
  • ถ้า Bun อยู่ในมือคนที่ใส่ใจคุณภาพโค้ดก็ยินดีต้อนรับ แต่ก็เป็น งานระดับเฮอร์คิวลิส
    • ผมว่าใกล้เคียงกับ งานแบบซิซิฟัส ที่ต้องทำซ้ำไม่รู้จบมากกว่า
  • ในทางตรงกันข้าม ผมก็อยากเห็น ฟอร์ก Zig ที่รับเฉพาะ contribution จาก AI
    ไม่ใช่เพราะเชียร์ AI มากเป็นพิเศษ แต่ในฐานะงาน conceptual art หรือการทดลอง การดูว่าทั้งสองโปรเจกต์วิวัฒน์ต่างกันอย่างไรคงน่าสนุกดี
  • ยังมี Cruller ที่เกี่ยวข้องกันมาก ซึ่งก็ใช้ codebase ของ Bun ก่อนการเขียนใหม่ แต่โฟกัสเฉพาะส่วน runtime สำหรับ production
    ลิงก์: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
    กระทู้ HN: https://news.ycombinator.com/item?id=49017344
  • ผมไม่เข้าใจว่าทำไม Bun ถึงถูกพูดถึงมากขนาดนี้ หรือแค่ใช้ Node + npm + Vitest + Vite ไปก็ไม่ได้เหรอ
    • มีโปรเจกต์ Nub ที่พยายามเอาข้อดีของ Bun มาให้ Node และอาจช่วยให้เห็นด้วยว่าทำไมคนถึงชอบ Bun รวมถึงช่องว่างของเครื่องมือเดิม
      https://nubjs.com
    • ก็เพราะต้องไล่ชื่อมาสี่ตัวนี่แหละถึงกลายเป็นประเด็น แทนที่จะต้องประกอบเครื่องมือจำนวนมากเข้าด้วยกัน คุณสามารถใช้ runtime เดียว ที่จัดการทุกอย่างที่ต้องการได้
      การประกอบเครื่องมือเฉพาะทางเข้าด้วยกันก็ไม่ใช่ปัญหา แต่การที่ทุกอย่างใช้งานได้ตั้งแต่ค่าเริ่มต้นนั้นสะดวกมาก Bun bundler ยังมี runtime API ด้วย ทำให้ process เดียวกับที่เสิร์ฟ asset สามารถประสานงานกับ bundler ภายนอก หรือ bundle จากในหน่วยความจำได้ทันทีโดยไม่ต้องเขียนไฟล์ static ลงดิสก์
    • การที่คุณต้องไล่รายชื่อเครื่องมือถึงสี่ตัวก็ชี้ให้เห็นอยู่แล้วว่าสภาพเดิมมันแย่แค่ไหน
    • ตอนนี้ก็ไม่แน่ชัดแล้วว่าเรายังมีเหตุผลอะไรที่ต้อง ใช้ npm ต่อไป