การเขียน Bun ใหม่ด้วย Rust: "โค้ดเบสไม่ผ่านการตรวจ miri ขั้นพื้นฐานและเปิดให้เกิด UB ใน safe Rust"

• ประเด็นนี้ขณะนี้อยู่ในสถานะ Open และการสนทนาถูกล็อกว่าออกนอกประเด็นโดยจำกัดไว้เฉพาะ collaborator พร้อมเชื่อมโยงการแก้ไขที่เกี่ยวข้องคือ #30728 และ #30876
• ผู้รายงานชี้ว่า ค่าที่สร้างด้วย PathString::init ยังสามารถเรียก slice() ได้แม้ Box ต้นทางจะถูก drop ไปแล้ว ทำให้ Miri รายงาน Undefined Behavior ที่อิงกับ dangling reference
• โค้ดสำหรับทำซ้ำปัญหาอยู่ในรูปแบบส่งบัฟเฟอร์ที่สร้างด้วย Box::new(*b"Hello World") เข้าไปยัง PathString::init(&*test) จากนั้นเรียก init.slice() หลัง drop(test) และ Miri แจ้งข้อผิดพลาดที่จุด core::slice::from_raw_parts
• robobun ยืนยันว่าปัญหานี้เกิดซ้ำได้จริง และสรุปว่าแม้ PathString::init จะเป็นฟังก์ชัน safe แต่กลับลบ slice lifetime ทิ้งจนสร้าง &[u8] ที่ dangling ได้
• #30728 ที่เชื่อมโยงไว้มีแนวทางเปลี่ยนช่องโหว่คู่ขนานใน PathString::init และ dir_iterator::next() ให้เป็น unsafe fn และเพิ่มคอมเมนต์ SAFETY ที่ระบุ backing allocation อย่างชัดเจนในจุดเรียกใช้งานราว 70 แห่ง
• ในชุดแก้ไขเดียวกัน ยังมี compile_fail doctest ที่บังคับว่าต้องใช้คีย์เวิร์ด unsafe ในสามซิกเนเจอร์ และรวมถึงการแก้ fd leak ของ readdir-error ใน resolver ด้วย
• AwesomeQubic เสริมว่า PathString::init ยังลบ provenance ทิ้ง และจึงไม่ผ่านแม้เมื่อรันด้วย MIRIFLAGS=-Zmiri-strict-provenance
• JavaDerg อธิบายว่า init รับ lifetime โดยนัยของ &[u8] แล้วใช้การทำงานแบบ unsafe เพื่อลบทิ้ง ก่อนคืนค่า Self ที่ดูเหมือนเป็น 'static จึงเปิดให้เกิด use-after-free และ invalid aliasing ได้
• JavaDerg เตือนว่า บนโมเดลความปลอดภัยของ Rust นั้น UB อาจก่อปัญหาในจุดที่คาดไม่ถึง จึงจำเป็นต้องทบทวนการใช้ unsafe โดยรวม และการแปลรูปแบบการจัดการหน่วยความจำจากภาษาอื่นมาเป็น Rust แบบ 1:1 นั้นไม่เหมาะสม
• robobun เพิ่มคอมมิตที่เกี่ยวข้องคือ PathString::init signature stays unsafe test และ dir_iterator: make next() unsafe; audit call sites
• SimonReiff ระบุว่าผล grep ของ unsafe ในไฟล์ Rust ของรีโพซิทอรี โดยไม่นับคอมเมนต์ อยู่ที่ 13255 บรรทัด และเรียกร้องให้ย้อนกลับทันทีพร้อมหารือนโยบายและกระบวนการใช้โค้ด AI
• Jarred-Sumner ระบุว่า Rust port ตอนนี้เริ่มต้นจาก 1:1 mapping ที่พยายามให้ใกล้กับโค้ด Zig เดิมมากที่สุด และกำลังปรับปรุงต่อไป พร้อมขอให้รายงานบั๊กหรือพฤติกรรม unsound ในโค้ด Rust ต่อไปผ่าน issue ใหม่

[GN⁺]

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

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

  • Bun เป็นโปรเจ็กต์ที่น่าสนใจมากจริง ๆ แต่จำนวนsegmentation faultที่ขึ้นมาใน issue ต่าง ๆ ทำให้น่ากังวลเกินกว่าจะเอาไปใช้ในสภาพแวดล้อม production อย่างจริงจัง
    ทิศทางครั้งนี้อาจเป็นวิธีหนึ่งในการแก้ปัญหานั้นก็ได้ คงต้องรอดู
  • เข้าใจได้ แต่จุดตั้งต้นของผมต่างออกไปพอสมควร
    ในฐานะแฟน Deno มานาน Bun ดูเหมือน Deno ที่ทะเยอทะยานน้อยกว่า และเพราะไม่อยากเรียน Zig โอกาสที่ผมจะไปแตะ Bun เองแม้แต่เป็นงานอดิเรกก็ต่ำมาก
    แต่ในช่วงหลายปีที่ผ่านมา พอพยายามดูแล TypeScript codebase ขนาดค่อนข้างใหญ่ในแบบที่ไม่ผูกกับ runtime มากนัก ผมก็เริ่มเปิดใจให้ Bun มากขึ้น แม้จะไม่อยากให้ runtime TypeScript ตัวใดตัวหนึ่งกลายเป็นข้อกำหนด แต่ Bun ก็มีเหตุผลให้เลือกเรื่อย ๆ เช่น Postgres, SQLite, S3, เว็บซ็อกเก็ต, local secret storage, bundling, compiling และความเร็วสูง แบบเดียวกับ Deno
    ตอนนี้ผมทำทั้ง API server หลายตัวและ frontend app server เป็นไฟล์ executable เดี่ยวจาก bun build --compile --bytecode แล้วรันและ deploy ได้แทบทุกที่
    แต่ก็ไม่ได้คิดว่าวิธีนี้เป็นเรื่องปกติ และถ้าการพอร์ตด้วย LLMครั้งนี้ล้มเหลว ผมก็อยู่ในจุดที่พร้อมจะเสียใจกับทุกการตัดสินใจเกี่ยวกับ Bun ได้พอดี
    ถึงอย่างนั้น ถ้ามันไม่ล้มเหลวก็น่าสนใจมาก มันจะเป็นตัวอย่างว่า LLM ทำอะไรได้บ้าง และการที่ Bun จะพัฒนาด้วย Rust ต่อไปก็นับเป็นข้อดีสำหรับผม
    ในทางกลับกัน ถ้าล้มเหลว มันก็ยังสำคัญในเชิงข้อมูลอยู่ดี Bun เป็นหนึ่งใน TS/JS runtime หลัก และ Anthropic ก็มีทรัพยากรมหาศาล เข้าถึงโมเดลล่าสุด และมีงบประมาณแทบไม่จำกัด ดังนั้นถ้าพวกเขายังทำไม่ได้ ก็แทบหมายความว่าตอนนี้มันยังเป็นไปไม่ได้จริง ๆ
  • อยากรู้ว่าอะไรทำให้ Bun น่าสนใจกว่า Deno

• ถ้าจะย้ายจาก Zig ไปเป็น Rust ที่ไม่ปลอดภัยอยู่ดี ก็ไม่เข้าใจว่าทำไมไม่สร้างเครื่องมือแปลภาษาขึ้นมา
  ถ้าแมปโครงสร้างภาษากันแบบหนึ่งต่อหนึ่งและ hardcode pattern ของ codebase ก็น่าจะได้การแปลงแบบกำหนดผลได้แน่นอน อย่างที่เพื่อนผมพูดไว้ก็คืออาจทำแบบ “เอา zig translate-c ไปต่อกับ c2rust” ก็ยังได้
  ตอนนี้ผลลัพธ์ดูน่าเชื่อถือน้อยกว่าตัวอินพุตเสียอีก อินพุตอาจไม่ memory-safe แต่เป็นโค้ดที่คนเขียนเอง ส่วนเอาต์พุตนั้นไม่ memory-safe แถมเป็น vibe coding และดูเหมือนจะไม่มีมนุษย์ตรวจจริงจังเลยด้วย
  ไม่เข้าใจว่าการเอา agentic AI มาใช้เกินพอดีกับงานแบบนี้มีประโยชน์อะไร

  • ถ้าเคยเห็นผลลัพธ์จากc2rust ก็คงพูดแบบนั้นยาก
    มันเลียนแบบ pointer semantics ที่ไม่ปลอดภัยของ C ด้วย unsafe function library ของ Rust ทำให้ผลลัพธ์ออกมาน่ากลัวมาก
    เมื่อหลายปีก่อนตอนดูบั๊ก OpenJPEG มีคนลองแปลงด้วย c2rust แล้ว Rust แบบ unsafe ที่ได้ก็ยังเกิด segmentation fault ตรงจุดเดียวกับโค้ด C
    มันเข้ากันได้ แต่ไม่ได้ปลอดภัย
    ใจความสำคัญคืออย่าไปทำ string manipulation ด้วย C หรือ Rust แบบ unsafe มันเป็นเครื่องมือที่ไม่เหมาะกับงานนี้เลย
  • พวกเขาก็สร้างแล้วนะ เครื่องมือแปลที่ไดนามิกมากตัวหนึ่ง
  • แนวคิดว่า “เอา zig translate-c ไปต่อกับ c2rust ก็จบ” มันไม่ได้ทำงานแบบที่คิด
    เครื่องมือพวกนี้มีข้อผิดพลาดเยอะ และทำให้โค้ดยืดยาวมากจนวิเคราะห์ได้ยาก
    อาจใช้ได้กับแอปเล็ก ๆ แต่ไม่เหมาะกับการ rewrite ทั้งระบบ
  • ผมก็พูดเกือบแบบเดียวกันในอีกเธรดหนึ่ง แต่มีมุมมองต่างออกไปเล็กน้อยเรื่องวิธีเขียนซอฟต์แวร์
    แทนที่จะแปล Zig เป็น Rust ตรง ๆ ผมคิดว่าควรเขียน JPEG parser ด้วยstatic Pythonก่อน แล้วค่อยลดระดับลงเป็น Zig และ Rust ด้วยโครงสร้างแบบ idiomatic ที่เข้ากับแต่ละภาษา
    เพื่อทำแบบนั้น ผมเลยทำ dialect parser ของ Python ที่ออกแบบมาสำหรับจุดประสงค์นี้ และพยายามรับฟีเจอร์บางส่วนของ Rust/Zig ที่ช่วยให้แปลงง่ายขึ้น โดยยังคงความเข้ากันได้กับโค้ด Python ส่วนใหญ่
    JPEG parser ก็รวมอยู่ในตัวอย่าง asset ด้วย
    https://github.com/py2many/static-python-skill
    https://github.com/py2many/spy-ast
  • วิธีที่ถูกต้องในการพอร์ต codebase ไปอีกภาษาคือ parse เป็นsyntax tree แล้วใช้การแปลงที่กำหนดผลได้แน่นอนและตรวจสอบได้

• issue นี้ชวนให้เข้าใจผิด
  ปัญหาไม่ใช่แค่การมีอยู่ของundefined behaviorที่ miri จับได้ แต่คือการเปิดเผย API ที่ทำให้เกิด undefined behavior จากโค้ดที่ปลอดภัยได้ และ miri ก็จะจับได้ก็ต่อเมื่อมีการเขียนเทสต์ที่พิสูจน์เรื่องนั้นเท่านั้น
  สำหรับการพอร์ตช่วงแรกจากภาษาที่ไม่ปลอดภัย เรื่องแบบนี้ก็ไม่ได้ไร้เหตุผลไปเสียทีเดียว
  ดูเหมือนทีม Bun เองก็ทยอยตรวจสอบด้วยว่าฟังก์ชันที่ครอบโค้ด unsafe เหล่านั้นถูกต้องหรือไม่ในภายหลัง
  การติดป้ายผิดชั่วคราวให้ฟังก์ชัน unsafe บางตัวดูเหมือนปลอดภัยในช่วงพอร์ตนั้นไม่ใช่ปัญหาใหญ่มากในตัวมันเอง แต่การ merge มันเข้า main repository ทั้งสภาพนี้ก็ค่อนข้างแปลก
  ปัญหาจริงจะเกิดขึ้นถ้าปล่อยโค้ดสภาพนี้ออก release
  ที่น่าเสียดายคือไม่ได้ตั้งค่าให้รันเทสต์ด้วยmiriทันที เพราะ LLM ตอบสนองต่อเทสต์ที่ดีได้ดีมาก
  ที่ผมคิดแบบนี้ไม่ใช่เพราะ GitHub issue นี้ แต่เพราะเทสต์อีกตัวหนึ่ง [1] เรียกใช้ undefined behavior ที่ miri จับได้จริง เพียงแต่โค้ดที่ถูกเทสต์นั้นดูเหมือนไม่ได้ถูกใช้งานที่ไหน จึงน่าจะมีผลกระทบจริงไม่มาก
  นี่ยังเป็นช่วงต้นของการพอร์ต จึงอาจแก้ทีหลังได้ และอาจลบโค้ด unsafe ที่ไม่จำเป็นออกไปได้จริงด้วย
  [1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - pointer ที่แตกแขนงมาจาก mutable reference ตัวแรกถูกทำให้ใช้ไม่ได้เมื่อมีการสร้าง mutable reference ใหม่ให้กับอ็อบเจ็กต์เดียวกัน จะมองแบบ C ก็คิดว่า “mutable reference” คือ “restrict reference ที่มีการแก้ไขเล็กน้อย” ก็ได้
  ถ้าจะทำให้ถูกต้อง ต้องให้ pointer ทั้งหมดแตกแขนงมาจาก mutable reference ตัวเดียวกัน แต่แค่ไม่ได้ทำแบบนั้น
  ถ้าไประดมคนไปถล่มบน GitHub ก็จะยิ่งทำให้คนอยากทำงานแบบเปิดเผยต่อสาธารณะน้อยลงเท่านั้น หวังว่าจะไม่ทำกัน
  และน่าจะดีกว่าถ้าจะชะลอการตัดสินไว้จนกว่าจะอยู่ในสภาพที่พร้อมเผยแพร่ การประเมินงานระหว่างทางทั้งไม่ค่อยยุติธรรมและไม่ค่อยน่าสนใจด้วย

  • พอโปรเจ็กต์ถึง1.0 แล้ว หลายคนก็คาดหวังว่า branch main จะต้องใช้งานได้เสมอ
    เพราะ CI/CD ก็แทบตั้งอยู่บนสมมติฐานว่าทุก commit ต้องทำงานได้
    งานที่กำลังทำอยู่และยังใช้ไม่ได้อย่างการ rewrite ทั้งระบบควรทำบน branch แยก
    แบบนั้นถึงเวลาต้องทำอย่างแพตช์ความปลอดภัยก็ยังรักษา main ที่ใช้งานได้ไว้ได้

• ผลลัพธ์แบบนี้ไม่น่าแปลกใจ เพราะวิธีที่ขอไปแทบจะเป็นการพอร์ตแบบแปลตรงตัวอยู่แล้ว
  จะมองว่าการย้าย Bun ไปยังภาษาที่มี type system แข็งแรงกว่าก่อน แล้วค่อยใช้ type system นั้นเป็นฐานสำหรับปรับปรุงต่อ ก็ดูเป็นแนวทางที่ดีกว่าไหม
  ดูดีกว่าการเรียกร้องความสมบูรณ์แบบตั้งแต่ขั้นแรก

  • ที่จริงนั่นแหละคือสิ่งที่พวกเขากำลังทำอยู่
    พวกเขากำลังทยอยจัดการ issue ที่เข้ามา
  • แค่เพิ่มคำว่า “อย่าให้มี undefined behavior” ลงไปใน prompt ก็น่าจะดีขึ้นเอง
  • ตอนนี้ดูเหมือนจะกดดันการ rewrite ด้วยเครื่องมืออย่าง miriแล้วให้ Claude Code ปรับปรุงให้อัตโนมัติได้
  • การที่ Rust ซึ่งแปลตรงตัวมาเป็นส่วนใหญ่และมีบางส่วน unsafe จะมี undefined behavior อยู่ก็ไม่น่าแปลกใจ
    แต่ที่น่าผิดหวังคือ API ของโค้ด Rust สามารถก่อ undefined behavior ได้ทั้งที่ไม่ได้ถูกทำเครื่องหมายเป็น unsafe
    ถ้าจะทำการแปลแบบนี้ ผมคงเลือกแนวทางอนุรักษนิยมและทำเครื่องหมายให้ทั้งหมดหรือเกือบทั้งหมดเป็น unsafe ไปก่อน
    แล้วค่อยตรวจสอบความปลอดภัยของแต่ละส่วนทีละขั้น

• พูดตรง ๆ คือค่อนข้างแปลกใจที่บอกว่าทำให้มันใช้งานได้ครบภายในสัปดาห์เดียว
  side project ของผม https://tsz.dev ก็มีความทะเยอทะยานคล้ายกัน แต่ผมยังอ้างว่ามันสำเร็จไม่ได้
  ผมยังคงเพิ่มเทสต์เพื่อตรวจสอบพฤติกรรมอยู่เรื่อย ๆ และแม้จะผ่านชุดเทสต์ของ TypeScript ทั้งหมดแล้ว ก็ยังเจอบั๊กตามที่คาดไว้
  มาตรฐานที่จะให้**ตรงกับพฤติกรรมของ tsc**นั้นสูงมากจริง ๆ
  https://github.com/type-challenges/type-challenges
  ผมไม่ได้คัดค้านการใช้ LLM เขียนโค้ดจำนวนมาก แต่ตอนนี้ที่เราดึงโค้ดออกมาได้เร็วระดับนี้ การตรวจสอบก็ควรแข็งแรงขึ้นอีกสัก 100 เท่า

  • สิ่งที่น่าตกใจคือการ mergeโค้ดระดับล้านบรรทัดที่เป็น “การทดลอง” และมีโอกาสสูงมากว่าแทบไม่ได้รับการ review ภายในสัปดาห์เดียว
    ผมไม่ได้ต่อต้านการใช้ agent แต่การเร่งเรื่องแบบนี้แล้วทำให้ชุมชนตกใจทีเดียวนั้นดูเป็นมือสมัครเล่นมาก
    เป็นพฤติกรรมที่น่าคาดจากวิศวกรใหม่ไฟแรงมากกว่า
  • https://tsz.dev/sound-mode/
    นี่เยี่ยมมาก TypeScript ต้องการอะไรแบบนี้มากกว่านี้ และหวังว่ามันจะเป็นที่รู้จักมากขึ้นจน Microsoft อาจรับไปใช้ด้วย
    แต่คิดว่าควรระวังการเรียกมันว่าsound mode
    ประโยคที่ว่า “มันไม่ใช่การพิสูจน์ความ sound ในความหมายทางคณิตศาสตร์ และไม่ได้ทำให้ไฟล์ .d.ts ของ third-party กลายเป็นจริง” นั้นเอาสองเรื่องที่ต่างกันโดยสิ้นเชิงมาปนกัน
    อย่างแรก soundness เป็นแนวคิดทางคณิตศาสตร์ ถ้าบางอย่าง sound มันก็คือ sound จริง ๆ หมายความว่าคุณเชื่อคอมไพเลอร์ได้โดยไม่ต้องไปตรวจรายละเอียดเองทีละจุด
    ถ้ามีบั๊กในการ implement มันก็อาจทำงานผิดได้ แต่แก้ได้ และ soundness หมายถึงในเชิงทฤษฎีแล้ว specification หรือ type system เองไม่มีบั๊กที่ทำให้ผิดได้
    อย่างที่สอง ในภาษาจริง การมีฟีเจอร์ที่ไม่ถูกตรวจสอบและต้องอาศัยมนุษย์ใช้ให้ถูกต้องนั้นเป็นเรื่องปกติและยอมรับได้ เช่น unsafeCoerce ของ Haskell หรือ sun.misc.unsafe ของ Java
    ปัญหาจริงคือกรณีที่ type system พังทั้งที่ไม่ได้ใช้ฟีเจอร์พวกนั้น
  • จะเรียกว่ามันใช้งานได้ก็เกินจริงไปหน่อย
    ผมดูโค้ดไม่กี่นาที แต่รู้สึกว่าแค่เปิด optimization ก็น่าจะพังหนักแล้ว
  • พวกเขาอาจวางแผนและทดลองเรื่องนี้มาหลายเดือน
    นอกจากจะมีชุดเทสต์เดิมขนาดใหญ่แล้ว ยังมีเครื่องมือสำหรับทำ agent ให้ขนานกันและงบ token ที่แทบไม่จำกัดด้วย จึงไม่ต้องท้อเกินไป

• มีหนังสือเล่มหนึ่ง [0] ที่เปลี่ยนความคิดผมเรื่องความสนใจและสื่อไปมาก
  ตัวหนังสือเองอาจไม่ได้ยอดเยี่ยมนัก แต่ชี้ประเด็นที่เกี่ยวข้องตรงนี้ไว้
  มีความไม่สมมาตรอย่างมหาศาลระหว่างการเข้าถึงของการประกาศใหญ่โตหวือหวา เช่นข้อความว่า “Bun ถูก rewrite เป็น Rust ที่ memory-safe ภายในไม่กี่สัปดาห์” กับการเข้าถึงของการแก้ข่าว เช่นเชิงอรรถในบทความเก่าหรือ GitHub issue
  ความไม่สมมาตรนี้เป็นสิ่งที่วงการการตลาดและ PRเข้าใจดีและใช้ประโยชน์อย่างจริงจัง
  [0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying

  • จากบรรยากาศครั้งนี้ ดูเหมือนมีคนจำนวนมากพยายามหาเสียงวิจารณ์โค้ดอะไรก็ได้แล้วขยายมันให้ดังที่สุด
    ตอนนี้ส่วนใหญ่ยังดูค่อนข้างผิวเผิน
    การ merge งานพอร์ตขนาดใหญ่ที่มี LLM ช่วยนั้นเป็นการตัดสินใจที่กล้ามากแน่นอน แต่ในผลลัพธ์จริง ๆ สิ่งที่คนชี้กันอยู่หลายอย่างก็ไม่ได้รู้สึกว่าแย่ไปกว่างานพอร์ตที่ยังทำไม่เสร็จอื่น ๆ นัก
    ทุก issue ที่เจอกำลังถูกทำให้ใหญ่เกินจริง
  • ผมยังสงสัยอยู่เลยว่าพวกเขาอ้างจริงไหมว่าmemory-safe
    ทุกการถกเถียงในหัวข้อนี้เต็มไปด้วยคอมเมนต์เป็นสิบ ๆ อันที่บอกว่า codebase จาก vibe coding นี้พร้อมจะระเบิดด้วยบล็อก unsafe ที่ไม่ผ่านการ audit และถูกรีวิวแบบลวก ๆ โดยคนที่ดูเหมือนไม่เข้าใจ Rust
    ถึงขั้นเหมือนบางคนโมโหกับแนวคิดที่ว่าคุณควรเข้าใจภาษาโปรแกรมใด ๆ ที่จะใช้งานด้วยซ้ำ
  • นี่ใช่แนวคิดเดียวกับคำพูดที่ว่า “คำโกหกเดินทางรอบโลกไปครึ่งหนึ่งก่อนที่ความจริงจะทันใส่รองเท้า” หรือเปล่า
  • ไม่ใช่แค่การตลาดกับ PR เท่านั้น สื่อกระแสหลักก็รู้เหมือนกันว่าปล่อยข่าวมั่วออกไปก่อนแล้วค่อยถอนทีหลังยังมีผลคงอยู่
    คนมักจำบทความเดิมหรือพาดหัวได้ แต่ไม่เคยเห็นคำแก้ข่าว
  • ผมนึกว่าคุณจะพูดถึงปัญหาในทางตรงกันข้ามเสียอีก
    การพอร์ตยังทำไม่เสร็จ จึงยังไม่มีการประกาศใหญ่โตหวือหวา และมันยังไม่เสร็จหรือถูกปล่อยออกมา
    สิ่งหวือหวาที่ผมเห็นกลับเป็นการล้อเลียนแบบเข้าแล้วออกต่อโค้ดที่ยังทำไม่เสร็จ และความพยายามจะสื่อเป็นนัยว่าทีมเหมือนเคยบอกว่างานเสร็จแล้วหรือสมบูรณ์แบบ
    การ rewrite นี้เป็นการแปลโค้ดเพื่อใช้เป็นจุดตั้งต้น
    ทีม Bun ไม่เคยประกาศใหญ่โตว่าโค้ดตอนนี้ memory-safe แล้ว และพูดชัดมาตลอดว่ามันเป็นเพียงจุดเริ่มต้น
    การคาดหวังว่ามันควรสมบูรณ์แบบทันทีและแก้ปัญหาหน่วยความจำทุกอย่างจากโค้ด Zig เดิมได้ทั้งหมด จึงเหมือนกำลังเถียงกับคำประกาศที่จินตนาการขึ้นมาเอง ไม่ใช่สิ่งที่ทีม Bun ประกาศจริง
    ผมก็สงสัยเหมือนกันว่ามีใครลองแมปไหมว่าปัญหา memory นี้มีอยู่ใน codebase เดิมด้วยหรือไม่

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

  • ข้อผิดพลาดแบบนี้หลีกเลี่ยงได้มากพอสมควร
    ecosystem ของ Rust มีเครื่องมือที่รู้จักกันดีสำหรับจับข้อผิดพลาดแบบนี้ และถึงจะจับ undefined behavior ที่เกิดจากความผิดพลาดในบล็อก unsafe ได้ไม่หมด แต่การรันมันก็ถือเป็นแนวปฏิบัติที่ดี

• สิ่งที่ผมกังวลที่สุดคือบทสนทนาระดับเมตา
  ตอนแรกผมมองเชิงวิจารณ์ต่อผู้ดูแลที่ปิด GitHub issue นี้ว่าไม่เกี่ยวกับหัวข้อ
  แต่ UI ของ GitHub ก็กำลัง auto-fold ข้อความจำนวนมากที่ไม่มีคุณค่าด้านข้อมูลเลย และข้อความเหล่านั้นดูเหมือนมาจากการระดมคนจากฟอรัมหรือ community Discord
  สถานการณ์นี้ทำให้ทุกฝ่ายแพ้
  คนที่ค้นพบปัญหาร้ายแรงซึ่งชุมชนที่เกี่ยวข้องจำนวนมากสมควรกังวล ย่อมมีเหตุผลมากพอที่จะบอกให้กว้างที่สุดเท่าที่ทำได้
  มันเป็นคำร้องที่มีเนื้อหาจริงเกี่ยวกับการเปลี่ยนแปลงล่าสุด และการไปจับเรื่องน้ำเสียงไม่ได้ทำให้ข้อเท็จจริงหายไป
  ปัญหาคือความสนใจที่เพิ่มขึ้นกลับฆ่าการสนทนาไปแบบตรงตัว
  และอาจกลายเป็นเกราะป้องกันให้คนฝั่งผู้ดูแลที่ตัดสินใจด้วยอารมณ์มากเกินไป หรือถึงขั้นคล้าย AI psychosis ด้วย
  โปรเจ็กต์ที่มีจิตวิทยาแบบถูกปิดล้อมจนบล็อกและเมินคำวิจารณ์มักออกนอกลู่นอกทางได้เร็วมาก
  ในทางกลับกัน โปรเจ็กต์ที่ปกป้องผู้ดูแลจากความกังวลและอาการหมกมุ่นกับ AI ไม่ได้เลย ก็หนีไม่พ้นภาวะหมดไฟของผู้ดูแลเช่นกัน

• การ rewrite Bun ครั้งนี้ให้ความรู้สึกเหมือนเป็นอีเวนต์ที่อาจถูกใช้ทำการตลาด Mythos

  • จนถึงตอนนี้ยังไม่มีใครในทีม Bun หรือ Anthropic โหมการตลาดเรื่องนี้เกินกว่าการบอกว่ามันคือการย้ายไปยังภาษาที่มีการรับประกันจากคอมไพเลอร์ดีกว่าและ memory-safe มากกว่า
    กระแสและการโปรโมตทั้งหมดจนถึงตอนนี้ส่วนใหญ่มาจากปฏิกิริยาเชิงลบของคนที่ต่อต้าน AI
    ผมคิดว่าส่วนหนึ่งก็พัวพันกับภาพลักษณ์เชิงลบต่อ Anthropic ที่เพิ่มขึ้นจากการตัดสินใจบางอย่างของ Anthropic ในช่วงหลังด้วย
  • มันดูเหมือนcorporate rug pullมากกว่า
    ให้ความรู้สึกว่าความต้องการของ Anthropic เป็นสิ่งสำคัญเพียงอย่างเดียว และอย่างอื่นไม่สำคัญ
  • พวกเขาเอาการ rewrite ไปรันด้วยเงินไม่รู้เท่าไรบน token แบบไม่จำกัด
    แล้วออกมาพูดเสียงดังพร้อมเขียนบล็อกว่า “Claude Code ทำให้ทีม Bun rewrite Zig กว่า 1 ล้านบรรทัดเป็น Rust ได้” จน VC น้ำลายไหล
    แต่ไม่ผ่านการตรวจพื้นฐาน
    แล้วก็ปล่อยให้ Mythos ฉีก codebase จนเละโดยไม่รู้ว่าเผาเงินไปอีกเท่าไร
    เขียนบล็อกแยกอีกโพสต์
    พวกนักต้มตุ๋นกับคนใสซื่อก็ปรบมือและปกป้องมันเพื่อต่อต้าน “ฝูงชนแอนตี้ AI ที่เพ้อคลั่ง”
    VC ก็ยิ่งตื่นเต้นกว่าเดิม
    นี่แหละวิธีหาเงิน
    แล้วเรื่องก็ไหลไปต่อในทำนองว่าตอนนี้ควรกำจัดวิศวกรซอฟต์แวร์ได้แล้ว

• มีทั้ง codebase จากภาษาที่ไม่ปลอดภัย และยังมี binding จากอีกภาษาที่ไม่ปลอดภัยซ้อนเข้ามาอีก ผมไม่เข้าใจว่าทำไมถึงสมมติว่ามันจะดูสมบูรณ์แบบได้ทันที