การเขียน Bun ใหม่ด้วย Rust คืบหน้าไปถึงไหนแล้ว?

 (lockwood.dev)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้จะเป็นงานที่ถูกเล่าว่าเสร็จใน 11 วัน แต่ จนถึงวันที่ 27 กรกฎาคม 2026 ซึ่งผ่านไป 6 สัปดาห์หลังจาก merge เข้า main ก็ยังไม่มี release tag และงานที่เกี่ยวข้องยังดำเนินต่อไป
  • การเขียนใหม่รอบแรกระหว่างวันที่ 3–14 พฤษภาคม 2026 ใช้ ค่าใช้จ่าย Anthropic API 165,000 ดอลลาร์ แต่ดูเหมือนจะไม่รวมค่าใช้จ่ายของ Buildkite CI/CD และงานต่อเนื่องหลังจากนั้น
  • จำนวน PR ที่ยังเปิดอยู่ของ robobun เพิ่มจาก 1,277 รายการในวันที่ 9 กรกฎาคม เป็น 2,475 รายการในวันที่ 27 กรกฎาคม และหาก pipeline ต่อ PR ใช้เวลาราว 40 นาที จะต้องรันต่อเนื่อง 86 วันจึงจะประมวลผลครบทั้งหมด
  • การใช้งาน Claude พุ่งขึ้นมากพร้อมกับการเริ่มเขียนใหม่ และการมีส่วนร่วมในงาน Rust ของ robobun กับพนักงาน Anthropic ก็เพิ่มขึ้นเช่นกัน จึงยากที่จะสรุปว่า เวลาที่เสร็จสิ้นและต้นทุนรวมจริง อยู่ที่ 165,000 ดอลลาร์
  • เนื่องจากทีม Bun ไม่ได้ยืนยันโดยตรงว่าการเขียนใหม่เสร็จสมบูรณ์แล้วหรือมีต้นทุนรวมเท่านี้ การจะใช้ผลงาน AI coding เป็นฐานประเมินมูลค่าบริษัทจึงควรดูทั้ง ความคุ้มค่าเมื่อเทียบกับต้นทุนและการแทรกแซงของมนุษย์อย่างต่อเนื่อง

การเขียนใหม่ที่ยังดำเนินต่อหลังการ merge

  • Jarred Sumner ระบุใน Rewriting Bun in Rust ว่าเขาใช้เงิน 165,000 ดอลลาร์ ไปกับการเรียก Anthropic API ตลอด 11 วันระหว่าง 3–14 พฤษภาคม 2026 และได้ merge ผลลัพธ์ของการเขียนใหม่เข้า main
    • เฉลี่ยราว 15,000 ดอลลาร์ต่อวัน ซึ่งเป็นระดับที่ผู้ดูแลโอเพนซอร์สจำนวนมากยากจะรับภาระได้
    • ดูเหมือนว่า ค่าใช้จ่าย CI/CD ที่ยังรันต่อบนคลัสเตอร์ Buildkite ขององค์กรจะไม่ถูกรวมอยู่ในตัวเลขนี้
  • ณ วันที่ 27 กรกฎาคม 2026 แม้จะผ่านไป 6 สัปดาห์หลัง merge แต่ก็ยังไม่มี release tag ใหม่ และนับจาก tag ล่าสุด bun-v1.3.14 ก็ผ่านไปแล้ว 11 สัปดาห์
    • ก่อนหน้านี้ช่วงที่ไม่มีรีลีสนานเกิน 1 เดือนคือช่วงว่าง 6 สัปดาห์ตั้งแต่ v0.2.2 เมื่อ 26 ตุลาคม 2022 ถึง v0.3.0 เมื่อ 7 ธันวาคม
  • robobun PR ที่เปิดอยู่ ซึ่งเป็นตัวชี้วัดโดยอ้อมของ PR ที่สร้างโดย Claude Code เพิ่มจาก 1,277 รายการในวันที่ 9 กรกฎาคม เป็น 2,475 รายการในวันที่ 27 กรกฎาคม
    • มีการสังเกตว่าการตรวจสอบของ Buildkite และการ merge เข้า main โดยทั่วไปใช้เวลาราว 40 นาที และบางครั้งนานถึง 1 ชั่วโมง 30 นาที
    • หากคิด PR ละ 40 นาที การ merge ทั้ง 2,475 รายการจะต้องรัน pipeline ต่อเนื่อง 86 วัน
    • PR บางส่วนไม่เกี่ยวข้องกับโค้ด Rust และในบรรดา PR เดี่ยว ๆ ก็มีกรณีที่ผ่านการรีวิวอย่างหนักจำนวนมาก

ความต่างระหว่างต้นทุนที่เปิดเผยกับทรัพยากรที่ใช้จริง

  • ตอนเริ่มการเขียนใหม่ การใช้งาน Claude เพิ่มขึ้นอย่างมาก และหลังจากนั้นก็เห็นแนวโน้มว่า พนักงาน Anthropic และ robobun เข้ามามีส่วนร่วมในงาน Rust มากขึ้น
    • การวิเคราะห์นี้รวมสมมติฐานว่าคอมมิตของ Jarred Sumner ในช่วงเขียนใหม่นั้นใช้ Claude
    • บาง PR ถูกเขียนโดยพนักงาน Anthropic ดังนั้นนอกจากค่า token แล้ว ยังต้องคำนึงถึงการลงมือโดยตรงของพนักงานด้วย
  • หากสมมติว่าการเขียนใหม่ยังคงมีค่าใช้จ่ายวันละ 10,000 ดอลลาร์ ต้นทุนสะสมจะเข้าใกล้ 800,000 ดอลลาร์ แต่ตัวเลขนี้เป็นเพียงการประเมินตามสมมติฐาน ไม่ใช่ต้นทุนจริงที่เปิดเผย
  • ทีม Bun ไม่ได้อ้างว่าการเขียนใหม่เสร็จสมบูรณ์ทั้งหมดแล้ว หรือว่าต้นทุนรวมมีเพียง 165,000 ดอลลาร์
    • จึงยังยากที่จะสรุปจากกรณีนี้เพียงอย่างเดียวว่า AI เข้ามาแทนงานของผู้ดูแลโอเพนซอร์สได้เร็วขึ้นจริง
    • Anthropic กำลังนำเครื่องมือของตัวเองมาใช้ภายใน และทั้งงานอัตโนมัติกับการมีส่วนร่วมของพนักงานก็ยังดำเนินต่อเนื่อง
  • แทนที่จะปฏิเสธ AI โดยสิ้นเชิง บทความนี้เตือนให้ระวัง ความคาดหวังที่สูงเกินจริงและการประเมินมูลค่าบริษัท ในปัจจุบัน พร้อมตั้งคำถามว่างานนี้สร้างคุณค่าได้คุ้มกับต้นทุนที่ลงไปหรือไม่ และมูลค่าบริษัทดังกล่าวสมเหตุสมผลหรือเปล่า
  • C compiler ของ Anthropic และ เว็บเบราว์เซอร์ FastRender ของ Cursor ไม่มีคอมมิตมาเป็นเวลาหลายเดือน

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

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

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Hacker News

  • เวอร์ชันที่เขียน Bun ใหม่ด้วย Rust ถูกใช้งานใน Claude Code มานานกว่าหนึ่งเดือนแล้ว แต่แทบไม่มีใครสังเกตเห็น และโดยรวมก็ทำงานได้ดี
    จะยังไม่ปล่อยออกมาจนกว่าจะผ่านการทดสอบความเข้ากันได้กับ Node.js ตามที่สัญญาไว้ในวิดีโอ Bun v1.4 และถ้า PR ที่เกี่ยวข้องถูกรวมเข้ามา ก็มีโอกาสสูงที่จะปล่อย v1.4 ราววันอังคารสัปดาห์หน้า

    • ใช้เวลาเท่าที่จำเป็นเพื่อคุณภาพของซอฟต์แวร์ได้เลย การไม่มีรีลีสตลอดหนึ่งเดือนไม่ใช่เรื่องใหญ่ และถ้าต้องการฟีเจอร์ไหนด่วนก็สามารถช่วย contribute หรือ build เองได้
      แม้แต่ Node.js เองก็แทบไม่มีรีลีสที่มีนัยสำคัญช่วงละ 4-6 สัปดาห์ทุกเดือนธันวาคมอยู่แล้ว ยกเว้นการแก้ไขด้านความปลอดภัย ดังนั้นคำวิจารณ์ครั้งนี้ที่เริ่มจากโพสต์ด้วยความโกรธโดยไม่ถามเจ้าตัวก่อนจึงมีน้ำหนักไม่มาก พูดในฐานะผู้ดูแล Node.js
    • ตัว Claude Code เองก็มีทั้งบั๊กและปัญหาหลังรีลีสอยู่บ่อย จึงไม่แปลกที่ผู้ใช้จะแยกไม่ออกระหว่าง บั๊กที่เกิดจาก Bun ที่ย้ายไปใช้ Rust กับบั๊กปกติที่มีอยู่เดิม
    • อยากรู้ว่าจะมีคำตอบเรื่องต้นทุนที่บทความประเมินไว้ โดยเฉพาะ ค่าใช้จ่าย Buildkite หรือไม่
    • เข้าใจได้ว่าทำไมบางคนถึงกังวลกับอนาคตของ Bun เพราะมี โปรเจ็กต์ vibe coding จำนวนมากที่เริ่มต้นแรงแต่สุดท้ายก็ถูกปล่อยทิ้งแบบ Anthropic C แต่ Bun ทั้งเร็วและใช้งานดี จึงหวังว่าจะอยู่ได้นานแบบ GCC

  • หลังการรีแฟกเตอร์ครั้งใหญ่หรือการเขียนใหม่ขนาดใหญ่ มักต้องใช้เวลากว่าจะกลับมาที่ความเร็วการพัฒนาปกติได้ ดังนั้นจึงตัดสินอะไรจากแค่ จำนวนคอมมิตและรอบการรีลีส ได้ยาก
    ถึงนักพัฒนาจะคุ้นกับโครงสร้างเดิม แต่ก็ยังต้องปรับตัวกับโค้ดเบส Rust ใหม่ และอาจกำลังโฟกัสกับงานอย่างการตามรอยจุดที่ใช้ unsafe มากกว่าฟีเจอร์ฝั่งผู้ใช้ อีกทั้งในช่อง canary ก็แทบไม่เห็นทั้งปัญหาใหญ่หรือความเปลี่ยนแปลงชัดเจน จึงมีเหตุผลพอที่จะเคลียร์งานค้างแทนการเร่งรีลีส
    มองทั้งคอมไพเลอร์ C ของ Anthropic และเบราว์เซอร์ FastRender ของ Cursor ว่าเป็นการทดลองศักยภาพมากกว่าจะเป็นโปรเจ็กต์ระยะยาว และหวังว่าตอนนี้คงไม่มีใครใช้งานมันโดยตรง

    • หนึ่งเดือนก่อนมีการย้ายผู้ใช้ Claude Code ทั้งหมดไปเวอร์ชันใหม่แล้ว ดังนั้นในแง่หนึ่งก็ถือว่า ปล่อยใช้งานจริงใน production ไปแล้ว ดูเหมือนจะค่อยๆ เดินหน้าแบบเป็นขั้นตอนเพราะได้รับความสนใจมากอยู่แล้วและไม่จำเป็นต้องรีบเปิดตัวอย่างเป็นทางการ
    • มุมมองเรื่อง ต้นทุน CI/CD น่าสนใจ ปกติเวลาโต้แย้ง ROI ของ AI มักพูดกันว่าโค้ดที่มากขึ้นไม่ได้แปลว่ามีคุณค่าเพิ่มขึ้น แต่ถ้าคิดเงินทุกครั้งที่ CI รัน รายได้จริงก็เพิ่มขึ้นได้
      โดยเฉพาะเมื่อมันเชื่อมโยงกับข้อเท็จจริงที่ว่า CI และการทดสอบเพิ่มเติมคือหัวใจสำคัญในการกันไม่ให้งานซ้ำๆ ที่ AI สร้างขึ้นหลุดการควบคุม
    • แม้ในมุมของคนเขียนบทความเองก็ยังไม่แน่ใจว่าจะตัดสินอะไรจากตัวเลขเหล่านี้ได้มากแค่ไหน หวังว่าหลังรีลีสครั้งหน้าจะมีบทความย้อนหลังจาก Anthropic หรือ Bun ที่เปิดเผยต้นทุนทั้งหมด

  • แม้การใช้ LLM แปลโปรเจ็กต์ภายในเวลาสั้นๆ หรือสร้างของเลียนแบบผลิตภัณฑ์ออฟฟิศแบบยกชุดจะเป็นเรื่องน่าทึ่ง แต่แก่นของซอฟต์แวร์ไม่ได้อยู่ที่การสร้างช่วงแรกให้เร็ว แต่อยู่ที่ การพัฒนาฟีเจอร์และการบำรุงรักษาระยะยาว
    ของเลียนแบบ Word ก็อาจทำฟังก์ชันพื้นฐานได้เร็ว แต่พอเจอรายละเอียดอย่างโครงสร้างหน้า ตาราง รูปภาพ หรือการหมุน LLM ก็เริ่มไปไม่รอด ต่อให้ย้าย SQLite จาก C ไป Rust แล้วผ่านเทสต์ทั้งหมด ก็ยังมีโอกาสสูงว่าจะช้ากว่าเดิมเพราะไม่มีการปรับแต่งสะสมมาหลายปีของ implementation เดิม แถมยังต้องรับมือทั้งบั๊กใหม่จากการเปลี่ยนภาษาและการซัพพอร์ตในอนาคต
    ใน Reddit มีโปรเจ็กต์ที่บอกว่าทำ X, Y, Z ได้อยู่เรื่อยๆ แต่การแก้บั๊ก การตอบผู้ใช้ ความปลอดภัย โครงสร้างข้อมูลที่เปลี่ยนไป และงานฐานข้อมูลนั้นไม่ใช่งานที่ดึงดูดใจ จึงมักถูกปล่อยทิ้งเร็วพอๆ กับ vibe coding
    ถ้าไม่เข้าใจซอฟต์แวร์ที่ตัวเองสร้างอย่างลึกซึ้ง สุดท้ายมันก็จะระเบิด และคำอย่าง เขียน X ใหม่เป็น Z ภายใน Y วัน เพียงอย่างเดียวไม่มีความหมายอะไรเลย การเริ่มต้นได้เร็วขึ้นกับการเข้าใจโค้ดที่พอร์ตมาแล้ว ค่อยๆ พัฒนา และดูแลรักษามันต่อ เป็นคนละเรื่องกันโดยสิ้นเชิง และผลการค้นหาอาจเต็มไปด้วยเวอร์ชัน Rust ที่ถูกทิ้งกับโพสต์เชิงโปรโมต แทนที่จะเป็นเวอร์ชัน Zig ที่ยังมีคนดูแล

    • อยากให้มีคนบันทึกกระบวนการแบบนี้มากขึ้น ตอนนี้ส่วนตัวก็ทำโปรเจ็กต์ที่พึ่งพา LLM สูงและกำลังเรียนรู้จากมันอยู่ ตอนที่ฟีเจอร์ซับซ้อนทำงานได้เร็วจะให้ความรู้สึกสะใจมาก แต่พอเป็นช่วงรวมระบบ เก็บงาน และขัด UI กลับยิ่งเจ็บปวดกว่าเดิมเพราะเคยชินกับความเร็วช่วงต้นไปแล้ว
      ถ้าโค้ดเริ่มพันกันแบบแก้ขัดเกินไป ก็จะถึง จุดเฉื่อย ที่ LLM เดินหน้าต่อไม่ได้โดยไม่สร้างความสับสนเพิ่มขึ้นอีก จากนั้นก็ต้องแก้สถาปัตยกรรม ทิ้งแล้วเริ่มใหม่ทั้งหมด หรือย้อนกลับไปยังจุดสุดท้ายที่ยังปกติดี มันเหมือนพัฒนาโดยสะพายเจ็ตแพ็ก ไปถึงเป้าหมายได้เร็วขึ้น แต่ก็ชนกำแพงได้เร็วและเจ็บกว่าเหมือนกัน
      ท่ามกลางการถกเถียงว่า AI ดีที่สุดหรือแย่ที่สุด และการแข่งขันกันว่าใครใช้เครื่องมือเก่งกว่า ยังมีข้อมูลไม่พอเกี่ยวกับสิ่งที่เวิร์ก สิ่งที่ล้มเหลว และระหว่างใช้งานควรเปลี่ยนพฤติกรรมอย่างไร ตั้งใจจะเขียนประสบการณ์ใช้งานเองเหมือนกัน แต่การทำฟีเจอร์ใหม่หรือเก็บรอยตำหนิของ UI สนุกกว่าจึงผัดไปเรื่อย
    • ใน GitHub ก็มีทั้งเกมเอนจินและคอมไพเลอร์สำหรับภาษาสมมติที่ถูกทิ้งไว้เป็นพันๆ โปรเจ็กต์มาตั้งแต่ก่อนยุค LLM แล้ว ในบอร์ดระบบปฏิบัติการช่วงต้นยุค 2000 แทบทุกคนก็ทำ OS ของตัวเอง และบางตัวถึงขั้นรัน Firefox ได้ด้วย
      ไม่ใช่ซอฟต์แวร์ทุกชิ้นต้องเป็นเชิงพาณิชย์หรือสมบูรณ์แบบถึงจะมีประโยชน์ได้ แค่เป็น การทดลองเพื่อการเรียนรู้ ก็เรียนรู้อะไรได้มากพอแล้ว
    • ยิ่งงานลึกทางเทคนิคมากเท่าไร ก็ยิ่งถูกมองว่าแทนที่ได้ง่ายขึ้นเท่านั้น เพราะในองค์กรมีการยอมรับสมมติฐานว่าคุณค่ามาจากความสามารถทางเทคนิคล้วนๆ ไม่ใช่ตัวบุคคลหรือความสัมพันธ์
      แต่ดูเหมือนหลายคนกำลังเริ่มยอมรับแล้วว่าองค์ประกอบที่เกิดขึ้นโดยบังเอิญอย่าง network effect, ความเป็นเจ้าของ, ความรับผิดชอบ ก็สำคัญเช่นกัน เพียงแต่มันก็มีความย้อนแย้งตรงที่คนสายเทคจำนวนมากหนีจากระบบอุปถัมภ์ การประเมินแบบตามอำเภอใจ และสภาพแวดล้อมที่ให้ค่ากับคำพูดเกินจริงมากกว่าเทคนิค แล้วเข้าสู่สายงานเทคนิคแทน
    • เคยทำงานในสตาร์ตอัปที่เขียนโค้ดเบสขนาดใหญ่ใหม่ทั้งหมดโดยหยุดพัฒนาฟีเจอร์ไปด้วย แต่พอกลับมาหลังไปทำโปรเจ็กต์อื่นจนพลาดกระบวนการทั้งหมดไป ก็แทบไม่มี learning curve เลย เพราะถึงภาษาจะเปลี่ยน แต่ สถาปัตยกรรมหลัก โครงสร้างข้อมูล และแนวคิด ยังเหมือนเดิม
      Bun เองก็ไม่ได้เริ่มออกแบบใหม่ตั้งแต่ต้น แต่ใช้วิธีย้ายของเดิมไปยังภาษาใหม่ก่อน เมื่อมองจากประสบการณ์ก่อนยุค LLM แล้ว ถ้าจะให้ทีมเปลี่ยนผ่านได้เร็ว การย้ายไปอีกภาษาหนึ่งให้เรียบง่ายและรวดเร็วที่สุดคือวิธีที่ถูกต้อง และการลดระยะเวลาเขียนใหม่ X วันให้น้อยที่สุดก็เป็นเป้าหมายที่ดี
    • ท่าทีที่ไม่พยายามเข้าใจโค้ดที่ตัวเองเขียนอย่างลึกซึ้งคือ ลัทธิระยะสั้นแบบสุดโต่ง ผู้ดูแลรักษาระบบจะได้เรียนรู้แบบยากลำบากว่าเส้นแบ่งระหว่างโค้ดที่ AI สร้างกับโค้ดที่มนุษย์ยังพอรักษาต่อได้อยู่ตรงไหน

  • มีคนบอกว่าสามารถทำให้ implementation เดิมที่เขียนด้วย Zig ทันสมัยขึ้น ใช้แนวปฏิบัติที่ดี และแก้บั๊กจนได้ incremental build ต่ำกว่า 1 วินาที ซึ่งชวนให้เห็นว่าปัญหาที่ใช้เป็นเหตุผลในการ rewrite นั้นจริง ๆ แล้วเป็นปัญหาที่สร้างขึ้นเองและแก้ได้
    https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
    ฝั่ง Zig ก็ใช้ LLM เหมือนกัน จึงไม่เกี่ยวกับสงครามทางวัฒนธรรม คนที่เข้าใจปัญหาอย่างถูกต้องย่อมทำผลงานได้ดีกว่าคนที่แค่ทุ่มทรัพยากรอย่างโทเคนมูลค่าหลายแสนดอลลาร์เสมอ

    • แกนหลักที่ใช้ให้เหตุผลกับการ rewrite ไม่ใช่ความเร็วในการ build แต่เป็น memory bug โดยเฉพาะเวลาที่ต้องโต้ตอบกับอ็อบเจ็กต์ JavaScript ที่ถูกจัดการด้วย garbage collection ซึ่งใน Zig ไม่มีวิธีทั่วไปที่จะป้องกันเรื่องนี้ และก็ยังไม่เห็นว่ามีการอ้างว่า Buz แก้ปัญหานี้ได้
    • โปรเจ็กต์นี้ดูใกล้เคียงกับมีมหรือเรื่องล้อเล่นมากกว่าความพยายามจริงจัง โดยตีตราโค้ดเดิม 600,000 บรรทัดว่าเป็นโค้ดเละเทะที่ AI สร้างขึ้น และประกาศว่าจะ ปฏิเสธ contribution ที่มนุษย์เขียน จนกว่าจะ rewrite subsystem ส่วนใหญ่ใหม่หมด
      จึงยากจะมองโปรเจ็กต์ที่ใช้ LLM เก็บกวาดโค้ดเละเทะ แต่กลับห้าม contribution จากมนุษย์ ว่าเป็นเรื่องจริงจัง

  • การ rewrite Bun ทำให้กล้าลองทั้งการพอร์ตโค้ด การ rewrite และการ vendor dependency ภายนอกมากขึ้นอย่างมาก และทำให้ปรับแต่งให้ตรงกับความต้องการภายในได้ แม้จะไม่เหมาะกับ upstream project ก็ตาม
    พร้อมกันนั้นก็เริ่มมอบงานที่ทะเยอทะยานกว่าเดิมให้ coding model มากขึ้น และหันไปโฟกัสกับ test harness และการตรวจสอบนอกขอบเขตภาษา มากขึ้นมาก เคยมีส่วนร่วมกับการ rewrite ขนาดใหญ่ที่กินเวลาหลายปีมาแล้ว แต่ก็มองว่า Bun ที่ยังรักษาการทดสอบและความเทียบเท่าด้านฟังก์ชันไว้ได้พร้อมกับเพิ่มการปรับปรุงเข้าไปนั้น เป็นความสำเร็จทางวิศวกรรมที่น่าทึ่ง

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

    • ในทีม ไม่มีใครมีประสบการณ์ Rust เลย
    • การพอร์ต Bun จาก Zig→Rust แทบไม่ได้ให้บทเรียนที่นำไปสรุปทั่วไปได้เกี่ยวกับ Zig, Rust, การพอร์ตข้ามภาษา หรือการใช้ LLM เพราะโค้ดเบสก่อนและหลังมีคุณลักษณะที่วัดเชิงปริมาณได้ยากมากเกินไป และยังมีเรื่องรสนิยมต่อภาษา วิธีพอร์ต และการเขียนโค้ดด้วย LLM เข้ามาเกี่ยวข้องด้วย
      ถ้าทำผลลัพธ์แบบเดียวกันไม่ได้หรือต้องเสียค่าโทเคนมากกว่า ก็อาจบอกว่าใช้เครื่องมือไม่เป็น แต่ถ้าผลลัพธ์น่าผิดหวัง ก็อาจถอยไปบอกว่าเป็นแค่ proof of concept และโมเดลในช่วง 6 เดือนหลังดีขึ้นจนเทียบกันไม่ได้ ทำให้ยากจะได้ ข้อสรุปที่ตรวจสอบได้
    • LLM เก่งมากในการสร้างผลลัพธ์ที่ดูน่าเชื่อแต่ผิด จึงมีเหตุผลมากพอที่จะมองอย่างระแวดระวัง งานนี้ไม่ว่าผลลัพธ์จะจริงแค่ไหนก็เป็น อีเวนต์การตลาด อย่างชัดเจน และ Anthropic ก็มีประวัติการประกาศที่เกินจริงหรือไม่ตรงข้อเท็จจริง จึงยิ่งต้องตรวจสอบอย่างเข้มงวด

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

    • การพิมพ์เป็นเรื่องรองในวิศวกรรมซอฟต์แวร์ แต่ถ้าอยู่ในสถานการณ์ที่การพิมพ์เป็นคอขวดจริง ๆ LLM ก็อาจมีคุณค่าได้ เพียงแต่สถานการณ์แบบนั้นพบได้น้อย

  • ถ้าบทความสะท้อนข้อเท็จจริงว่า Bun บน Rust นั้น รันอยู่บน Claude Code มาตั้งแต่ 17 มิถุนายน และหลัง merge เข้า main ก็ถูกปล่อยเป็น canary ด้วย ความน่าเชื่อถือก็น่าจะสูงขึ้น สำหรับการ rewrite ระดับนี้ ช่วง canary ที่ยาวนานถือว่าสมเหตุสมผลมาก

    • ในบทความได้กล่าวถึง การใช้งานจริงภายในของ Anthropic ไว้อยู่แล้ว

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

    • ถ้าสิ่งที่สำคัญจริง ๆ มีแค่ Claude Code การ rewrite ตัว Claude Code เป็น Rust น่าจะมีประสิทธิภาพกว่ามาก เมื่อเทียบกับการเปลี่ยนภาษาของ TypeScript runtime ค่าใช้จ่ายราว 800,000 ดอลลาร์อาจมาจากงบการตลาดของ Anthropic ที่หวังผลด้านประชาสัมพันธ์ก้อนใหญ่
    • โอกาสที่จะทิ้งชุมชนในวงกว้างมีน้อย และยิ่งมีผู้ใช้อื่นมากเท่าไร Anthropic ก็ยิ่งได้ประโยชน์ หากการปล่อยครั้งนี้มีปัญหา ก็อาจถูกวิจารณ์อย่างหนักและทำลายความเชื่อมั่นของชุมชน จึงดูเหมือนกำลังระมัดระวังมากกว่าปกติ
    • Bun เป็นองค์ประกอบสำคัญของ ecosystem ฝั่งเว็บ ดังนั้นแค่ข้อเท็จจริงที่ว่า Anthropic พัฒนาด้วย AI ก็สร้าง ผลประชาสัมพันธ์มหาศาล ได้แล้ว
    • Claude Code ก็น่าจะรันได้บน JavaScript runtime ไหนก็ได้ จึงน่าสงสัยว่าทำไมต้องเป็น Bun
    • ท้ายที่สุดแล้วมันดูเหมือน อีเวนต์การตลาด สำหรับโฆษณาการ rewrite โค้ดด้วย Claude ข้อความที่ส่งออกมาอย่างได้ผลคือ ถ้าอยากกำจัดโค้ดเบสที่ชวนอึดอัด ก็ให้จ่ายเงินก้อนใหญ่กับ Anthropic
      ถ้าเป้าหมายคือ Claude Code ก็ควร rewrite ตรงนั้นก่อน และถ้าย้ำมาตลอดว่าไม่ต้องเขียนโค้ดเองโดยตรงอีกแล้ว ภาษา implementation ก็ควรไม่ใช่เรื่องสำคัญ

  • คนที่เคย rewrite ซอฟต์แวร์มาก่อนจะเข้าใจช่วงนี้ได้ ตอนนี้คือระยะที่ส่วนใหญ่ใช้งานได้แล้ว แต่ยังต้องแก้ต่อเนื่องเพื่อไม่ให้เกิด regression และแรงกดดันจากการปล่อยก็สูงมาก
    มองว่าการตัดสินใจ rewrite นั้นถูกต้อง แต่ถ้าเป็นตั้งแต่แรกก็คงไม่อยาก deploy เข้าสู่ production ทันที ถ้า Jarred เลือกออก release candidate ก่อนแทนที่จะปล่อยรุ่นเสถียรเลย ก็จะช่วยลดภาระกดดันได้