ความเห็นของผมต่อการเขียน Bun ใหม่ด้วย Rust

 (en.liujiacai.net)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การเขียน Bun ใหม่ด้วย Rust ใกล้เคียงกับการตัดสินใจย้ายไปใช้เทคโนโลยีสแตกที่เป็นกระแสหลักมากขึ้น โดยยังคง สถาปัตยกรรมและโครงสร้างข้อมูลเดิม ที่สร้างไว้ด้วย Zig
  • PR สำหรับการเขียนใหม่นี้มีขนาดใหญ่ถึง 6,755 คอมมิต เปิดเมื่อวันที่ 8 พฤษภาคมและถูกรวมเมื่อวันที่ 14 พฤษภาคม จึงยังชวนให้ตั้งคำถามถึงความลึกของการรีวิวสำหรับการเปลี่ยนแปลงรันไทม์ระดับโปรดักชัน
  • การที่เทสต์ผ่านยืนยันได้เพียงเส้นทางที่รู้จักเท่านั้น และยากที่จะรับประกัน อินวาเรียนต์ระดับระบบทั้งหมด เช่น เส้นทางข้อผิดพลาด ภาวะพร้อมกัน และสภาวะหน่วยความจำสุดขั้ว
  • ประเด็นสำคัญไม่ใช่ความล้มเหลวของ Zig แต่เป็นความไม่สอดคล้องเชิงโครงสร้างระหว่างวัฒนธรรมทีม Bun ที่ให้ความสำคัญกับการปล่อยของให้เร็ว กับ ต้นทุนของการจัดการหน่วยความจำด้วยมือ
  • การเดิมพันจริงไม่ใช่ Zig ปะทะ Rust แต่คือการดูว่า โค้ดที่ AI สร้างขึ้นและไม่ได้รับการรีวิวอย่างเพียงพอ จะบำรุงรักษาได้ในระยะยาวหรือไม่

รากฐานของ Bun ที่ Zig สร้างขึ้น

  • ก่อนจะดู PR การเขียน Bun ใหม่ด้วย Rust ต้องยอมรับว่า Zig มีบทบาทสำคัญ ที่ทำให้ Bun มาถึงจุดปัจจุบัน
  • เหตุผลที่ Jarred เลือก Zig ไม่ใช่เพราะ “มันเท่” แต่เพราะมันทำให้ทีมเล็กสามารถสร้างต้นแบบ JS runtime ประสิทธิภาพสูงที่ไม่มี garbage collection ได้อย่างรวดเร็ว
  • ความเสียดทานต่ำของ Zig การจัดการหน่วยความจำโดยตรง และการทำงานร่วมกับ C ที่เรียบง่าย ช่วยให้ Bun ยุคแรกมีทั้งประสิทธิภาพสูงและใช้ทีมขนาดเล็กได้
  • เมื่อ Jarred บอกว่า “สถาปัตยกรรมจะไม่เปลี่ยน และโครงสร้างข้อมูลก็จะไม่เปลี่ยน” การเขียนใหม่ด้วย Rust จึงใกล้เคียงกับการสืบทอด โครงกระดูกที่สร้างด้วย Zig
  • การสร้างรากฐานด้วย Zig เปิดตัวผลิตภัณฑ์ ระดมทุน แล้วเมื่อบริษัทถูกซื้อกิจการและขยายใหญ่ขึ้นจึงย้ายไปสู่เทคโนโลยีที่เป็นกระแสหลักกว่า ถือได้ว่าเป็นการตัดสินใจทางธุรกิจที่ปกติ
  • แต่ก็ยากจะอธิบายเรื่องนี้ว่าเป็นเพราะ Zig เองไม่เหมาะสม

ความเสี่ยงของการเขียนใหม่ขนาดใหญ่ที่ถูกรวมภายใน 6 วัน

  • PR การเขียนใหม่ ทิ้งสถิติไว้ที่ 6,755 คอมมิต ใช้ชื่อแบรนช์ claude/phase-a-port เปิดเมื่อ 8 พฤษภาคมและถูกรวมเมื่อ 14 พฤษภาคม
  • ประเด็นหลักคือการเขียน JS runtime ระดับโปรดักชันใหม่ทั้งก้อน ถูกรวมภายใน 6 วัน
  • หลักพื้นฐานของวิศวกรรมซอฟต์แวร์คือ “โค้ดที่ยังไม่เข้าใจ ไม่ควรรันในโปรดักชัน”
  • หลักการนี้ไม่ได้หมายความว่าโค้ดนั้นต้องมีบั๊กเสมอไป แต่หมายถึงเมื่อบั๊กเกิดขึ้น เราจะไม่รู้ว่าควรเริ่มดูจากตรงไหน และนี่คือเส้นฐานของความสามารถในการบำรุงรักษา
  • ในรายชื่อผู้รีวิวของ PR มี coderabbitai[bot], claude[bot] และผู้รีวิวที่เป็นมนุษย์เพียงคนเดียวคือ alii ซึ่งอยู่ในสถานะ “Awaiting requested review”
  • วงจรปิดแบบ Claude เขียนแล้ว Claude รีวิว อาจไม่ใช่เรื่องที่เป็นไปไม่ได้ในเชิงตรรกะ แต่ผลลัพธ์คือไม่มีมนุษย์คนใดอ่านโค้ดเบสทั้งหมดจนจบจริง ๆ

สิ่งที่การทดสอบผ่านยังรับประกันไม่ได้

  • แม้เทสต์สวีตจะผ่านบนทุกแพลตฟอร์ม แต่นั่นก็ยืนยันได้เพียงความถูกต้องของ พฤติกรรมและเส้นทางที่รู้จัก
  • เทสต์สวีตยากที่จะรับประกันพื้นที่ต่อไปนี้ได้อย่างเพียงพอ
    • เส้นทางข้อผิดพลาดถูกจัดการอย่างถูกต้องหรือไม่
    • ระบบจะทำงานอย่างไรที่เงื่อนไขขอบเขตภายใต้ภาวะกดดัน
    • ความสอดคล้องของสถานะยังคงอยู่หรือไม่ในสถานการณ์ที่มีภาวะพร้อมกัน
    • โมเดลหน่วยความจำภายใต้สภาวะสุดขั้วสอดคล้องกับเจตนาหรือไม่
  • มีการสรุปว่า Jarred เองก็ยอมรับว่าปัญหาหน่วยความจำเมื่อต้องกลับเข้าสู่ขอบเขตของ JS อีกครั้งนั้น Rust compiler ไม่สามารถจัดการให้ได้ และยังต้องพึ่งพามนุษย์อยู่ดี
  • ปัญหาคือส่วนที่ยังต้องพึ่งพามนุษย์นั้น ไม่ได้ถูกรีวิวโดยมนุษย์
  • การแปลโค้ดโดย AI มีลักษณะใกล้เคียงกับการทำให้แต่ละฟังก์ชันทำงานเหมือนต้นฉบับในสภาวะแยกส่วน หรือ ความเท่าเทียมกันเชิงความหมายในระดับเฉพาะจุด
  • แต่เรื่องอย่างอินวาเรียนต์ระดับระบบระหว่างฟังก์ชัน หรือข้อจำกัดด้านการออกแบบที่ไม่ได้ถูกเขียนไว้ในเทสต์และมีอยู่แค่ในหัวของผู้เขียนเดิมนั้น ยากที่จะรับประกันได้ด้วยการแปลโดย AI เพียงอย่างเดียว
  • ข้อจำกัดเหล่านี้อาจไม่ปรากฏในเทสต์ปัจจุบัน แต่ไปโผล่เป็นการล่มที่อธิบายได้ยากภายใต้โหลดโปรดักชันบางแบบในอีก 6 เดือนข้างหน้า
  • นี่ไม่ใช่ปัญหาเฉพาะของ Claude แต่รวมถึงทุกเครื่องมือและแม้แต่นักพัฒนาที่เป็นมนุษย์ หากมีการแปลโดยไม่มีการรีวิวอย่างเพียงพอ
  • และในงานขนาด 6,755 คอมมิต ความเสี่ยงนี้จะยิ่งทวีคูณ

หลังการซื้อกิจการ ผู้แบกรับความเสี่ยงได้เปลี่ยนไป

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

ความผิดพลาดในการวิเคราะห์ว่าเป็นปัญหาของ Zig

  • เหตุผลก่อนหน้านี้ที่ Jarred ยกมาคือ ในโค้ดเบส Zig มีปัญหา use-after-free, double-free และ memory leak บนเส้นทางข้อผิดพลาดจำนวนมาก
  • การวินิจฉัยนี้อาจถูกต้องในตัวมันเอง แต่ยากจะสรุปจากจุดนี้ต่อว่า “Zig ใช้งานไม่ได้”
  • การวินิจฉัยที่แม่นกว่าคือ ในโครงการเชิงพาณิชย์ที่ให้ความสำคัญกับการทำซ้ำอย่างรวดเร็ว ต้นทุนทางการรับรู้ของการจัดการหน่วยความจำด้วยมือ สูงเกินงบประมาณของทีม
  • นี่ไม่ใช่บั๊กของ Zig แต่เป็นความไม่สอดคล้องเชิงโครงสร้างระหว่างเป้าหมายการออกแบบของ Zig กับโมเดลธุรกิจของ Bun
  • กลุ่มผู้ใช้เป้าหมายของ Zig คือ system programmer ที่รู้ว่าตัวเองกำลังทำอะไร และยินดีจ่ายต้นทุนเพื่อแลกกับการควบคุมขั้นสุดท้าย
  • TigerBeetle เขียนฐานข้อมูลด้วย Zig โดยแทบไม่มีบั๊กด้านหน่วยความจำ ซึ่งสรุปได้ว่าเป็นเพราะวัฒนธรรมทีมและลักษณะของโครงการสอดคล้องกับปรัชญาของ Zig
  • วัฒนธรรมทีม Bun โน้มเอียงไปทางการทำซ้ำเร็ว ปล่อยเร็ว และแก้บั๊กเร็ว ซึ่งมีความตึงเครียดโดยพื้นฐานกับวินัยด้านหน่วยความจำที่ Zig เรียกร้อง
  • การตีความว่า “ทีมของเราพลาดบ่อยเมื่อใช้เครื่องมือนี้” เท่ากับ “เครื่องมือนี้ไม่เหมาะสม” นั้นใกล้เคียงกับ ความผิดพลาดด้านการระบุสาเหตุ
  • มีการใช้อุปมาว่าเพียงเพราะค้อนไม่ใช่เครื่องมือที่เหมาะกับงาน ก็ไม่ได้แปลว่าค้อนเป็นฝ่ายผิด

แนวโน้มระยะสั้นและความเสี่ยงระยะยาว

  • ในระยะสั้น เวอร์ชันที่เขียนใหม่มีแนวโน้มค่อนข้างสูงว่าจะใช้งานได้ดีโดยรวม
  • เส้นทางหลักถูกครอบคลุมด้วยเทสต์ ปัญหาที่ชัดเจนจะถูกเปิดเผยในขั้น canary และการรับประกันจาก Rust compiler จะช่วยตัดบั๊กหน่วยความจำบางประเภทออกไป
  • ในระดับผิวเผิน ทุกอย่างอาจดูปกติ
  • แต่ในระยะยาว 6,755 คอมมิตที่ไม่มีมนุษย์อ่านครบทั้งหมด จะยังคงเป็นความเสี่ยงเชิงโครงสร้าง
  • หากอีก 6 เดือนข้างหน้าเกิดบั๊กภาวะพร้อมกันแปลก ๆ หรือเงื่อนไขขอบเขตภายใต้โหลดบางแบบทำให้เกิดพฤติกรรมผิดปกติ วิศวกรที่ต้องดีบักจะต้องเผชิญกับระบบที่ไม่เคยมีใครเข้าใจมันอย่างแท้จริง
  • คำว่าระบบที่ไม่เคยถูกเข้าใจ ไม่ได้หมายความว่าไม่มีบั๊ก แต่หมายความว่าเมื่อบั๊กปรากฏขึ้น จะไม่มีใครรู้ว่าทำไมมันถึงเกิดขึ้น
  • การเดิมพันทางเทคนิคที่แท้จริงของการเขียนใหม่ครั้งนี้จึงไม่ใช่ Zig ปะทะ Rust แต่คือการดูว่า โค้ดที่ AI สร้างและไม่ได้รับการรีวิว จะสามารถบำรุงรักษาในสภาพแวดล้อมโปรดักชันระยะยาวได้หรือไม่
  • คำถามนี้ซับซ้อนกว่า “เทสต์ผ่านทั้งหมด” และลึกกว่า “ความปลอดภัยหน่วยความจำของ Rust”
  • ข้อสรุปถูกย่อไว้ในอุปมาว่า “Zig สร้างฐานราก, Claude สร้างตัวอาคาร, และผู้รีวิวที่เป็นมนุษย์ยังมาไม่ถึง”
  • อาคารนี้จะอยู่อาศัยได้ยาวนานแค่ไหน ขึ้นอยู่กับว่าเมื่อการรั่วครั้งแรกเกิดขึ้น จะมีใครสักคนอ่านแบบแปลนได้หรือไม่

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

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

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Lobste.rs

  • ก่อนจะคุยกันว่า “มาเขียน Bun ใหม่ด้วย Rust กันเถอะ” ก็ควรพูดก่อนว่า Bun มาถึงจุดนี้ได้ก็เพราะ Zig
    Jarred ผู้สร้าง Bunก็พูดแบบนั้นอยู่ เขาบอกว่า Zig คือสิ่งที่ทำให้ Bun เป็นไปได้ และ Zig มีส่วนอย่างมากที่ทำให้โปรเจ็กต์ซึ่งเขาเขียนโค้ดคนเดียวอยู่ 1 ปีในห้องเหม็น ๆ ที่ Oakland เติบโตจนกลายเป็นหนึ่งในเครื่องมือที่ถูกใช้อย่างแพร่หลายที่สุดใน ecosystem ของ JavaScript
    เขายังบอกอีกว่า Zig เป็นภาษาที่ยอดเยี่ยม และ Bun ติดหนี้ความสำเร็จไว้กับมันมาก แต่โปรเจ็กต์อื่นอย่าง Ghostty หรือ Tigerbeetle ไม่ได้เจอปัญหาด้านเสถียรภาพแบบที่ Bun เจอ

    • ถ้า “โปรเจ็กต์อื่นอย่าง Ghostty หรือ Tigerbeetle ไม่ได้เจอปัญหาด้านเสถียรภาพแบบที่ Bun เจอ” ก็น่าถามว่าทำไม
      เพราะโดยปกติแล้ว ฐานข้อมูล มีโจทย์ด้านเสถียรภาพหนักกว่าภาษา runtime มาก

  • บทความนี้มีกลิ่นของ ข้อความที่ LLM เขียน แรงมาก

    • ดูเหมือนว่าภาษาหลักของผู้เขียนจะเป็นภาษาจีน เช่น: https://liujiacai.net/ai/litellm-poisoning-analysis/
      เพราะงั้นความรู้สึกแบบนั้นอาจเป็นร่องรอยของ การแปลด้วยเครื่อง ก็ได้

  • ถ้ากลุ่มผู้ใช้เป้าหมายของ Zig คือ “system programmer ที่รู้ว่าตัวเองกำลังทำอะไร และพร้อมจ่ายราคาเพื่ออำนาจควบคุมสูงสุด” มันก็ดูเหมือน ความมั่นใจเกินแบบ C/C++ ที่กลับมาใหม่อีกครั้งในบริบทของภาษาที่ออกมาหลัง Rust และ Swift
    ถ้าเหตุผลที่ Jarred ย้ายคือ “ใน codebase ของ Zig มีทั้ง use-after-free, double free, และ memory leak ในเส้นทาง error มากเกินไป” ก็ถือเป็นข้อมูลประกอบว่าการให้ LLM ช่วยไล่หา memory safety bug อย่างหนัก จะทำให้ภาษาที่ไม่ปลอดภัยด้านหน่วยความจำกลายเป็นปลอดภัยได้จริงหรือไม่
    แม้แต่บริษัท LLM เองก็ไม่ได้เลือกเดินเส้นนั้น

  • คำพูดที่ว่า “โค้ดนี้ Claude เขียนและ Claude ก็เป็นคนรีวิว ดังนั้นวงปิดนี้ไม่ได้เป็นไปไม่ได้ในเชิงตรรกะ แต่ก็หมายความว่าไม่มีมนุษย์คนไหนเคยอ่าน codebase นี้ทั้งก้อนจริง ๆ” ดูชัดเจนว่าไม่ถูกต้อง
    ถ้าเอา codebase Zig ที่มนุษย์เขียนมาแปลเชิงกลเป็น Rust คนที่เข้าใจโค้ดเดิมก็ย่อมเข้าใจโค้ดใหม่ได้ ไม่ใช่ว่าจะย้ายไป APL เสียหน่อย ทั้งคู่ก็เป็นภาษาเชิงกระบวนวิธีในสายไวยากรณ์แบบ C
    ประเด็นที่ว่า ถ้าปล่อย LLM ทำงานโดยไม่มีการกำกับต่อไป โค้ดอาจค่อย ๆ ห่างจากสัญชาตญาณของมนุษย์เรื่อย ๆ นั้นยังถกกันได้ แต่ codebase ณ ตอนนี้ก็ดูยังเข้าใจได้อยู่ ในระดับที่ JavaScript runtime ขนาดล้านบรรทัดและเครื่องมือสารพัดประโยชน์แบบไบนารีเดียวพึงจะเป็น
    ประโยคที่ว่า “AI ทำได้แค่รักษาความสมมูลของความหมายเชิงเฉพาะจุดในระดับฟังก์ชัน แต่ไม่เข้าใจ invariant เชิง global ระหว่างฟังก์ชัน” ก็ดูแปลกทั้งในมุมที่เข้าข้าง LLM และในมุมวิจารณ์
    LLM ไม่ได้มีความเป็นเชิงกำหนดมากพอจะรับประกันได้ว่าทุกฟังก์ชันทำงานเหมือนต้นฉบับ การรับประกันแบบนั้นต้องใช้เครื่องมืออย่าง c2rust LLM แปลโค้ดที่ดูเหมือนต้นฉบับได้ แต่สิ่งที่จะกันไม่ให้มันเปลี่ยน ((abc & 45) << 3) == 360 เป็น ((abc & 45) << 30) == 360 ก็คือคอมไพเลอร์ ชุดทดสอบ และอาจรวมถึงการตรวจโค้ดด้วย LLM ที่ตรวจจับแบบน่าจะเป็นเท่านั้น
    ในทางกลับกัน ถ้ามีตัวแปลที่รับประกันความเหมือนกันของแต่ละฟังก์ชันแบบ c2rust พร้อมทั้งรักษาคอมเมนต์และโครงสร้างไว้ได้แบบ LLM นั่นก็คือ ตัวแปลที่สมบูรณ์แบบ และคงพอร์ต codebase ระดับล้านบรรทัดได้อัตโนมัติ คอมไพเลอร์เองก็มองเป็นกรณีพิเศษแบบนี้ได้ และ Clang แม้จะไม่ไร้บั๊ก แต่ก็ใกล้เคียงพอที่ผู้คนจะเชื่อถือได้ ถ้า LLM แปล Zig หรือ C++ เป็น Rust ได้ด้วยความน่าเชื่อถือระดับ Clang ตอนสิ้นเดือนนี้ Chrome ก็คงกลายเป็น Rust ล้วนไปแล้ว
    อีกอย่าง การเข้ารหัส invariant ระหว่างฟังก์ชันก็คือแก่นสำคัญของ ระบบชนิดข้อมูล อยู่แล้ว และหนึ่งในเหตุผลที่เขียน Bun ใหม่ด้วย Rust ก็คือระบบชนิดข้อมูลของ Rust สามารถแสดง invariant ที่ซับซ้อนได้ดีกว่า ไม่ใช่ว่า Anthropic คอมไพล์ทุกอย่างลง assembly แล้วเผา source code ทิ้งเสียหน่อย

    • ประโยคที่ว่า “ถ้าเอา codebase Zig ที่มนุษย์เขียนมาแปลเชิงกลเป็น Rust คนที่เข้าใจโค้ดเดิมก็ย่อมเข้าใจโค้ดใหม่ได้” น่าจะถูก optimize หายไปหมดใน release fast :^)
      Bun ถูก vibe coding มาตั้งแต่ก่อนจะย้ายไป Rust เสียอีก รับ AI มาใช้ค่อนข้างเร็ว และหลัง Anthropic เข้าซื้อ ก็คอมมิตแทบทั้งหมดก็เป็นบอตเขียน Jarred เองก็เคยทวีตว่าให้ AI เขียนฟีเจอร์ช่วงสุดสัปดาห์จนเพิ่มฟีเจอร์ได้หลายอย่าง
    • นอกเหนือจากที่ Kristoff ชี้ว่า Bun ไม่ใช่ codebase ที่มนุษย์เขียนมานานแล้ว ผู้เขียนดูจะสมมติว่า Claude พอร์ตแบบเชิงกล แต่ในความเป็นจริงดูไม่ใช่แบบนั้น
      HTML Parsers in Portland วิเคราะห์การพอร์ตหลายแบบของ HTML parser ใน Python และแสดงให้เห็นว่าอัลกอริทึมแกนตัวหนึ่งถูก implement ต่างกันมากในแต่ละตัวพอร์ต ทั้งที่ทุกกรณีสามารถพอร์ตแบบเชิงกลได้ แต่ของจริงกลับไม่เป็นแบบนั้น
      แน่นอนว่านี่เป็นกรณีจากช่วงต้นปีและกระบวนการก็แตกต่างกัน แต่ชิ้นส่วนบางอย่างที่เห็นใน codebase ของ Bun หลังการพอร์ตก็ดูเหมือนเจอปัญหาคล้ายกัน
    • คำพูดที่ว่า “ถ้าเอา codebase Zig ที่มนุษย์เขียนมาแปลเชิงกลเป็น Rust คนที่เข้าใจโค้ดเดิมก็ย่อมเข้าใจโค้ดใหม่ได้” นั้นถูกต้องในตัวมันเอง
      แต่ประเด็นที่ว่า “LLM ไม่ได้มีความเป็นเชิงกำหนดมากพอจะรับประกันได้ว่าทุกฟังก์ชันทำงานเหมือนต้นฉบับ” ก็สุดท้ายพาไปสู่ข้อสรุปว่า ไม่มีมนุษย์คนไหนได้อ่าน codebase ทั้งหมดจริง ๆ

  • ตัวอย่างหนึ่งของคำว่า “ทุกเทสต์ผ่าน”: https://github.com/oven-sh/bun/…

    • การเปลี่ยนแปลงในคอมมิตนั้นไม่ได้อยู่ใน diff สุดท้าย และถ้าตรวจเองก็ดูออกได้ไม่ยาก
      จากที่เห็นว่าหลายคนในฟอรัมอื่นก็ลิงก์คอมมิตเดียวกัน ดูเหมือนว่าจะมีคนเห็นลิงก์นั้นจากที่ไหนสักแห่งแล้วรู้สึกว่ามันตรงกับความคาดหวังของตัวเอง เลยไม่ได้ตรวจว่ามันเกี่ยวข้องจริงไหม ผมคิดว่าเราควรตั้งมาตรฐานกับตัวเองให้สูงกว่านี้
    • ไม่ว่าจะดีหรือแย่ คอมมิตนั้นเป็น คอมมิตที่มนุษย์เขียน ซึ่งย้อนบางส่วนของคอมมิตก่อนหน้าที่มนุษย์เขียนไว้
      คอมมิตแรก: “await process exit / JSON-parse-retry instead of fixed sleeps”
      คอมมิตย้อนกลับ: “test: revert proc.exited change in spawn.test.ts, keep isDebug iteration count”

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

  • เขาบอกว่า “Zig ทำให้ทีมเล็ก ๆ สามารถสร้างต้นแบบ JS runtime ประสิทธิภาพสูงได้อย่างรวดเร็ว โดยไม่ต้องมี garbage collector หรือ runtime หนัก ๆ” แต่ Node และ Deno ซึ่งเป็น runtime หลักตัวอื่นก็ทำแบบเดียวกันอยู่
    ทั้งคู่ห่อหุ้ม JS engine ด้วยภาษาไร้ garbage collector อย่าง C++ และ Rust ผมไม่แน่ใจว่า V8 หรือ JSC เองถือว่าจัดส่งมาพร้อม garbage collector หรือเปล่า แต่ประเด็นนั้นก็ไม่ใช่สาระสำคัญ

  • ทั้ง repository ของ Bun ให้ความรู้สึกเหมือนโลกดิสโทเปีย บอตคุยกันเองแล้วสร้าง PR เพี้ยน ๆ ออกมา
    ตัวอย่าง: https://github.com/oven-sh/bun/issues/30766

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