ผู้สร้าง Zig พูดความจริง แต่ Anthropic กำลังพูดโม้

 (raymyers.org)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ขณะที่ Anthropic ชู จุดจบของวิศวกรรมซอฟต์แวร์ เป็นคุณค่าในอนาคต การเปลี่ยนผ่านของ Bun จาก Zig ไปเป็น Rust ก็ถูกวิจารณ์ว่าโดนนำไปใช้เป็นส่วนหนึ่งของเรื่องเล่าเชิงประชาสัมพันธ์ว่า AI สามารถแทนที่งานวิศวกรรมได้
  • Bun อ้างเรื่องบั๊กหน่วยความจำเป็นเหตุผลของการย้ายภาษา แต่ขาดการเปรียบเทียบ ทางเลือกและข้อดีข้อเสีย อย่างเพียงพอ และก็ไม่ได้เปิดเผยต้นทุนอย่างการคอมไพล์ที่ช้าของ Rust จึงอาจดูเหมือนเป็นการหาเหตุผลมารองรับภายหลัง
  • ยังมีทางเลือกอื่นในการใช้งาน Zig และ TigerStyle ของ TigerBeetle ก็แสดงให้เห็นกรณีตัวอย่างที่ใช้การจัดสรรหน่วยความจำแบบคงที่และการทดสอบแบบจำลองสถานการณ์เพื่อป้องกันปัญหา use-after-free
  • วิธีพอร์ตเป็นไฟล์ ๆ ด้วย unsafe Rust เป็นแนวทางที่สมเหตุสมผล ซึ่งลดความเสี่ยงและเปิดทางให้รีดีไซน์ในอนาคตได้ แต่การยอมรับการแปลงโค้ดด้วย AI ในระดับล้านบรรทัด ขณะเดียวกันกลับมองว่าโค้ดจัดการพอยน์เตอร์ไม่กี่บรรทัดที่มนุษย์อ่านได้เป็นปัญหา ก็เป็นท่าทีที่ไม่ค่อยสอดคล้องกัน
  • เพราะยังคงต้องมี agent harness, borrow checker ของ Rust, กฎด้านความอ่านง่าย และการตรวจทานโดยมนุษย์อยู่เสมอ การ นำ coding agent มาใช้ จึงไม่ใช่ทางเลือกเดียวกับการยกเลิกวิศวกรรมซอฟต์แวร์

จุดจบของวิศวกรรมซอฟต์แวร์ที่ Anthropic พยายามผลักดัน

  • Anthropic กำลังผลักดัน เรื่องเล่า อย่างแข็งขันว่า หลังจากงานเขียนโค้ดแล้ว วิศวกรรมซอฟต์แวร์และแม้แต่แรงงานมนุษย์ส่วนใหญ่ก็จะหายไป
  • บริษัทระดมทุนได้ 1.32 แสนล้านดอลลาร์ และกำลังเข้าใกล้ IPO ที่มีมูลค่ากิจการเกิน 1 ล้านล้านดอลลาร์ แต่ในสถานการณ์ที่ ยังไม่สามารถแสดงให้เห็นถึงความสามารถในการทำกำไร ก็อยู่ในจุดที่ต้องขายอิทธิพลต่ออนาคตในเชิงสมมุติ
  • เพราะผลประโยชน์เช่นนี้ Anthropic จึงควรถูกมองว่าเป็น ผู้เล่าเรื่องที่ไม่น่าเชื่อถือ (unreliable narrator) และสิ่งสำคัญไม่ใช่แค่ข้อความนั้นจริงหรือไม่ แต่รวมถึงผลกระทบที่มีต่อการตัดสินใจของผู้บริหาร ผู้นำโลก และผู้จัดการกองทุนบำนาญด้วย
  • เรื่องเล่า AI ส่งผลต่อการตัดสินใจด้านสถาปัตยกรรม ผลิตภัณฑ์ และการจัดวางกำลังคน และท่ามกลางความกลัวการเลย์ออฟ คำเตือนว่าจะถูกทิ้งไว้ข้างหลัง และ Doom Trolling ก็ทำให้การตัดสินอย่างเยือกเย็นยากขึ้น
  • เมื่อต้องประเมิน AI ในแวดวงซอฟต์แวร์ จึงจำเป็นต้องมี การพิจารณาอย่างสงสัยไว้ก่อน โดยคำนึงถึงผลประโยชน์และเป้าหมายด้านประชาสัมพันธ์ของ Anthropic

การเปลี่ยนผ่านของ Bun จาก Zig→Rust และคำชี้แจงที่มาช้า

  • Anthropic/Bun เพิ่งออก คำชี้แจง เกี่ยวกับการตัดสินใจย้าย Bun ที่เขียนด้วย Zig ไปเป็น Rust หลังจาก merge เข้าสู่ main branch ไปแล้วถึงสองเดือน
    • หากเป็นโครงการโครงสร้างพื้นฐานขนาดใหญ่ โดยทั่วไปมักจะอธิบายทิศทางล่วงหน้า
    • ระหว่างที่คำชี้แจงยังไม่ออกมา พาดหัวอย่าง Anthropic’s Bun Rust rewrite merged at speed of AI ก็ช่วยกระจายความ impression ว่า AI ทำการเขียนใหม่เสร็จอย่างรวดเร็ว
  • Andrew Kelley ผู้สร้าง Zig ได้เผยแพร่ บทโต้แย้ง และวิจารณ์ทั้งเทคโนโลยีและการบริหารองค์กรของ Bun ด้วยน้ำเสียงตรงไปตรงมาผิดปกติ
    • มีภาระด้านชื่อเสียงอยู่ เพราะอาจกลายเป็นแบบอย่างให้ผู้นำของภาษาเดิมโจมตีไปถึงข้อบกพร่องส่วนตัว เพียงเพราะอีกฝ่ายเปลี่ยนภาษา
    • บางคนเรียกสิ่งนี้ว่า “meltdown” แต่ก็อาจมองได้ว่าเป็นการชี้ประเด็นที่ควรถูกพูดถึงอย่างเปิดเผย

เกณฑ์ในการตัดสินคำวิจารณ์ที่ตรงเกินไป

  • คำพูดที่ถูกต้องตามพุทธศาสนา (right speech) มองว่า ทุกคำพูดควรผ่านเกณฑ์ห้าข้อดังต่อไปนี้
    • จริงหรือไม่
    • เป็นประโยชน์หรือไม่
    • ถูกกาลเทศะหรือไม่
    • มีเมตตาหรือไม่
    • มีจุดตั้งต้นจากความเมตตาหรือไม่
  • การตอบโต้ของ Andrew Kelley เข้าข่าย คำพูดที่จริงแต่ไม่อ่อนโยน และประเด็นถกเถียงคือ แม้จะออกนอกกรอบมารยาทตามปกติ ก็จำเป็นต้องชี้ปัญหาต่อสาธารณะหรือไม่

ความสัมพันธ์ระหว่าง Bun·Zig·นโยบายการมีส่วนร่วมของ AI

  • Bun คือรันไทม์ TypeScript ที่มักถูกเปรียบกับ NodeJS เวอร์ชันที่เร็วกว่า ส่วน Zig คือภาษาระบบที่มักถูกเปรียบกับ C ยุคใหม่
  • จนกระทั่งไม่นานมานี้ Bun ยังเขียนด้วย Zig และเป็นหนึ่งในโค้ดเบส Zig ที่ใหญ่ที่สุด
  • นโยบายการมีส่วนร่วมของ AI ในสองโปรเจกต์นี้ตรงข้ามกันอย่างสิ้นเชิง
  • หลัง Anthropic เข้าซื้อ Bun ผู้ก่อตั้ง Jarred Sumner ก็ทำการทดลอง agent ขนาดใหญ่เพื่อย้ายโค้ด Zig ไปเป็น unsafe Rust และผลลัพธ์ก็ถูก merge ภายในไม่กี่วันจนกลายเป็นเวอร์ชันทางการ
  • ในบรรดาผู้เกี่ยวข้อง ดูเหมือนไม่มีฝ่ายไหนที่เรียกร้องให้ Bun คง Zig ต่อไป และข้อถกเถียงจึงไปอยู่ที่เหตุผลของการย้ายและวิธีประชาสัมพันธ์มากกว่าตัวการย้ายเอง
  • การย้ายภาษาครั้งใหญ่ด้วย agent เป็นการทดลองทางเทคนิคที่น่าลองอีกครั้งได้ หากอยู่ในบริบทที่เหมาะสม

สามการตีความต่อการตัดสินใจเดียวกัน

  • สำหรับนักพัฒนาที่กำลังเลือกระหว่าง Zig กับ Rust เหตุการณ์ที่หนึ่งในผู้ใช้ Zig รายใหญ่ที่สุดกลับคำตัดสิน ย่อมเป็นข้อมูลสำคัญในการตัดสินใจ
  • การตีความของ Anthropic/Bun คือได้ลองวิธีที่สมเหตุสมผลทั้งหมดแล้ว แต่ปัญหาบั๊กหน่วยความจำใน Zig รับมือได้ยากเกินไป
  • ตาม การตีความของ Andrew Kelley โค้ดเบสของ Bun พังเพราะการตัดสินใจทางวิศวกรรมของ Bun เอง เช่น ปล่อยให้ AI agent รับภาระการเขียนและรีวิวโค้ดมากเกินไป
  • ความเป็นไปได้ที่ธรรมดากว่านั้นคือ มีหลายวิธีแก้ปัญหาหน่วยความจำจริงอยู่แล้ว แต่ฝ่ายบริหารตัดสินใจเลือกการเขียนใหม่ด้วย Rust ได้ง่ายกว่า
    • สามารถใช้โปรโมตความสามารถของโมเดล Fable รุ่นใหม่ได้
    • Anthropic เองก็ใช้ Rust อยู่แล้ว
    • โปรเจกต์ Zig คัดค้านการใช้ผลิตภัณฑ์ของ Anthropic อย่างเปิดเผย
  • การย้ายไป Rust อาจสมเหตุสมผลในเชิงธุรกิจ แต่การประชาสัมพันธ์กลับเน้นว่า AI ทรงพลังพอจะทำการเขียนใหม่ได้
    • ข้อเท็จจริงที่ว่า AI ไม่สามารถจับปัญหา use-after-free ได้ล่วงหน้า กลับขัดกับเรื่องเล่านี้
  • การพูดเกินจริงผ่านกระบอกเสียงของ Anthropic ทำให้คนต้องนำการตัดสินใจของ Jarred Sumner ไปเทียบตรงกับ Andrew Kelley และอาจส่งผลต่อ ชื่อเสียงของ Zig โดยไม่ได้ตั้งใจด้วย

เหตุใดความน่าเชื่อถือส่วนบุคคลจึงเข้ามาอยู่ในข้อถกเถียงทางเทคนิค

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

ภาวะ crunch ถาวรและสภาพแวดล้อมองค์กรของ Bun

  • ประกาศรับสมัครงานของ Bun ในปี 2022 เตือนว่า 9 เดือนแรกจะหนักมาก และถ้าให้ความสำคัญกับสมดุลชีวิตการทำงานในรูปแบบที่มีเวลานอกงานเยอะ ก็อาจไม่เหมาะ
  • ภาวะ crunch mode แบบถาวรเป็นผลเสียทั้งต่อสุขภาพและประสิทธิภาพการทำงาน ซึ่งได้รับการยืนยันซ้ำแล้วซ้ำอีกจากงานวิจัยเชิงประจักษ์ด้านงานความรู้
    • เอกสารอ้างอิงที่เกี่ยวข้องดูได้จากส่วน Human Factors ของ Empirical Software Engineering
  • ควรเลือกผู้จัดการที่คอยปกป้องให้สมาชิกทีมได้นอนตอนกลางคืน มากกว่าผู้จัดการที่อวดว่า ทำงานสัปดาห์ละ 90 ชั่วโมง
  • คำประเมินที่ Andrew Kelley บอกว่าได้ยินมาจากคนที่เกี่ยวข้องกับทีม Bun สรุปได้ว่า การสื่อสารไม่เพียงพอ ความคาดหวังไม่สมจริง ความเห็นอกเห็นใจต่ำ และประสบการณ์น้อย แต่ก็มี ข้อจำกัดว่าเป็นคำบอกเล่า
  • อย่างไรก็ตาม คำประเมินนี้ก็สอดคล้องกับสภาพการทำงานสุดโต่งที่เปิดเผยไว้ในประกาศรับสมัครงาน
  • แม้อยู่ในสภาพแวดล้อมการทำงานที่แย่ ก็ยังอาจสร้างเทคโนโลยีที่ยอดเยี่ยมได้ และตัว Bun เองก็เป็นเครื่องมือที่ใช้งานได้ดีและน่าสนใจ
  • คำวิจารณ์ที่ว่าโค้ดมีบั๊กมากและดูแลรักษายาก ไม่ได้เป็นแค่คำวิจารณ์จากภายนอกเท่านั้น แต่ยังเป็น สภาพที่ Bun เองยกขึ้นมาเป็นเหตุผลสนับสนุนการย้ายไป Rust ด้วย

คุณค่าเชิงปฏิบัติของแนวทางพอร์ต unsafe Rust

  • รายละเอียดทางเทคนิคของกระบวนการเปลี่ยนผ่านมีคุณค่าพอที่จะนำกลับไปใช้กับโครงการปรับปรุงระบบสมัยใหม่อื่น ๆ ได้
  • Bun ไม่ได้ออกแบบใหม่เป็น Rust ที่ปลอดภัยตั้งแต่ต้น แต่ทำการ พอร์ตในระดับไฟล์ ด้วย unsafe Rust
    • คงโครงสร้างเดิมไว้เพื่อลดความเสี่ยงในช่วงเปลี่ยนผ่านระยะแรก
    • จากนั้นจึงวางรากฐานสำหรับการปรับปรุงความปลอดภัยและการออกแบบใหม่ในภายหลัง
  • แม้ระบบอัตโนมัติที่ขับเคลื่อนด้วย AI อาจทำให้การย้อนกลับการเลือกภาษาเป็นเรื่องง่ายกว่าในอดีต แต่การเขียนใหม่แบบอัตโนมัติยังคงมี ข้อดีข้อเสียและช่องว่างด้านความหมาย อยู่
  • ยังสามารถผสมผสานเทคนิคการเขียนใหม่หลายแบบและเสริมด้วย Formal Methods ได้ด้วย
  • TRACTOR ของ DARPA เป็นโครงการวิจัยเพื่อย้ายโค้ด C ทั้งหมดไปเป็น Rust และรายงานประเมินผลที่เผยแพร่ก็กล่าวถึงสถานะปัจจุบันของเทคโนโลยีการแปลงอัตโนมัติ
  • ต่อให้เอเจนต์จะมอบทางเลือกให้โค้ดเก่ามากขึ้น การกำหนดเป้าหมายการปรับปรุงระบบก็ยังต้องอาศัยการตัดสินใจและการสื่อสารต่อไป
    • หนังสืออ้างอิงที่เกี่ยวข้องคือ Kill It With Fire ของ Marianne Bellotti

เอกสารการตัดสินใจทางเทคนิคที่ขาดหายไปหลายอย่าง

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

การเปรียบเทียบที่ไล่เรียงแต่ข้อดีของ Rust

  • ส่วน “Bun is better in Rust” กล่าวถึงแต่ประโยชน์ของการย้ายไป Rust และแทบไม่เสนอค่าใช้จ่ายที่ต้องแลก
  • โดยทั่วไป โค้ดเบส Rust ขนาดใหญ่ได้ความปลอดภัยมากขึ้น แต่ต้องจ่ายด้วย เวลาในการคอมไพล์ที่ช้าลง
  • ในอดีต Bun ให้ความสำคัญกับความเร็วในการคอมไพล์ จนถึงขั้น fork คอมไพเลอร์ Zig เพื่อพยายามปรับปรุงได้ 4 เท่า
  • หากการพอร์ตไป Rust ทำให้เวลาบิลด์ของผู้ร่วมพัฒนาเพิ่มขึ้น ก็ควรเปิดเผยเรื่องนี้ และอธิบายว่าทำไมความปลอดภัยจึงสำคัญกว่าต้นทุนนั้น เพื่อให้การตัดสินใจน่าเชื่อถือยิ่งขึ้น
  • การนำการปรับปรุงอื่น ๆ ที่เกิดขึ้นหลังการเปลี่ยนผ่านมาปะปนไว้ในรายการข้อดีของการเขียนใหม่เป็น Rust อาจทำให้ผลโดยตรงของการเปลี่ยนภาษาเกินจริงได้

ทางเลือกด้านสไตล์ไกด์ที่ไม่ได้รับการพิจารณา

  • ใน Bun บั๊กหน่วยความจำไม่ใช่สาเหตุเดียวของข้อบกพร่อง แต่เกิดขึ้นบ่อยถึงขั้นตามการรวบรวมส่วนตัวแล้วต้องมี commit แก้ไข 4 ครั้งต่อสัปดาห์
  • บั๊กหน่วยความจำแต่ละกรณีหมายความว่ากติกาเกี่ยวกับการสร้าง การเป็นเจ้าของ และการปล่อยอ็อบเจ็กต์ถูกทำลายลงที่ใดที่หนึ่ง ดังนั้นอาจเริ่มจากการพิจารณาวิธีทำให้พฤติกรรมที่คาดหวังในแต่ละสถานการณ์ชัดเจนขึ้น
  • การจัดการหน่วยความจำด้วยมือต้องพึ่งกติกาที่กว้างขึ้น แต่ไม่ว่าภาษาใดก็จำเป็นต้องมีแนวทางใช้งานที่มีประสิทธิภาพ และ Rust เองก็มี API style guide

  • ทางเลือกที่ TigerBeetle แสดงให้เห็น

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

  • ช่องว่างที่ยังเหลือในคำชี้แจงของ Bun

    • Bun กล่าวถึง TigerStyle และคู่มือสไตล์ C++ ของ Google ที่ยาว 31,000 คำ ก่อนสรุปว่าสไตล์ไกด์บังคับใช้ได้ยากและตามธรรมเนียมต้องพึ่ง code review, linter และ static analyzer
    • แต่ไม่ได้กล่าวว่าในทางปฏิบัติ Bun ใช้สไตล์ไกด์ใด ทำไมมันจึงล้มเหลว และตลอด 4 ปีได้ปรับปรุงอย่างไร
    • หากโครงการขนาดใหญ่ยังมีปัญหาหน่วยความจำต่อเนื่อง คำถามสำคัญคือได้ทดลองทางเลือกในการใช้ภาษาปัจจุบันให้ต่างออกไปอย่างจริงจังหรือไม่ แต่หลักฐานที่สนับสนุนเรื่องนี้ยังมีน้อย
    • รูปแบบการทำงานที่คนคนเดียวต้องเก็บบริบททั้งหมดไว้ในหัวและไม่มีการประชุม ทำให้ยากต่อการสร้างกติกาที่ชัดแจ้งและการออกแบบที่มีการแบ่งปันร่วมกัน

ความขัดแย้งระหว่าง agent review กับสไตล์ไกด์

  • Bun มองว่าสไตล์ไกด์บังคับใช้ได้ยาก แต่ในขณะเดียวกันก็ระบุว่าได้เขียน PORTING.md สำหรับการย้ายระบบ และให้เอเจนต์ตรวจทานโค้ดที่เขียนใหม่ทั้งหมดตามแนวทางที่เข้มงวด
  • ตัว PORTING.md เองเป็น สไตล์ไกด์ ที่เจาะจงกับขอบเขตของการเปลี่ยนผ่าน ดังนั้นหาก agent review ประสบความสำเร็จ ก็เท่ากับว่าได้แก้ปัญหาการบังคับใช้แนวทางไปแล้ว
  • ภายใต้เงื่อนไขที่เหมาะสม agent review อาจใช้งานได้จริง แต่ต้องตั้งอยู่บนกฎและวิธีตรวจทานที่ออกแบบมาอย่างเพียงพอ
  • ความพยายามทางความคิดแบบเดียวกันนี้ก็อาจทุ่มให้กับการออกแบบโค้ด Zig ใหม่และการเสริมความเข้มแข็งของกติกาได้ แต่ Bun เลือกการเขียนใหม่แทนการปรับสถาปัตยกรรมใหม่
  • ด้วยเหตุผลหลายอย่างที่ไม่ได้เปิดเผย การเขียนใหม่อาจเป็นตัวเลือกที่ถูกต้องก็ได้ แต่จากคำชี้แจงปัจจุบันยังเปรียบเทียบทางเลือกได้ไม่เพียงพอ

การเขียนใหม่หนึ่งล้านบรรทัดกับโค้ด pointer สามบรรทัด

  • Bun มองว่าหากต้องการให้ความคาดหวังเรื่อง ownership ปรากฏในระดับ type ใน Zig ก็ต้องเพิ่มโค้ดอย่าง SharedPtr(TCPSocket) และ deref() ซึ่งใช้งานไม่สะดวกเท่าการใช้ pointer แบบเดิม
  • ในตัวอย่างนี้ โค้ดเพิ่มขึ้นราว สามบรรทัด เพื่อทำให้การส่ง pointer ผ่านขอบเขตของอินเทอร์เฟซชัดเจนขึ้น
  • การยอมรับ PR ที่สร้างโดย AI ขนาดระดับล้านบรรทัดซึ่งตรวจทานได้ยาก แต่กลับปฏิเสธโค้ดไม่กี่บรรทัดที่ทำให้ ownership ของ pointer ชัดเจนขึ้นด้วยเหตุผลด้านความอ่านง่าย เป็นท่าทีที่ไม่ค่อยสอดคล้องกัน
  • Jarred Sumner เคยระบุไว้ว่าเป็นเวลาหลายเดือนแล้วที่ไม่มีการพิมพ์โค้ดโดยมนุษย์โดยตรง
  • หากโค้ดไม่ได้มีไว้เพื่อมนุษย์ เหตุผลที่ว่า wrapper อย่าง SharedPtr ดูไม่สบายตาก็จะอ่อนลง แต่หากโค้ดมีไว้เพื่อมนุษย์ ก็ยังต้องคำนึงถึงความอ่านง่าย ความสามารถในการตรวจทาน และการบำรุงรักษาต่อไป
  • บริษัท AI มักไม่อยากยอมรับว่าความอ่านง่ายของโค้ดยังคงสำคัญ แต่การปฏิเสธเรื่องนี้แม้จะสอดคล้องกับเรื่องเล่าว่าวิศวกรรมซอฟต์แวร์กำลังสิ้นสุดลง ก็ขัดกับความเป็นจริงของการบำรุงรักษา
  • ยังมี benchmark ที่ชี้ว่า coding agent อาจทำให้ความสามารถในการบำรุงรักษา แย่ลง โดยพื้นฐานได้

เหตุการณ์เดียวกันที่เผยให้เห็นว่า ‘มีแค่ AI อย่างเดียวยังไม่พอ’

  • การรีไรต์เอเจนต์ครั้งใหญ่ของ Bun ไม่ได้มีแค่การปรับปรุงทางเทคนิค แต่ยังทำหน้าที่ทางธุรกิจในการโปรโมตข้อความของ Anthropic ที่ว่า “AI อย่างเดียวก็พอ”
  • แต่กรณีเดียวกันนี้ก็สามารถตีความในทางตรงกันข้ามได้เช่นกัน
  • ภายใต้สมมติฐานที่ว่าปัญหาที่เอเจนต์สร้างขึ้นสามารถแก้ด้วยเอเจนต์ที่มากขึ้นได้ จึงเกิดการแพร่หลายของแนวทางที่ซื้อโทเคนแทนการสร้างเครื่องมือที่ดีกว่า และแนบ SKILL.md แทนการเรียนรู้ทักษะ
  • การเรียกเซสชันเอเจนต์แบบขนานว่า Team แทนที่จะทำความเข้าใจ จิตวิทยาของทีมซอฟต์แวร์ เป็นการสับสนระหว่างองค์กรของมนุษย์กับเซสชันการทำงานอัตโนมัติ

การนำโค้ดดิงเอเจนต์มาใช้กับการทิ้งวิศวกรรมเป็นคนละเรื่องกัน

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

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

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

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

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

    • โปรเจ็กต์ AI ถูกทิ้งเพราะมันถูกสร้างขึ้นแบบฉับพลัน ต้นทุนจม อาจกลับเป็นข้อดีที่ช่วยให้คนทนผ่านช่วงยากลำบากและช่วงซบเซาได้ แต่ผลงานที่เกิดจากไอเดียชั่ววูบกับ Claude prompt เพียงอย่างเดียวไม่ทำให้เกิดความผูกพัน
      แม้แต่ผมซึ่งเป็นโปรแกรมเมอร์ธรรมดา ๆ ก็มีไอเดียเจ๋ง ๆ หลายสิบอย่างทุกวัน แต่มีน้อยมากที่ทนการพิจารณาได้ และไม่กี่วันต่อมาก็ยังดูไม่คุ้มค่าจะลงแรง ไอเดียนั้นเดิมก็ราคาถูกอยู่แล้ว และตอนนี้แม้แต่การพิสูจน์แนวคิดก็ถูกลงไปอีก ดังนั้น Show HN ที่ยังลงทุนไม่ถึงเดือนจึงไม่น่าสนใจสำหรับผม
    • ถ้าจะไปถึง Rust ที่ปลอดภัย และผ่านการพิสูจน์ในงานจริงอย่างมาก ก็ต้องเริ่มจากที่ไหนสักแห่ง จึงเลือกแปลตรงก่อนแล้วค่อยปรับปรุงทีละขั้น
      ฝั่ง Zig ดูจะกังวลว่า Zig อาจเป็นภาษาที่หมดหวังตั้งแต่แรก เพราะมันไม่ได้มีข้อได้เปรียบเหนือ C มากพอจนถูกใช้ในงานจริงจัง และแม้แต่โปรเจ็กต์ตัวแทนก็ยังย้ายออกไป ลองค้นหา segfault ใน issue tracker ของ Zig ก็จะพอเข้าใจได้ว่าทำไมบางคนจึงสงสัยถึงประโยชน์ในอนาคตของมันเมื่อเทียบกับทางเลือกอย่าง Rust
    • ต่างจาก Zig ตอนนี้มี ขอบเขต unsafe ที่ชัดเจนและจำกัดขอบเขต แล้ว และสามารถแก้ไขมันทีละจุดได้ ซึ่งดีกว่า
    • บทนำของบทความนี้ประชดประชันเกินไป พอดูคนรู้จักใน Anthropic กับ OpenAI แล้ว คนเหล่านี้เชื่อจริง ๆ ว่าในอนาคตอันใกล้ เอเจนต์จะเข้ามารับงานเขียนโปรแกรมส่วนใหญ่ และตัวพวกเขาเองก็จะตกงาน
      ไม่ใช่ว่าพวกเขากำลังจัดการสารเพื่อจะมาสั่งสอนฝั่งต่อต้าน AI แต่อย่างใด
    • จะสรุปว่าโปรเจ็กต์ที่ AI สร้างถูกทิ้งเร็วเพราะขาดการพิสูจน์ในงานจริงก็ไม่ได้ โปรเจ็กต์ส่วนตัวทั่วไปส่วนใหญ่ก็ถูกทิ้งไปเมื่อเวลาผ่านไปอยู่ดี และการที่ตอนนี้เขียนโค้ดได้เร็วขึ้นมาก อาจแค่ทำให้ไปถึง จุดที่อรรถประโยชน์ส่วนเพิ่มลดลง ในแง่ประโยชน์ส่วนตัว การเรียนรู้ และความสนุก ได้เร็วขึ้นก็เท่านั้น

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

    • ที่น่าหนักใจกว่าคือเริ่มมีสัญญาณว่าท่าทีแบบนี้ กำลังกระจายไปในชุมชน Zig แม้ตอนนี้จะยังไม่ใช่คนส่วนใหญ่ แต่ถ้าคนที่เป็นมิตรทยอยย้ายไปหาชุมชนที่อบอุ่นกว่า สัดส่วนของคนลักษณะนี้ในกลุ่มที่เหลือก็จะยิ่งมากขึ้น
    • ผมอยากปกป้อง Andrew ว่าเขาให้ความสำคัญกับการทำสิ่งที่ถูกต้องอย่างจริงจังจนมีความเห็นที่แรง แต่ตัวจริงเป็นคนอดทนและเปิดกว้างกว่าที่ตัดสินจากระยะไกล
      บางคนอาจมองว่า Andrew โจมตี Bun ส่วนผมก็อาจมองว่าปฏิกิริยาที่มีต่อ Andrew เป็นการโจมตีตัวบุคคลเหมือนกัน ถ้าถอดอคติออก ทั้งสองฝ่ายอาจผิดทั้งคู่หรืออาจไม่มีใครผิดเลย และเวลาตัดสินสถานการณ์จากระยะไกล เราควรตระหนักว่า อคติส่วนบุคคล มีอิทธิพลมากเกินไปเพียงใด
    • ถ้าจะจากไป ก็ขอแค่อย่าเขียนบทความชวนเข้าใจผิดที่ทำให้ Zig ดูแย่ และอย่าไม่มาตามนัดประชุมกับ Zig Foundation โดยไม่แจ้งล่วงหน้า ก็น่าจะโอเค
    • บทความของ Andrew ถูกแก้หลายครั้ง ดังนั้นถ้าอ่าน ฉบับแก้ไขล่าสุด ความกังวลอาจลดลงได้: https://github.com/andrewrk/andrewkelley.me/commits/master/p...
    • Rust ไม่มี BDFL โดยการออกแบบ และ Python เองก็จำได้ว่าออกจากโมเดลนี้ไปแล้ว ผู้มีส่วนร่วมรายบุคคลอาจโกรธและเขียนข้อความเชิงรุกได้ แต่ไม่มีบุคคลคนเดียวที่เป็นตัวแทนของภาษาแบบกรณี Zig

  • ผมอยากอยู่ฝั่ง Andrew จากการติดตามงานของ Sumner มาหลายปี คำวิจารณ์ของ Kelley แม้จะไม่เป็นมิตร แต่ก็เป็นความจริงพอสมควร และต่อให้ผลงานสุดท้ายจะมีประโยชน์และน่าประทับใจเพียงใด มันก็ใกล้เคียงกับ การใช้อิทธิพลเพื่อโปรโมตตัวเอง มาตั้งแต่ต้นจนจบ
    ผมเองก็ทำ agentic development วันละ 8 ชั่วโมง และชวนทีมมาใช้ Rust กับ Deno แทน Node มาโดยตลอด แต่การเขียนใหม่นี้มีเหตุผลรองรับน้อยมาก และดูเป็นส่วนต่อเนื่องของแคมเปญประชาสัมพันธ์ยาว ๆ ที่ Dario กับพวกทำสำเร็จ ถ้าถ้อยคำสุภาพกว่านี้ก็คงถูกรับได้ดีกว่า แต่ผมก็ชื่นชมที่เขาเอาความคิดจริงออกมาแทนบทความที่ทีม PR เขียนให้

    • บทเรียนจากเรื่องวุ่นวายครั้งนี้คือ ก่อนโพสต์คำตอบที่รุนแรงควร พักไว้ 1–2 วันแล้วให้เพื่อนสนิทช่วยอ่าน บทสรุปที่ Andrew มาแก้ทีหลัง ควรเป็นสิ่งที่เขาปล่อยออกมาตั้งแต่ฉบับแก้ครั้งแรก
    • เหตุผลล่วงหน้าสำหรับการเขียนใหม่ค่อนข้างอ่อน แต่ผมก็เข้าใจว่าทำไม Jarred ถึงหงุดหงิดได้แม้ไม่ยกตัวอย่าง
      คำอธิบายว่า Bun มีความยากเฉพาะตัวจากการต้องทำงานร่วมกับ JavaScript garbage collector นั้นมีประโยชน์ แต่ Andrew ไม่แตะเรื่องนี้เลย ส่วนคำอธิบายว่าโค้ดใหม่ผ่านการตรวจด้วยชุดทดสอบเดิม ก็ช่วยแก้ความเข้าใจผิดของผมที่เคยคิดว่าแม้แต่เทสต์ก็คงถูกแปลด้วย vibe coding จนเชื่อถือไม่ได้ แน่นอนว่าเทสต์ไม่ได้จับบั๊กได้ทั้งหมด ซึ่งใช้ได้กับซอฟต์แวร์ทุกตัวรวมถึง Zig ด้วย
      สุดท้ายแล้ว เรื่องนี้ขยายวงเพราะการปะทะกันระหว่างมุมมองที่ว่า ภาษาที่ไม่ปลอดภัยด้านหน่วยความจำก่อให้เกิดต้นทุนความบกพร่องมหาศาล กับคำตอบแบบ “ก็พัฒนาฝีมือให้ไม่เขียนบั๊กสิ” แล้วถูกเติมเชื้อด้วยข้อถกเถียงเรื่อง AI การมีส่วนร่วมของ Anthropic และสไตล์การพูดแบบ Linus ของ Andrew
    • วิธีคิดที่ว่าต้อง อธิบายความชอบธรรมของการเขียนใหม่ ให้คนนอกบริษัทฟังนั้นแปลกในตัวเองอยู่แล้ว
    • ในประเด็นทางเทคนิค ผมชอบท่าทีแบบ Linus ที่ พูดตามที่เป็นจริง มากกว่าถ้อยคำ PR และถ้อยคำเชิงประชาสัมพันธ์ก็เอาไว้ใช้กับลูกค้าที่ไม่ใช่สายเทคนิคก็พอ

  • ฉันสงสัยว่าเราอ่านบทความของ Anthropic กับของ Andrew Kelley ในแบบเดียวกันหรือไม่ Anthropic ไม่ใช่บริษัทที่ขายภาษาโปรแกรม และบทความเรื่องการเขียน Bun ใหม่ด้วย Rust ก็มีรายละเอียดทางเทคนิคมากมายที่แสดงให้เห็นว่าผลิตภัณฑ์ดีขึ้นอย่างไรสำหรับผู้ใช้ปลายทาง
    ในทางกลับกัน ฝั่ง Zig ดูเหมือนจะตอบโต้ด้วย บทความเสียดสีเผ็ดร้อนที่เต็มไปด้วยการโจมตีตัวบุคคล มากกว่า ฉันใช้ Codex และไม่ได้มีส่วนได้ส่วนเสียกับทั้ง Zig หรือ Rust จึงมองจากคนนอก

    • Anthropic เองก็มี ผลประโยชน์ในตลาดภาษาโปรแกรม อย่างชัดเจน หาก AI ทำให้การเขียนใหม่ไปเป็นภาษาใดภาษาหนึ่งง่ายขึ้น เรื่องราวความสำเร็จก็จะเชื่อมภาษานั้นเข้ากับบริษัท AI และความสำเร็จของ Rust ในฐานะภาษาที่เขียนด้วย AI ได้ง่ายก็เป็นผลดีกับ Anthropic เช่นกัน
      อีกทั้งเวลาโปรโมตการเขียนใหม่ที่ประสบความสำเร็จ ก็มักมีการซ่อนองค์ประกอบที่ทำให้เรื่องเล่าไม่น่าดู เช่น โค้ดเดิมแย่แค่ไหน และครั้งนี้ก็มีหลายด้านสำคัญที่หายไป
      บทความของ Andrew Kelley(https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) กล่าวถึงมาตรฐานวิศวกรรมที่ต่ำของ Jarred, การขาดความรับผิดชอบด้านความสัมพันธ์ภายนอก เช่น ไม่มาเข้าร่วมประชุมกับมูลนิธิ Zig โดยไม่แจ้งล่วงหน้า, ความเสียหายที่เกิดจากการทำให้ Zig ดูเป็นตัวเลือกที่แย่ระหว่างการย้ายไป Rust และความโกรธของ ZSF ที่ตามมา
      หากมองผิวเผินก็เข้าใจได้ว่าทำไมคนจะกังวลว่าผู้สร้างภาษากำลังโจมตีผู้ใช้เก่า แต่ Kelley ได้อธิบายว่าทำไมความรู้สึกนั้น ซึ่งฉันเองก็มีหลังอ่านแต่บทความของ Bun จึงไม่ยุติธรรม แน่นอนว่ามีการโจมตีตัวบุคคลบางส่วนจริง และในย่อหน้าสุดท้ายที่เพิ่มภายหลังก็พูดถึงเรื่องนี้
    • ลองนึกภาพว่าสตูดิโอแห่งหนึ่งย้ายจาก Unity ไป Unreal แล้ว Unity ออกบทความโจมตีคุณภาพโค้ดเดิมกับสภาพแวดล้อมการทำงานของทีมนั้น จะเห็นว่า แค่การที่ Zig ออกมาตอบโต้ก็แปลกแล้ว
    • นี่คือความขัดแย้งเก่าแก่ระหว่างแนวคิดแบบช่างฝีมือกับแบบอุตสาหกรรม Andrew อยู่ในสายความคิดที่อยากให้นักพัฒนาทุกคนเป็นช่างฝีมือที่มีความภูมิใจในงาน
      Java, JavaScript, Python และ C# ครองอุตสาหกรรมที่เคยมี C++ เป็นศูนย์กลาง เพราะมี ราวป้องกันความปลอดภัย ที่ทำให้นักพัฒนาซึ่งไม่ได้สมบูรณ์แบบนักก็ยังทำงานได้โดยไม่เกิดหายนะใหญ่ C และ C++ แม้ได้เปรียบด้านประสิทธิภาพมาก แต่ก็ต้องอาศัยทักษะสูงขึ้นเรื่อย ๆ ในสภาพแวดล้อมที่เป็นปรปักษ์มากขึ้น
      Rust และ Swift ให้ความปลอดภัยที่ใกล้เคียงหรือแข็งแรงกว่าภาษาที่มี garbage collection พร้อมความสามารถในการคาดเดาประสิทธิภาพที่ดีกว่า และแนวคิดของ Rust ก็ทำให้ภาษาใหม่ ๆ ระเบิดจำนวนขึ้นมาในพื้นที่นี้ เพียงแต่หลายภาษาโน้มไปทางช่างฝีมือมากกว่า Rust ซึ่งเริ่มจากความต้องการของอุตสาหกรรม
      ถ้าเปรียบเป็นยานพาหนะ Java และ JavaScript เป็นต้น คือรถใช้งานทั่วไปที่ปลอดภัย, C/C++ คือมอเตอร์ไซค์สองล้อ, Rust คือรถแรลลีที่เร็วแต่ปกป้องผู้ขับได้ดี, ส่วน Zig ใกล้กับ ATV หรือโกคาร์ทแบบล้อเปิดมากกว่า มันอาจไม่ได้ลื่นไถลง่าย แต่ถ้าพลิกคว่ำก็อันตรายมาก
      คนสายช่างฝีมือที่ไม่สนข้อจำกัดด้านเวลาและต้นทุนมักคิดว่าแค่มีนักพัฒนาที่ระมัดระวังก็พอแล้ว แต่ในโลกอุตสาหกรรม แม้จะเขียนโค้ดดีได้ คนถึง 90% ก็ยังต้องทำงานภายใต้ข้อจำกัด จึงเชื่อใจได้ยากทั้งโค้ดตัวเองและโค้ดคนอื่น Zig มีข้อดีมากมาย แต่ตั้งแต่แรกก็เป็นภาษาสำหรับ คนที่ให้คุณค่ากับอิสระในการแฮ็กมากกว่าความปลอดภัย
    • ขนาดไบนารีและความเร็วที่ดีขึ้นไม่ได้เกี่ยวกับการเขียนใหม่ด้วย Rust โดยตรงมากนัก และน่าจะทำได้เหมือนกันหากลงแรงกับโค้ดเบส Zig ในระดับใกล้เคียงกัน มีด้านที่ดูเหมือนเพิ่มงานพิเศษเพื่อให้ตัวเลขเหล่านี้ออกมาสวยไว้ใช้โปรโมตการเขียนใหม่
      เรื่อง memory safety ก็อาจบรรลุได้ใกล้เคียงกัน หากใช้ integrated fuzzer ที่ทีม Zig แนะนำ แทนที่จะพึ่ง AI, การทดสอบ และ fuzzing ระดับสูงกว่า ถึงอย่างนั้น Rust ที่มีความเป็นผู้ใหญ่มากกว่าก็อาจเป็นตัวเลือกที่ดีสำหรับโปรเจกต์อย่าง Bun
      มุมมองของ Andrew จำเป็นต่อการเข้าใจว่าเกิดอะไรขึ้น แม้บางถ้อยคำจะนุ่มนวลกว่านี้ได้ แต่ถ้าการจัดการที่แย่เป็นสาเหตุโดยตรงของความสัมพันธ์ที่เลวลงและผลลัพธ์ทางวิศวกรรมที่ย่ำแย่ การพูดให้ชัดก็ไม่ใช่การโจมตีตัวบุคคล แต่เป็นบริบทที่จำเป็น
    • การมองว่าผลิตภัณฑ์ซึ่งช่วยเพิ่มผลิตภาพโปรแกรมเมอร์ด้วยการเขียนโค้ดแทน ไม่ได้เกี่ยวกับ ตลาดภาษาโปรแกรม เพียงเพราะไม่ได้ขายภาษาของตัวเอง เป็นมุมมองที่สั้นเกินไป
      โดยเฉพาะเมื่อผู้นำของ Zig เองก็แสดงท่าทีไม่ชอบ vibe coding อย่างเปิดเผยและวิจารณ์อุตสาหกรรม รวมถึงตัวโปรเจกต์ก็ปฏิเสธ pull request ที่สร้างด้วยผลิตภัณฑ์นั้น

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

    • หากดูจากข้อเท็จจริงที่ฝั่ง Bun นำเสนอ การเขียนใหม่นี้ มีความชอบธรรมทางเทคนิคไม่มากนัก และก็ไม่น่าแปลก เพราะการเขียนใหม่ทั้งหมดมักเป็นวิศวกรรมที่ไม่ดีในแทบทุกกรณี
      Bun ถูกเริ่มโดยคนที่มีประสบการณ์กับ Zig ไม่มาก ทั้งยังมีขอบเขตและความซับซ้อนมหาศาล และตั้งแต่แรกก็เป็นโปรเจกต์ที่เขียนใหม่จากโค้ดภาษาอื่นอยู่แล้ว หากนำตัวแปลง JavaScript·TypeScript ของ esbuild มาแปลจาก Go เป็น Zig แบบบรรทัดต่อบรรทัด แล้วไม่กี่ปีต่อมาก็ทิ้งทั้งโค้ดเบสเพื่อเขียนใหม่อีกครั้งในอีกภาษา ก็ไม่แน่ใจว่ายังมีอะไรให้พูดถึงมากนัก
    • ประเด็นของ Andrew คือ โค้ดของ Bun เดิมทีแย่อยู่แล้ว และดูเหมือนจะสื่อด้วยว่า Jarred เป็นบุคคลที่เป็นพิษจนไม่คุ้มจะเข้าไปถกเถียงด้วย
    • Bun ต้องการเคลื่อนที่เร็วและยอมพังได้ ส่วน Zig ทำให้ต้องเดินช้าและระมัดระวัง
      Bun ต้องการออกฟีเจอร์อย่าง shell language และไคลเอนต์ SQLite/PostgreSQL ให้เร็วที่สุด จึงไม่อยากมาคอยใส่ใจเรื่องการจัดการหน่วยความจำด้วยตัวเอง Zig บังคับให้ต้องจัดการ memory management และ lifetime เอง และตั้งใจไม่เพิ่มฟีเจอร์อย่าง Drop แต่ Rust เหมาะกว่าเพราะมี Drop
      เช่นเดียวกับที่ไม่มีใครสร้างฐานข้อมูล SQL ด้วย Python Zig ไม่ใช่เครื่องมือที่เหมาะกับ Bun และนี่ไม่ใช่เรื่องที่ควรแก้แบบตามตำราของ Zig เท่าไรนัก แต่เป็นความต่างในวิธีที่ Jarred ต้องการผลักดันโปรเจกต์ให้เดินหน้าเร็ว
    • บทความต้นฉบับแตะประเด็นนี้โดยตรง แต่แทบจะคัดเลือกเฉพาะด้านดีมาเล่า ตัวอย่างเช่นบอกว่าถึงขั้นเขียนคอมไพเลอร์ Zig ใหม่เพื่อปรับปรุง เวลา build แต่กลับไม่พูดเลยว่าทำไมเวลา build ของ Rust ซึ่งโดยทั่วไปช้ากว่ามากจึงไม่ถูกกล่าวถึงแม้แต่น้อย
    • คนที่ขายพลั่วในยุคตื่นทองจริง ๆ คือบริษัทที่ทำดาต้าเซ็นเตอร์และพลังงาน ส่วน ทองคำก็คือโทเค็น

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

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

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

  • อย่าประเมินต่ำเกินไปว่าอิทธิพลของการตลาดมีมากแค่ไหนต่อผู้บริหารและผู้บริหารระดับสูง โดยเฉพาะคนที่ขึ้นไปอยู่ในตำแหน่งอย่าง CEO ว่าจะถูกอารมณ์เล็กน้อยชักจูงได้ง่ายเพียงใด
    แค่การที่นี่เป็นโอกาสโปรโมตโมเดล Fable ใหม่ และ Zig ก็ประกาศคัดค้านการใช้ผลิตภัณฑ์ของ Anthropic อย่างเปิดเผย ก็อาจทำให้การเขียน Bun ใหม่ด้วย Rust ถูกตัดสินใจไปแล้วในทางปฏิบัติ

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

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

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

    • เป็นเรื่องยากที่ทั้งฝ่ายสนับสนุน AI แบบสุดโต่งกับฝ่ายคัดค้านแบบสุดโต่งจะประนีประนอมกันได้ เหตุผลเชิงเทคนิคและการโจมตีส่วนใหญ่เป็นเพียงการหาเหตุผลมารองรับภายหลัง โดยแต่ละองค์กรก็มีบริบทและเป้าหมายต่างกันไป
      Kelley เองก็น่าจะรู้เรื่องนี้ แต่ดูเหมือนจะต้านทานความยั่วยวนที่จะทำให้ประเด็นหลักพร่ามัวไม่ไหว บทความรุนแรง([0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...)นั้นเกินไปหน่อย แต่ภาคผนวกที่ชวนให้เดินหน้าต่อถือว่าดี และสำหรับ BDFL ฉันคิดว่าให้เผ็ดนิดหน่อยยังดีกว่าจืดชืดเกินไป