PR การเขียน Bun ใหม่ด้วย Rust ถูกรวมแล้ว

• PR #30412 เป็นการเปลี่ยนแปลงสำหรับ การเขียน Bun ใหม่ด้วย Rust และถูก merge จากสาขา claude/phase-a-port เข้า main เมื่อวันที่ 14 พฤษภาคม 2026
• ขนาดของการเปลี่ยนแปลงแสดงไว้ที่ 6,755 commits, 2,188 ไฟล์, และ +1,009,257/-4,024 บรรทัด
• Jarred-Sumner ระบุว่าจะมี บทความบล็อก ที่มีรายละเอียดเพิ่มเติมออกมาในเร็ว ๆ นี้
• มีการอธิบายว่าการเปลี่ยนแปลงนี้ผ่าน test suite เดิมของ Bun บนทุกแพลตฟอร์ม และแก้ memory leak หลายจุดรวมถึงการทดสอบที่ไม่เสถียร
• ระบุว่าขนาดไบนารี ลดลง 3MB~8MB และผล benchmark อยู่ในช่วงที่เป็นกลางหรือเร็วขึ้น
• เหตุผลที่สำคัญที่สุดคือ ทีมจะสามารถจับและป้องกัน memory bug ที่ใช้เวลาในการพัฒนาและดีบักมาหลายปีได้ด้วยเครื่องมือช่วยจากคอมไพเลอร์
• มีการอธิบายว่า codebase โดยรวมแทบจะเหมือนเดิม และ สถาปัตยกรรมกับโครงสร้างข้อมูล ก็ยังคงไว้เช่นเดิม
• Bun ยังคงใช้ไลบรารีจากภายนอกน้อยมาก และระบุชัดว่าไม่ได้ใช้ async Rust
• ผู้ใช้สามารถทดลองการเปลี่ยนแปลงนี้ได้ด้วย bun upgrade --canary
• Jarred-Sumner ขอให้รายงาน issue หากพบปัญหา และระบุว่าอาจล็อกเธรดหากการสนทนาร้อนแรงเกินไป
• ก่อนจะเข้าสู่เวอร์ชันที่ไม่ใช่ canary ยังเหลือ งานปรับแต่งประสิทธิภาพ ที่ต้องทำ
• ยังเหลืองานเก็บกวาดโค้ด ซึ่งจะดำเนินการต่อในชุด PR ถัดไป

[xguru]

ว้าว PR ขนาดล้านบรรทัดถูก merge แล้ว จาก Zig ไป Rust แบบย้ายทีเดียวเลยนะ ก่อนหน้านี้ยังพูดอยู่เลยว่าไม่รู้ว่าจะ merge ได้ไหม~~ แต่แค่สัปดาห์เดียวก็เปลี่ยนภาษาของโค้ดที่ทำงานได้ดีอยู่แล้วในทีเดียวเลย 555 รู้สึกเหมือนกำลังมีอะไรระดับหมุดหมายเกิดขึ้นเพราะการเขียนโค้ดแบบมี AI assist.

[heycalmdown]

จริงเหรอ ก่อนหน้านี้ก็บอกว่าแค่ทดสอบเฉยๆ และมีโอกาสสูงว่าจะไม่ใช้

[freedomzero]

พอ Zig ไม่ทำให้ ก็ข้ามไปรัสต์ทันทีแบบกล้ามาก 555

[GN⁺]

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

• ถ้าในการประกาศบอกว่าการรีไรต์ใช้เวลาแค่ 1 สัปดาห์ ก็อดสงสัยไม่ได้ว่าต้องใช้เวลานานแค่ไหนในการเตรียมไฟล์คู่มืออย่างละเอียดมากนี้สำหรับแมปสำนวนของ Zig ไปเป็นสำนวนของ Rust: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
  แถมถ้าดูส่วน Pointers & ownership กับ Collections ก็เหมือนว่าโค้ดเบสของ Bun ได้ใช้ internal smart pointer types อยู่แล้วเพื่อให้แมปกับของฝั่ง Rust แบบ 1:1 ได้ และก็มี Rust crate ชื่อ bun_collections อยู่แล้วด้วย
  การรีไรต์นี้ดูเหมือนจะเตรียมการกันมานานแล้ว และน่าจะเป็นสิ่งที่ทีม Bun เสนอไว้ระหว่างการเจรจาซื้อกิจการกับ Anthropic

  • เวลาอ่านบทความเกี่ยวกับ LLM ก็ไม่รู้เหมือนกันว่าอะไรจริง และคอมเมนต์ Hacker News ตรงนี้ก็เหมือนกัน
    เงินที่เกี่ยวข้องมันมากเกินไป จึงมีแรงจูงใจชัดเจนที่จะฝัง หน้าม้าโฆษณา ไว้ในชุมชน และบางส่วนก็แค่ติดอยู่ในตรรกะแบบแบ่งฝักแบ่งฝ่าย
    ในเมื่อ Anthropic เป็นเจ้าของ Bun แล้ว ก็ยิ่งมีแรงจูงใจมากพอที่จะทำให้งานนี้ดูง่ายกว่าความเป็นจริง
  • ถ้าไม่นับเรื่องอย่างคุณภาพของโค้ด Rust ที่ออกมา จำนวนบรรทัดที่เหมาะสม หรือว่าเดิมทีโค้ดเบสพร้อมกับงานนี้แค่ไหน ผมก็คิดว่าเอกสาร 622 บรรทัดอาจถือเป็นต้นทุนที่ค่อนข้างเล็ก เมื่อเทียบกับการเป็นผลลัพธ์ล่วงหน้าที่ช่วยเพิ่มความสม่ำเสมอหรือคุณภาพให้กับ เอาต์พุตราว 1 ล้านบรรทัด
    ขนาดของเอาต์พุตมันใหญ่มากจนดูเหมือนมีผลคูณอยู่ตรงนี้
    แต่ก็ยังสงสัยว่าการสร้างกฎพวกนี้ต้องอาศัยความรู้ฝังลึกมากแค่ไหน และไฟล์นี้ถูกปรับปรุงวนซ้ำมากน้อยแค่ไหน
    เช่น อยากรู้ว่ากฎพวกนี้มีสัดส่วนเท่าไรที่มาจากเคสล้มเหลวที่เจอระหว่างรอบการแปล
  • ที่บอกว่า using internal smart pointer types that map 1-to-1 to Rust equivalents นั้น smart pointer ไม่ได้เป็นสิ่งที่ Rust เป็นคนคิดค้น
    ถ้าคุณเขียนโค้ดในภาษาอื่นที่มี pointer คุณก็โมเดลชนิดแบบเดียวกันนี้ไว้ในหัวอยู่แล้ว
    แล้วที่บอกว่า Rust crate bun_collections มีอยู่ก่อนแล้วก็ไม่จริง
    มันเป็นแค่ส่วนหนึ่งของ PR ในโค้ดเบส ไม่ได้มีอยู่ก่อนหน้านี้
  • นี่ก็เหมือนกับตอน เดโม gcc ของ Anthropic
    มันจะง่ายมากที่จะลดความสงสัยและเพิ่มบรรยากาศก่อน IPO ถ้าเปิดเผยงานเบื้องหลังที่จำเป็นต่อการผลัก AI ให้ไปถึงจุดนั้นเป็นรีโปแยก และให้ทุกคนทำซ้ำผลลัพธ์ได้
    ท้ายที่สุด สิ่งที่ลูกค้าอยากได้ก็คือโค้ด 1 ล้านบรรทัดที่ใช้งานได้ใน “7 วัน” ไม่ใช่หรือ
    ทุกคนจะได้ลองทำซ้ำในเวิร์กโฟลว์ของตัวเอง และตัวชี้วัดการใช้งาน Anthropic ก็จะสูงขึ้นด้วย
    ถ้ามันเป็นผลลัพธ์ที่เจ๋งจริง ก็น่าจะออกเป็นโพสต์บล็อกพร้อมลิงก์และคำแนะนำไปแล้ว
    ก็เป็นไปได้ว่า ณ ตอนนี้โพสต์บล็อกนั้นกำลังเขียนอยู่ และผมอาจคิดผิดก็ได้
  • ดูเหมือนว่า Bun เวอร์ชัน Zig จะมี pointer types อยู่ 3 แบบที่แมปกับ pointer types เดิมของ Rust ได้อย่างเรียบร้อย และอีก 7~8 แบบที่เหลือน่าจะต้องสร้าง type ใหม่
    นั่นคือแก่นของทฤษฎีสมคบคิดหรือ
    bun_collections เองก็ดูไม่ได้เก่ากว่าคู่มือการพอร์ตไปมากนัก

• [phone] สินะ แปลว่าตอนนี้ Bun มี โค้ด Rust เกิน 1 ล้านบรรทัด แล้ว
  มันเริ่มเข้าใกล้ขนาดของตัวคอมไพเลอร์ Rust เอง
  แต่ BunJS โดยมากก็เป็น wrapper ของ JavaScript interpreter กับการ reimplement ไลบรารี NodeJS ซึ่งก็แทบจะเป็น wrapper ของ Rust standard library อีกที
  BunJS ดูเหมือนกำลังกลายเป็นนกคีรีบูนในเหมืองสำหรับเรื่อง การจัดการความซับซ้อนของซอฟต์แวร์ ในยุค LLM

  • mostly a JavaScript interpreter wrapper ไม่ค่อยแม่นเท่าไร
    Bun เป็นทั้ง JavaScript และ CSS transpiler (parser) แบบมีแบตเตอรี่มาครบ, minifier, bundler, package manager แบบ npm, test runner แบบ Jest และยังมี runtime API อย่างไคลเอนต์ Postgres, MySQL, Redis ที่ฝังมาในตัวด้วย
    ดังนั้นจำนวนโค้ดเยอะมากจึงเป็นเรื่องธรรมดา
  • Bun ไม่ใช่ JavaScript interpreter แต่ใกล้เคียงกับการ reimplement ไลบรารี NodeJS และไลบรารีอื่นอีกหลายตัวมากกว่า
    Bun ใช้ JavaScriptCore เป็น JS engine ดังนั้นตัว Bun เองไม่ได้ หรืออย่างน้อยก็ไม่ควรจะต้อง ทำการ parse, interpret หรือ JIT JavaScript
    แก้ไข: ผมอ่านผิดไป เขาบอกว่า “JavaScript interpreter wrapper” งั้นก็ถือว่าพูดถูก
  • ไม่แน่ใจว่าที่ iOS มันตรวจจับเป็นเบอร์โทรศัพท์เพราะมี + ข้างหน้าหรือมีปัจจัยอื่นด้วย แต่บนมือถือ จำนวนบรรทัดที่เปลี่ยน จะถูกขีดเส้นใต้และกดเพื่อโทรออกได้
    ถ้าเป็นเพราะขนาด diff จริงก็ค่อนข้างขำดี
  • โค้ดเบส Bun ก่อนรีไรต์ก็มี จำนวนบรรทัดพอๆ กัน อยู่แล้ว
    ดังนั้นผลลัพธ์จากการรีไรต์ออกมาเป็น LOC ใกล้เคียงกันจึงไม่ใช่เรื่องแปลก
  • การมี wrapper ของ JavaScriptCore ที่ยาวถึง 1 ล้านบรรทัด เป็นตัวอย่างชั้นดีของสิ่งที่เอเจนต์ทำได้

• ผลของ $ rg 'unsafe [{]' src/ | wc -l คือ 10428 และผลของ $ rg 'unsafe [{]' src/ -l | wc -l คือ 736
  แยกตามภาษาได้เป็น Rust 1443 ไฟล์ 929213 บรรทัด, Zig 1298 ไฟล์ 711112 บรรทัด, TypeScript 2604 ไฟล์ 654684 บรรทัด, JavaScript 4370 ไฟล์ 364928 บรรทัด, C 111 ไฟล์ 305123 บรรทัด, C++ 586 ไฟล์ 262475 บรรทัด, C Header 779 ไฟล์ 100979 บรรทัด

  • ข้อดีคือใน Rust คุณสามารถค้นหาโค้ดที่อาจไม่ปลอดภัยแบบนี้ได้ชัดเจน
    แล้วใน Zig จะค้นหา โค้ดที่ไม่ปลอดภัย ยังไงล่ะ
    หรือว่าต้องสมมติว่ามันอยู่ทุกที่อยู่แล้ว
  • ถ้าครึ่งหนึ่งของไฟล์มีคีย์เวิร์ด unsafe อยู่ มันก็ดูไม่เหมือนการรีไรต์ที่ดีเท่าไร
    ถ้าเกือบครึ่งหนึ่งของโค้ดยังเป็น unsafe อยู่ แบบนั้นการรีไรต์เป็น Rust จะมี ความหมาย อะไร
  • หวังว่า Mythos จะเก่งที่สุดในโลกจริงอย่างที่พวกเขาอ้างนะ เพราะตอนนี้คงจำเป็นจริงๆ แล้ว
  • ที่บ้านเรามี memory safety นะ!
    ของที่บ้านมี: 10428

• ตอนนี้เรายังเขียนโพสต์บล็อกเกี่ยวกับเรื่องนี้อยู่ และจะมาแชร์รายละเอียดเพิ่มเติม
  ถ้าอยากรู้พื้นหลัง ลองไล่ดูรายการแก้บั๊กในโน้ตรีลีสของ Bun v1.3.14 และรุ่นก่อนๆ
  Rust ไม่ได้แก้ทุกอย่างให้หมด ปัญหาที่เกิดจากการ hold reference นานเกินไปจนรั่ว หรือทุกปัญหาเรื่อง reentrancy ข้ามขอบเขต JS ก็ยังเป็นความรับผิดชอบของเราอยู่
  แต่รายการนั้นจำนวนไม่น้อยเป็นปัญหา use-after-free, double-free หรือการลืม free ในเส้นทาง error ซึ่งสิ่งเหล่านี้จะกลายเป็น compile error หรือเปลี่ยนเป็นการ cleanup อัตโนมัติ

  • เมื่อ 9 วันก่อนคุณพูดไว้แบบนี้[0]:
    I work on Bun and this is my branch
This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
    หรือจริงๆ แล้วมันอาจไม่ใช่การโอเวอร์รีแอ็กต์?
    [0]: https://news.ycombinator.com/item?id=48019226
  • รอโพสต์บล็อกอยู่นะ
    อยากรู้ว่ามีแผนจะรันไบนารี Zig กับ Rust แบบคู่ขนานบนแอปจริงที่หลากหลายเพื่อคัดบั๊กออก หรือถ้าเป็นไปได้จะทำ shadow execution ในโปรดักชันไหม
  • ถ้าผมเป็นลูกค้าที่จ่ายเงินอยู่ ก็อยากรู้เหมือนกันว่างานนี้มีต้นทุนเท่าไร
    พอจะให้ตัวเลขคร่าวๆ ได้ไหม
  • อยากรู้ว่าคุณได้ทำหรือมีแผนจะทำ end-to-end fuzz test บางแบบสำหรับเทียบสองไบนารีหรือไม่
    และอยากรู้ด้วยว่ามีแผนที่เป็นรูปธรรมอะไรบ้างในการปล่อยรีลีสนี้โดยไม่ทำให้เวิร์กโฟลว์ของผู้ใช้พัง
  • สิ่งนี้มีโอกาสจะแก้ปัญหาเสถียรภาพของ Bun Workers API ไหม? https://bun.com/docs/runtime/workers

• ราว 9 วันก่อน Jarred เขียนไว้ว่ายังไม่แน่เลยว่าจะ merge มันหรือเปล่า และบอกว่าคนอื่นโอเวอร์รีแอ็กต์
  ช่างประชดดี

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

• ว้าว ต่อจากนี้คงน่าดูมาก
  ดูไม่มีทางเลยว่าโค้ดนี้จะได้รับการรีวิว แต่บางทีเราอาจเข้าสู่ ยุคหลังมนุษย์ ที่เชื่อถือให้โมเดลเขียนและรีวิวโค้ดได้แล้วก็ได้
  มันเหมือน Gastown แต่เกิดขึ้นกับโปรเจกต์ที่ดังยิ่งกว่ามาก
  น่าสนใจว่าโปรเจกต์นี้จะเพิ่มฟีเจอร์ใหม่ต่อจากนี้ยังไง หรือจะเพิ่มได้ไหม
  มีใครรู้ไหมว่า Anthropic ใช้ Bun อย่างไรแน่
  มันเป็นส่วนหนึ่งของ Claude Code หรือเปล่า
  ผมเริ่มกังวลกับการใช้ Bun มากทีเดียว แต่ไม่แน่ใจว่าความกังวลนั้นควรลามไปถึงการใช้ Claude ด้วยแค่ไหน

  • เราเชื่อถือให้โมเดลเขียนและรีวิวโค้ดเองได้อย่างนั้น ไม่ได้เลย
  • ทุกเทสต์ผ่านหมด
    ถ้าคุณเชื่อถือ ชุดทดสอบ ไม่ได้ว่าจะจับการแปลภาษาอัตโนมัติแบบนี้ได้ งั้นแต่แรกคุณก็ไม่ควรเชื่อถือชุดทดสอบนั้นเลย :)
  • ไม่รู้เหมือนกันว่า Anthropic ใช้ Bun ยังไง แต่ดูเหมือนกำลังใช้มันเพื่อเลื่อน Overton window ของการถกเถียงไปทางว่า การ merge แบบไม่ดูตาม้าตาเรือ หลายล้านบรรทัดก็เป็นเรื่องยอมรับได้
  • ชุดทดสอบตอนนี้อยู่ในสภาพไหน

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

  • ความคิดที่ว่าโค้ดที่ไม่มีมนุษย์สักคนดูเลยจะเข้ามาอยู่ใน รันไทม์ ที่ผมใช้นั้นทำให้รู้สึกไม่สบายใจ
    แต่ถ้ามันใช้งานได้จริงโดยไม่มีปัญหาใหญ่ ก็ถือว่าน่าทึ่งมาก
  • ไม่รู้ว่าการตัดสินใจพวกนี้เป็นของ LLM หรือเปล่า แต่ผมรู้สึกมาตลอดว่า Claude มีแนวโน้มจะทำ พฤติกรรมน่าสงสัย อย่างแก้เทสต์แทนที่จะหาวิธีแก้ปัญหาที่ถูกต้องมากกว่า
    GPT/Codex ดูซื่อตรงกว่าในแง่นี้
  • ดูไม่เหมือนว่าจะกลายเป็น stable release ได้ในทันที แต่ถ้าพิสูจน์ได้ว่าผมผิดก็ดีใจ
    ผมยังสงสัยกับการรีไรต์ทั้งก้อนนี้ และ Jarred Sumner ก็มีผู้ติดตามในอินเทอร์เน็ตเยอะมากจนมันให้ความรู้สึกเหมือนโฆษณา
  • ตัวอย่างของการแก้ปัญหา “เทสต์ไม่ผ่าน” ด้วยการแก้ตัวเทสต์: https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed...
    ยอดเยี่ยมเลย! แค่ใส่ sleep(1) แบบสุ่มลงในเทสต์ก็พอ ไม่ต้องห่วง ทุกอย่างจะโอเค!
  • ผมอยากไล่ดูเทสต์เพื่อดูว่ามีการเปลี่ยนแปลงที่สำคัญจริงไหม แต่ GitHub โหลดแม้แต่ diff ก็ยังไม่ไหว

• โปรเจกต์ Bun ที่ผมใช้อยู่ไม่กี่ตัวคงจะย้ายไปอย่างอื่น
  ผมไม่ไว้ใจธรรมาภิบาลที่ยอมให้เกิด การเปลี่ยนแปลงแบบหุนหันพลันแล่น แบบนี้

  • Deno ดีมาก แต่ผมคิดว่ามันไม่ได้รับความรักเท่าที่ควร
    ตั้งแต่แรกมันเขียนมาดีอยู่แล้ว เลยไม่ต้องรีไรต์ใหม่
  • ผมคงใช้ node ต่อไปเฉยๆ
    อีกด้านหนึ่งก็สนใจว่าจะผ่าน บททดสอบด้วยไฟ นี้ไปยังไง และในระยะยาวก็ดูเหมือนว่าสุดท้ายปัญหาต่างๆ คงจะถูกแก้ได้

• มีเธรดหนึ่งที่น่าศึกษาในเชิงการเรียนรู้ เป็นเธรดเมื่อสัปดาห์ก่อนที่ Jarred ถอยออกจากการตัดสินใจ merge อีกครั้ง และมีเหล่าทหารราบจำนวนมากโจมตีคนที่ทำนายว่ามันจะถูก merge ในไม่ช้า:
  https://news.ycombinator.com/item?id=48073680
  มองย้อนกลับไปตอนนี้ คำพูดนั้นดูไม่ค่อยทนทานนักใช่ไหม?

  • จากคำพูดที่ว่า “ทั้งเธรดนี้เป็นการโอเวอร์รีแอ็กต์ มีคอมเมนต์ 302 อันกับโค้ดที่ยังใช้ไม่ได้ เราไม่ได้ตกลงจะรีไรต์ โอกาสสูงมากที่โค้ดทั้งหมดนี้จะถูกทิ้ง” ไปจนถึง merge ทั้งหมดภายใน 10 วัน แม้รวมสิ่งที่ดูเหมือนแค่ความอยากรู้อยากลองเชิงทดลองเข้าไปด้วย มันก็ดูบ้ามากจริงๆ
  • ผมยังแปลกใจทุกครั้งที่เห็นว่ามี คนตามอำนาจ อยู่มากแค่ไหนในโลก ที่แทบไม่สนใจด้วยซ้ำว่าตัวเองกำลังไปเลียรองเท้าบู๊ตของใคร

• ถ้าสิ่งนี้ผิดพลาดแม้แต่นิดเดียว ก็จะโดนล้อแบบพ่อค้ายาเสพติดที่เสพของตัวเองไปอีกยาวแบบไม่จบไม่สิ้นและค่อนข้างมืดมน

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