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

 (andrewkelley.me)
4 คะแนน โดย GN⁺ 8 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Andrew Kelley ผู้สร้าง Zig ตีความการเขียน Bun ใหม่ด้วย Rust ว่าเป็นเหตุการณ์ที่สะท้อนถึง ความสัมพันธ์ที่พังทลาย ระหว่าง Zig Software Foundation (ZSF) กับ Bun/Oven มากกว่าจะเป็นเรื่อง แพ้ชนะของฟีเจอร์ภาษา
  • ในช่วงแรก Bun ยอมรับว่า Zig เป็นรากฐานของผลงานด้านประสิทธิภาพ และบริจาคให้ ZSF ปีละ $60,000 แต่หลังจากกลายเป็นสตาร์ตอัปที่ได้รับเงินทุนจาก VC ความไม่พอใจเรื่องการบริหารองค์กรและคุณภาพโค้ดก็เพิ่มขึ้น
  • ZSF กังวลกับ การเขียนแบบแก้ขัด, การใช้ assertion มากเกินไป, และการที่เพิ่มฟีเจอร์ได้เร็วแต่จัดการบั๊กและหนี้เทคนิคได้ไม่ทันใน codebase ของ Bun อีกทั้งยังรู้สึกกดดันที่ Bun ดูเหมือนเป็นกรณีตัวแทนของ Zig
  • Kelley วิจารณ์ว่าบทความเรื่องการย้ายไป Rust ของ Bun วางกรอบการลดบั๊กเป็นเรื่อง style guide vs ฟีเจอร์ภาษา ทั้งที่แก่นจริงคือเวลาทางวิศวกรรมที่ใช้กำจัดบั๊กและการควบคุมคุณภาพโค้ด
  • ZSF ระบุว่ารู้สึกขอบคุณสำหรับเงินบริจาคจาก Bun แต่หลังการเข้าซื้อโดย Anthropic ทั้งเงินบริจาคและความสัมพันธ์ก็สิ้นสุดลง และมองในแง่บวกที่การเขียนใหม่ด้วย Rust ทำให้ผลประโยชน์ทางธุรกิจของ Zig กับ Bun แยกออกจากกัน

ความสัมพันธ์ช่วงแรกระหว่าง Bun กับ Zig

  • Jarred เข้าร่วมชุมชน Zig เมื่อราว 5 ปีก่อน และ Kelley มองว่าเขาเป็นคนที่มี “beginner energy” สูง คือชอบลองเร็วและเรียนรู้มาก
  • เมื่อ Bun เริ่มเป็นที่สนใจในฐานะ toolchain สำหรับ JavaScript ก็ทำให้ Zig ได้รับความสนใจมากขึ้นตามไปด้วย
  • Kelley มองว่า Jarred น่าจะสร้างรายได้ที่มั่นคงในซานฟรานซิสโกได้แม้ใช้เพียงการระดมทุนจากชุมชน แต่เขาเลือก venture capital เพราะรับแนวคิดแบบ Thiel Fellowship และแนวทางแบบ Silicon Valley
  • ช่วงแรก Bun มีท่าทีเป็นมิตรกับโครงการ Zig
    • เว็บไซต์ Bun ให้เครดิต Zig สำหรับผลงานด้านประสิทธิภาพ
    • ตั้งค่าบริจาครายเดือนรวมปีละ $60,000 ให้ Zig Software Foundation
    • Kelley ยังประเมินด้วยว่าคำขอบคุณต่อโครงการ Zig ในบทความเรื่องการเขียน Bun ใหม่ด้วย Rust ดูจริงใจ

รอยร้าวหลังกลายเป็นสตาร์ตอัปที่ได้รับเงินทุนจาก VC

  • หลัง Bun กลายเป็นสตาร์ตอัปที่ได้รับเงินทุนจาก VC นั้น Jarred ก็เปลี่ยนจากนักพัฒนาที่ร่วมเติบโตโอเพนซอร์สกับชุมชน ไปใกล้เคียงกับบทบาท ผู้ดำเนินธุรกิจ มากขึ้น
  • ข้อความรับสมัครงานของ Oven บอกเป็นนัยว่าประมาณ 9 เดือนแรกจะเป็นงานที่เข้มข้นมาก และระบุว่าหาก work-life balance สำหรับคุณหมายถึง “มีเวลาที่ไม่ได้ทำงานเยอะ” ที่นี่อาจไม่เหมาะ
  • Kelley บอกว่าเขาได้ยินความเห็นด้านลบซ้ำ ๆ เกี่ยวกับบทบาทผู้จัดการของ Jarred จากทั้งผู้สมัครงานและพนักงานของ Oven
    • ประเด็นที่ถูกพูดถึงคือ การสื่อสารไม่เพียงพอ, ความคาดหวังที่ไม่สมจริง, ความเห็นอกเห็นใจต่ำ, และประสบการณ์ไม่มากพอ
  • ผลก็คือสมาชิกในชุมชนที่อยากทำงานกับ Zig เริ่มหลีกเลี่ยง Oven และ Bun
  • ยิ่ง Jarred มุ่งเน้นที่ productivity และกลยุทธ์การ exit ของสตาร์ตอัปมากเท่าไร ก็ยิ่งห่างจากวิสัยทัศน์ระยะยาวของ Kelley สำหรับ Zig มากขึ้นเท่านั้น
    • ตัวอย่างเช่น Jarred เคยขอให้ให้ความสำคัญกับการทำ Language Server Protocol และการเชื่อมกับ VSCode ก่อน แต่ Kelley มีแผนที่ใหญ่กว่านั้น

ปัญหาคุณภาพโค้ดของ Bun ในมุมมองของ ZSF

  • Kelley มองว่าปัญหาหลักคือ คุณภาพโค้ด
  • ทีม Zig อ่านซอร์สโค้ดของโปรเจ็กต์ผู้ใช้ ตรวจดูว่าการเปลี่ยนแปลงของภาษาส่งผลต่อผู้ใช้อย่างไร และทดสอบการพังจากการเปลี่ยนแปลงกับ regression ด้านประสิทธิภาพ
  • ใน codebase ของ Bun มีแนวปฏิบัติการเขียนโปรแกรมที่ ZSF กังวลเพิ่มขึ้น
    • มีการสะสมของการเขียนแบบแก้ขัดอย่างต่อเนื่อง
    • มี การใช้ assertion มากเกินไป
    • เมื่อเทียบกับความเร็วในการเพิ่มฟีเจอร์แล้ว มีเวลาสำหรับการทบทวน, การกำจัดบั๊ก, และการลดหนี้เทคนิคน้อยเกินไป
  • Kelley กังวลว่าวิธีทำงานแบบนี้ของ Bun อาจถูกนำไปผูกกับคำวิจารณ์เรื่อง memory safety ของ Zig และอยากเว้นระยะห่างทางสังคมระหว่างโครงการ Zig กับ Bun
  • ZSF พยายามผลักดันให้ Bun ไปสู่แนวปฏิบัติการเขียนโปรแกรมที่ดีกว่าเดิม แต่ไม่สำเร็จ

การเข้าซื้อโดย Anthropic และการเขียนใหม่ด้วย Rust

  • ภายใน ZSF เริ่มมีมุมมองว่า Bun ใกล้เคียงกับ ภาระสุทธิ (net liability) มากกว่า
  • แม้ Bun จะดูเหมือนกรณีตัวแทนของ Zig แต่ในความเป็นจริงกลับใกล้เคียงกับตัวอย่างประเภท “ไม่ควรเขียนโค้ด Zig แบบนี้” มากกว่า และนั่นเป็นภาระสำหรับองค์กร
  • Kelley มองว่าแผนธุรกิจของ Bun ที่ “ขายอะไรสักอย่างบน cloud” นั้นหลวมมาตั้งแต่แรก และหากวันหนึ่งถูกขายออกไป Zig ก็อาจได้รับภาพลบทางอ้อมด้วย
  • หลังการเข้าซื้อโดย Anthropic ทาง ZSF รู้สึกโล่งใจ
    • เงินบริจาคหยุดลงอย่างเงียบ ๆ และ ZSF ก็คาดไว้อยู่แล้ว
    • ฝั่ง Bun ไม่ได้ยกเลิกประชุมรายเดือน แต่ก็ไม่ได้เข้าร่วม และถูกมองว่าความสัมพันธ์ได้สิ้นสุดลงแล้ว
  • ZSF สงสัยว่าการเขียนใหม่ด้วย Rust จะตามมาในไม่กี่วัน และก็เอาใจช่วยเรื่องนี้
  • หลังการเข้าซื้อโดย Anthropic เพียงแค่ความเชื่อมโยงทางอ้อมว่า Claude เขียนด้วย Bun และ Bun เขียนด้วย Zig ก็สร้างภาระให้ชุมชน Zig แล้ว
    • มี drive-by slop contributions เพิ่มขึ้น
    • มีผู้ใช้สายคลั่ง AI ที่คัดลอกผลลัพธ์จาก LLM มาแปะในโพสต์ฟอรัมไหลเข้ามา
    • Kelley กังวลว่า Zig อาจถูกจดจำว่าเป็นภาษาโปรแกรมที่เชื่อมโยงกับ AI
  • เมื่อ Jarred ประกาศการเขียนใหม่ด้วย Rust Kelley บอกว่าเขายินดีอย่างมาก และรู้สึกว่า “ไม่ใช่ปัญหาของฉันอีกต่อไป”

ข้อโต้แย้งต่อบทความเรื่องการเขียน Bun ใหม่ด้วย Rust

  • Kelley มองว่า บทความเรื่องการเขียน Bun ใหม่ด้วย Rust ของ Bun เขียนได้ดี แต่ก็ชี้ปัญหาสำคัญหลายข้อ

  • แก่นของการลดบั๊ก

    • บทความของ Bun วางกรอบเหมือนกับว่าหากอยากหลีกเลี่ยงบั๊ก ต้องเลือกระหว่าง style guide กับฟีเจอร์ของภาษาโปรแกรมอย่างใดอย่างหนึ่ง
    • สำหรับ Kelley วิธีหลักในการกำจัดบั๊กคือการลงทรัพยากรทางวิศวกรรมเพื่อค้นหาและกำจัดมัน
    • เขามองว่า TigerBeetle ใช้เวลาค้นหาและกำจัดบั๊ก พร้อมทั้งรักษาความสัมพันธ์ที่ดีกับ ZSF แต่ Bun ไม่ได้ทำทั้งสองอย่าง

  • ความขัดแย้งเรื่อง test suite

    • Kelley มองว่าบทความของ Bun อ้างว่าเหตุผลที่สามารถปล่อยโค้ด 1 ล้านบรรทัดที่ไม่ได้รับการรีวิวได้ เป็นเพราะมี test suite ที่เพียงพอ
    • หากเป็นเช่นนั้น เขาจึงย้อนถามว่าทำไมโค้ด Zig ถึงยังมีบั๊กน่ารำคาญมากมาย และเหตุใด test suite จึงจับบั๊กในโค้ด Zig ไม่ได้ แต่กลับจับบั๊กในโค้ดที่ไม่ได้รีวิว 1 ล้านบรรทัดได้

  • ประสิทธิภาพและ LTO

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

  • fuzzing

    • บทความของ Bun สื่อราวกับว่ามีการทำ fuzzing กับโค้ด Zig อย่างจริงจัง แต่ Kelley บอกว่าในระหว่างการโทร ทีม Bun กลับพูดว่าไม่ได้ทำ fuzzing กับอะไรเลย

  • ขนาดไบนารีและ comptime

    • บทความของ Bun ยกงานวิศวกรรมหลายอย่างที่ช่วยลดขนาดไบนารีมาเป็นเหตุผลสนับสนุนการเขียนใหม่ด้วย Rust แต่ Kelley มองว่างานเหล่านั้นไม่ได้เกี่ยวกับตัวการเขียนใหม่โดยตรง
    • มันใกล้เคียงกับงานวิศวกรรมที่ควรทำกับ codebase Zig ตั้งแต่แรกมากกว่า
    • ZSF เตือนมาหลายปีเกี่ยวกับการใช้ comptime มากเกินไปใน Bun และยังสร้าง ฟีเจอร์ time report เพื่อให้ตรวจสอบการใช้ comptime/inline และเวลาในการคอมไพล์ได้ด้วย

  • ความเร็วในการคอมไพล์

    • Kelley ชี้ว่าบทความของ Bun ไม่ได้พูดถึง ความเร็วในการคอมไพล์ เลย
    • โปรเจ็กต์คอมไพเลอร์ Zig มีขนาดประมาณ 600,000 บรรทัด ใกล้เคียงกับ Bun ก่อนเขียนใหม่
    • จากการวัดของ Kelley การ build จากศูนย์ด้วยแคชสะอาดใช้เวลา 16 วินาที และหลังเปิด incremental compilation แล้ว การแก้ไขแต่ละครั้งถัดไปใช้เวลา 90ms
    • เขาจึงตั้งคำถามว่าตัวเลขที่เทียบกันได้ของ Bun หลังเขียนใหม่ด้วย Rust คือเท่าไร

บทสรุปของ Kelley

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

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

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

 
click 8 시간 전

พออ่านบทความนี้แล้วก็รู้สึกว่าไม่อยากใช้ทั้ง zig และ bun เลยนะ
 
GN⁺ 8 시간 전
ความคิดเห็นจาก Hacker News

  • ผมได้เรียนรู้อะไรเยอะมากจากการอ่านโค้ดของ Andrew และอย่างที่ต้นฉบับก็บอกไว้ ถ้าไม่มี Zig ก็จะไม่มี Bun
    สำหรับประเด็นที่ว่า “ในบทความอ้างว่ามีการ fuzz โค้ด Zig แต่ในคอลทีม Bun ทั้งทีมบอกว่าไม่ได้ fuzz อะไรเลย เรื่องนี้ดูเหมือนเป็นการบิดเบือนอย่างโจ่งแจ้ง” นั้น มี PR สำหรับการรวม Fuzzilli อยู่: https://github.com/oven-sh/bun/pull/24826
    และยังมี PR ที่ merge แล้วเพื่อแก้ปัญหาที่ Fuzzilli พบในโค้ด Zig ของ Bun ด้วย: https://github.com/oven-sh/bun/pull/28926, https://github.com/oven-sh/bun/pull/28934, https://github.com/oven-sh/bun/pull/29255, https://github.com/oven-sh/bun/pull/29210, https://github.com/oven-sh/bun/pull/29199
    ถ้าค้นหา “Fuzzilli” ก็จะเจอ PR เพิ่มอีก: https://github.com/search?q=repo%3Aoven-sh%2Fbun+is%3Apr+Fuz...

    • สิ่งที่ Andrew พูดน่าจะหมายถึง zig build test --fuzz หรือก็คือ fuzzer ที่มากับ Zig เอง และนั่นน่าจะเป็นเครื่องมือในขอบเขตที่เขารับผิดชอบ
    • ยังไม่ค่อยเข้าใจนัก คำว่า “มีการ fuzz โค้ด Zig” เกี่ยวอะไรกับการเพิ่ม การรวม Fuzzilli เข้าไปใน Bun?
    • ผมไม่ได้เข้าข้างฝ่ายไหนเป็นพิเศษในข้อถกเถียงนี้ แต่การหยิบแค่รายละเอียดเฉพาะจุดหนึ่งจากบทความของ Andrew มาพูด แล้วไม่แตะเรื่องที่เหลือเลย มันก็ดูไม่ค่อยมีประโยชน์
      ผมไม่ได้บูชาใครทั้งนั้น แค่สงสัยเพราะบทสนทนาทั้งหมดดูเหมือนกำลังแย่ลงแทนที่จะไปในทางที่ดีขึ้น
    • ลิงก์พวกนี้แสดงให้เห็นว่ามีการใช้ fuzzer แต่ไม่ได้ตอบอีกครึ่งหนึ่งของคำพูด Andrew เขาถ่ายทอดหรือจำเนื้อหาในการคอล ผิดไปหรือเปล่า?
      การที่โดนโหวตลบเพียงเพราะถามเพื่อเช็กข้อเท็จจริงก็ดูมีนัยพอสมควร อาจมีคำตอบง่าย ๆ อย่าง “จนไม่นานมานี้ยังไม่ได้ใช้ fuzzer ดังนั้นทั้งคู่จึงพูดถูก” ก็ได้ แต่ผมไม่รู้ เลยถามเฉย ๆ

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

    • ผมไม่เข้าใจว่าการพูด ความเห็นส่วนตัวอย่างตรงไปตรงมา ในบล็อกส่วนตัวเกี่ยวกับเรื่องที่ตัวเองให้ความสำคัญ ทำไมถึงถือว่าไม่เป็นมืออาชีพ
      ทุกคนต้องกลายเป็นแบรนด์ที่เดินได้ คอยกรองคำพูดตลอดเวลา เดินบนเปลือกไข่ และหลบอยู่หลังภาษาบริษัทเพื่อให้ดู “เป็นมืออาชีพ” งั้นหรือ?
      โลกตอนนี้ไม่ได้ต้องการบทสนทนาที่จริงใจน้อยลง แต่ต้องการมากขึ้น และปฏิสัมพันธ์ออนไลน์ก็ดูจะยิ่งขาดความจริงใจขึ้นเรื่อย ๆ
    • ใช่ นั่นแหละคือเหตุผลที่ Anthropic กับ Bun ถอยออกจาก Zig
      Zig แทบจะเป็น โปรเจ็กต์ของคนคนเดียว และคนคนนั้นก็ดูจะตัดสินใจแบบไม่มั่นคงมากขึ้นเรื่อย ๆ
      แน่นอนว่าเป็นโปรเจ็กต์ของเขา เขาจึงมีสิทธิ์ แต่ถ้าคุณเป็นบริษัทที่มีมูลค่าเกือบระดับล้านล้าน ก็คงไม่อยากรับ ความเสี่ยงในซัพพลายเชน แบบนี้
      สำหรับ Anthropic การตัดไฟแต่ต้นลมย่อมดีกว่าลงทุนกับ ecosystem ของ Zig ต่อไป หลังจากเห็นความเสี่ยงที่ not-so-BDFL จะทำอะไรเกินเลย
    • Antirez เคยเขียนในทำนองว่า “ไม่ใช้ AI เพื่อเพิ่ม test coverage นี่ออกจะโง่”
      ในทางกลับกัน ถ้าดูจากขนาดการนำไปใช้และระยะเวลาพัฒนาแล้ว test coverage ของ Zig ต่ำจนน่าอาย
      ท่าทีของ Zig ต่อ AI นั้นเด็กมาก ทั้งที่มีโอกาสได้ประโยชน์มาก แต่กลับไม่ยอมพิจารณาความเป็นไปได้ในการใช้งานเลย
      การพยายามกัน PR spam ออกไป กับการมัดมือตัวเองและไม่ใช้ AI เลยแม้แต่ในงานภายในที่ง่ายและคุ้มค่าที่สุด เป็นคนละเรื่องกัน
      คุณยังใช้ AI คัดกรองบั๊กที่น่าจะเป็นของจริงจาก PR spam ได้ด้วย แต่เพราะไม่ยอมใช้ตัวช่วยอะไรเลย บั๊กจริงจึงถูกปล่อยทิ้งไว้นานเกินความจำเป็น
    • บทความนี้ดูเหมือนจะยินดีด้วยซ้ำกับการย้ายไป Rust ประเด็นนี้ถูกย้ำหลายครั้งในบทความ และยังให้ความรู้สึกเหมือนรอคอยและหวังให้ Bun ทิ้ง Zig มานานแล้ว
    • เห็นด้วย บทความนี้ควรโฟกัสที่ ข้อเท็จจริงอย่างเยือกเย็น มากกว่าการเรียงข้อวิจารณ์ส่วนตัวที่คงเอาไปเขียนเป็นเอกสารในที่ทำงานไม่ได้
      น่าเสียดายที่มีนักพัฒนาโอเพนซอร์สจำนวนมากที่สบายใจกับการเขียนแบบนี้เกินไป และนี่ก็เป็นหนึ่งในเหตุผลที่ผมเลิกมีส่วนร่วมกับโอเพนซอร์ส
      ถ้าเป็นที่ทำงานที่มีเหตุผล การทำตัวแบบนี้ก็คงถูกไล่ออก อย่างน้อยก็ต้องโดนลงโทษทางวินัย

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

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

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

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

    • ยังไม่เห็นชัดทันทีว่าความจริงจังของโปรเจกต์เกี่ยวข้องกับถ้อยคำที่ผู้เขียนเลือกใช้ในบล็อกส่วนตัวมากแค่ไหน
      มันคล้ายกับการบอกว่า Linux คงเป็นโปรเจกต์จริงจังไม่ได้เพราะสไตล์อีเมลของ Linus
    • เข้าใจได้ถ้าจะโกรธ ดูเหมือนคุณกำลังมองว่าการมีอารมณ์และแสดงสัญญาณของอารมณ์นั้นเป็นปัญหาในตัวมันเอง
      แถมเขาก็ไม่ได้เขียนในที่ทางทางการด้วยซ้ำ แต่เขียนในบล็อกส่วนตัว
    • ฉันไม่เข้าใจว่าบทความนี้ทำให้เชื่อได้อย่างไรว่่า Andrew Kelley ขาดความเป็นมืออาชีพเกินกว่าจะดูแลโปรเจกต์จริงจังอย่าง Zig
      สิ่งสำคัญคือสิ่งที่เขาสร้างคุณูปการให้ภาษานั้นไม่ใช่หรือ?
    • จุดนี้เกือบจะเป็นข้อโต้แย้งหลัก แต่ก็เฉียดไปนิดเดียว มันคือการปะทะกันระหว่าง วัฒนธรรมแฮ็กเกอร์ แบบดั้งเดิมกับแนวคิด growth hacking แบบ VC
      ทำไมการยอมรับใช้งานและมวลวิกฤตถึงต้องสำคัญเสมอ? ทำไมถึงจะสร้างภาษาที่สอดคล้องกับความบริสุทธิ์และอุดมการณ์ที่ตัวเองต้องการไม่ได้ แม้ต้องแลกกับการยอมรับใช้งานที่กว้างขึ้น?
      ทำไมทุกอย่างต้องถูกปรับให้เหมาะกับการเติบโตของผู้ใช้และการรับรู้ในวงกว้าง?
    • ในกรณีนี้ Bun ถูก Anthropic ซื้อกิจการ การออกจาก Zig จึงไม่ได้แปลว่ามาจากข้อได้เปรียบทางเทคนิคเสมอไป
      ต่อให้พวกเขาจะแกล้งทำเหมือนว่าใช่ก็ตาม

  • บทความนี้สดใหม่มาก น่าจะมีแรงยั่วยวนสูงมากที่จะตอบโต้ ถ้อยคำแบบ PR ในบทความของ Bun ด้วยภาษาที่ขัดเกลากว่า แต่เขาไม่ได้ทำแบบนั้น
    เขาสามารถใส่ข้อเท็จจริงที่ทำให้ Jarred ดูแย่พร้อมซ่อนความเห็นตัวเองไว้อย่างระมัดระวังได้ เช่น “ได้ยินว่าคนเรียกเขาว่าผู้จัดการห่วยแตกนะ ไม่ใช่ว่าฉันเรียกเอง คนอื่นต่างหากที่พูด” แต่กลับเลือกจะพูดตรง ๆ ซึ่งฉันชอบ

    • การที่ผู้เขียนไม่พยายามซ่อนนิสัยและความคิดของตัวเองนั้นสดใหม่ดี
      เพียงแต่เนื้อหาของนิสัยและความคิดนั้นค่อนข้างรับได้ยาก
    • มันดูเหมือน การโจมตีตัวบุคคล ยาว ๆ มากกว่า
    • เห็นด้วย บล็อกโพสต์นี้ให้ความรู้สึกเหมือนหาจุดสมดุลระหว่างภาษาสไตล์ PR กับ x.com

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

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

  • การโจมตี Jarred ในเชิงส่วนตัวดูเหมือนจะไม่ได้ช่วยอะไรนักต่อข้อโต้แย้งที่ว่าควรใช้ Zig
    น่าจะโฟกัสที่ตัวภาษา มากกว่าจะใช้คำอย่าง “ผู้จัดการห่วย ๆ”
    พูดตามตรง พออ่านโพสต์นี้แล้วก็ทำให้อยากหลีกเลี่ยงทั้ง Andrew พอ ๆ กับ Jarred

    • นี่ไม่ใช่การโจมตี Jarred ในฐานะตัวบุคคล แต่เป็นการวิจารณ์ พฤติกรรมที่ไม่เป็นมืออาชีพ ของเขาในที่สาธารณะ
      และก็เป็นสิ่งที่คนจำนวนมากในชุมชนได้เห็นมากับตาในช่วงหลายเดือนที่ผ่านมา
      การพูดว่า “Jarred ทำให้คนจำนวนมากในชุมชนของเราถอยห่างออกไปจากบทบาททางอาชีพของเขา และเราอยากรักษาระยะห่าง” ไม่ได้แปลว่า “Jarred เป็นคนแย่ในชีวิตส่วนตัว”
      แน่นอนว่าในวงการนี้ ถ้าคิดถึงว่าเหล่า VC เหลือพื้นที่ชีวิตส่วนตัวนอกงานกันมากแค่ไหน มันอาจถูกตีความว่าแทบจะหมายถึงอย่างเดียวกันได้ แต่ก็ไม่ใช่ปัญหาของ Andrew
      ไม่ได้จะปกป้องสไตล์การเขียนของ Andrew นะ เวลาเขาพูดกับผู้อ่านที่มีความหลากหลายทางระบบประสาทในวงกว้างกว่านี้ เขาอาจจะปกปิดความเป็น neurodiversity ของตัวเองได้มากกว่านี้
      ถึงอย่างนั้นนี่ก็เป็นโปรเจกต์ของเขา และชุมชนของเขาก็รู้ลักษณะนี้กันอยู่แล้ว นี่ก็เป็นตัวแปรที่รับรู้กันดี
      แทนที่จะใส่นัยรองว่า “Andrew กำลังพยายามลอบสังหารบุคลิกของ Jarred” ลองกลับไปอ่านใหม่โดยตั้งต้นว่า Andrew พูดจากใจจริงทั้งหมดก็น่าจะช่วยได้
    • พฤติกรรมทางสังคมออนไลน์ของ Andrew โดยรวมดูเหมือนเป็นความ ใจแคบ ต่อเนื่องกันมา
      นี่ไม่ใช่ครั้งแรกที่ฉันเห็นเขาเขียนอะไรที่ให้ความรู้สึกมุ่งร้ายอย่างเปิดเผย มันไม่ใช่ระดับที่พอจะเรียกอย่างอ้อม ๆ ว่า “พูดตรง” ได้
      “การเงียบไว้ไม่ใช่ทางเลือกเหรอ?”

  • ถึงจะบอกว่า “ไม่มีการวิจารณ์ Jarred ในเชิงส่วนตัว” แต่ทั้งบทความก็ให้ความรู้สึกเหมือนเป็น การวิจารณ์ Jarred ในเชิงส่วนตัว

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

  • งานทั้งหมดในการเขียน Bun ใหม่จาก Zig เป็น Rust นี้ดูเหมือนเป็น หมากการตลาด ครั้งใหญ่
    ถ้า Anthropic AI ทรงพลังขนาดนั้นจริง ทำไมไม่ให้มันรับงานที่ทะเยอทะยานกว่านี้ เช่น แก้บั๊กและออกแบบ codebase Zig เดิมของ Bun ใหม่ เพื่อไม่ใช่แค่แก้บั๊กปัจจุบัน แต่ยังป้องกันไม่ให้บั๊กลักษณะคล้ายกันเกิดขึ้นอีกในอนาคต?

    • เหตุผลเดียวของการเขียนใหม่คือผู้สร้าง Zig ประกาศว่าจะ ไม่รับ contribution จาก AI
      นั่นไปทำร้ายความรู้สึกของ Anthropic
    • ฉันสงสัยว่าความเคลื่อนไหวประหลาดนี้มาจากฝั่ง Anthropic หรือมาจากผู้ก่อตั้งที่หัวร้อนเกินเหตุซึ่งพยายามขายเรื่องนี้เพิ่มแม้หลังจากดีลเกิดขึ้นแล้ว
      พอจะจินตนาการได้ว่า Anthropic อาจอยากซื้อ Bun อยู่แล้วโดยไม่ต้องมีลูกเล่นแบบนี้ก็ได้
    • ก่อนจะเขียนใหม่เป็น Rust นั้น Bun เคยดูแล fork ที่เร่งความเร็วการคอมไพล์ และได้แจ้งกับคนที่ถามว่าฟอร์กนี้ไม่มีทาง merge เข้าไปได้เลยเพราะ นโยบายแบน LLM ของ Zig
      ไม่กี่สัปดาห์ต่อมา Bun ก็เริ่มการเขียนใหม่ด้วย Rust แม้จะไม่ได้พูดชัด ๆ แต่ฉันคิดว่าสองเหตุการณ์นี้อาจเกี่ยวข้องกัน
    • Rust ก็คือเครื่องมือที่มอบการตรวจสอบจำนวนมากแบบนั้น รวมถึงเครื่องมืออย่าง RAII ให้ฟรีทั้งกับมนุษย์และ LLM
    • สุดท้ายก็มีแค่สองทาง: Claude แก้บั๊กพวกนั้นไม่ได้ หรือแก้ได้แต่ทีม Bun เลือกจะไม่แก้เองโดยตั้งใจ
      ฉันไม่แน่ใจว่าแบบไหนแย่กว่ากัน