Electrobun 2.0 เตรียมแยกออกจาก Bun เนื่องจากมีการเขียนใหม่ด้วย Rust

 (twitter.com/YoavCodes)
1 คะแนน โดย GN⁺ 7 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Electrobun 2.0 จะเปลี่ยนทิศทางไปสู่การลดการพึ่งพา Bun เนื่องจาก การเขียน Bun ใหม่ด้วย Rust คล้ายกับการตัดสินใจที่ yt-dlp เคยทำไว้ และโครงสร้างการพึ่งพา runtime ก็จะเปลี่ยนไปด้วย
  • การตัดสินใจแยกออกนี้ได้รับอิทธิพลจากมุมมองที่ว่า Anthropic ไม่ได้ผ่านขั้นตอนการรีวิวโดยมนุษย์ การทยอยปล่อยใช้งานอย่างสมเหตุสมผล และกระบวนการทำให้เสถียรอย่างเพียงพอ
  • ตัว Rust เองได้รับการประเมินในเชิงบวก และมีกำหนดจะเป็นเป้าหมายการรองรับระดับชั้นหนึ่งใน Electrobun 2.0
  • นอกจาก Rust แล้ว Electrobun 2.0 ยังมีแผนจะรวม Zig และ Go เป็นภาษาที่รองรับระดับชั้นหนึ่งด้วย
  • สามารถดูโปรเจ็กต์ที่เกี่ยวข้องได้ในรีโพซิทอรี blackboardsh/electrobun โดยทิศทางหลักคือการลดการพึ่งพา Bun

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

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

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

  • เรื่องนี้น่าสนใจมากจริง ๆ และดูเหมือนเป็นมากกว่าแค่เรื่องให้ยืนดูเฉย ๆ แต่คล้ายเป็น สัญญาณชี้นำ ของ การพัฒนาซอฟต์แวร์ในปี 2026

    • อนึ่ง คำที่แม่นกว่าคือ bellwether ซึ่งมาจากแกะตอนที่ติดกระดิ่งไว้เพื่อใช้พาฝูง
    • ที่ตลกกว่านั้นคือ ไม่มีใครอยากทิ้ง npm ทั้งที่มันถูกใช้ในทางที่ผิดและถูกแฮ็กอยู่เรื่อย ๆ
      npm เป็นต้นตอของการแฮ็กทั้งวงการมากี่ครั้งแล้วกัน? แค่เหตุใหญ่ก็สามครั้งแล้ว แถมยังมีแคมเปญโจมตีซัพพลายเชนขนาดใหญ่ที่เล็ง npm โดยเฉพาะอีกด้วย แต่กลับทำเหมือนว่าเรื่องที่ควรกังวลจริง ๆ คือ bun
      ถึงเวลาเผชิญความจริงแล้วกลับไปทบทวน npm ใหม่อย่างจริงจังได้แล้ว มันกำลังหลุดการควบคุมอย่างน่ากังวล
    • เดี๋ยวเวลาจะบอกเอง ผมคิดว่านี่ก็แค่แพตเทิร์นเดิมที่เกิดซ้ำมา 20 ปีแล้ว คือคนบนอินเทอร์เน็ตโกรธ $latest_thing อยู่พักหนึ่ง แล้วก็ย้ายไปหัวข้อร้อนแรงถัดไป
    • อุปมาให้ตรงกว่าว่าเป็น นกคานารีในเหมืองถ่านหิน มากกว่าจะเป็นสัญญาณชี้นำ
    • แต่แรกเลยก็สงสัยว่าองค์กรที่ “ตามไม่ทันและไม่ทันสมัยมากนัก” จะมีสักกี่แห่งที่ใช้ Bun หรือ Deno
      อีกด้านหนึ่งมันก็ดูเหมือนโอเวอร์รีแอ็กชันเบา ๆ เหมือนกัน เราไม่ได้ไปตรวจสอบ kernel, driver, BIOS, EFI ทีละบรรทัดก่อนจะรัน Linux กันอยู่แล้วไม่ใช่หรือ? ถ้าเทสต์ผ่าน ประสิทธิภาพไม่ถอยหลัง และปลอดภัย ก็ไม่แน่ใจว่าทำไมถึงโกรธกันมากเพียงเพราะมันถูก vibe coding ขึ้นมา หรือเป็นเพราะมันดูไม่รับผิดชอบ? ผมมองเห็นเหตุผลของทั้งสองฝั่ง

  • ที่เก็บโค้ดของ Electrobun: https://github.com/blackboardsh/electrobun
    Electrobun ตั้งเป้าเป็นโซลูชันแบบครบวงจรสำหรับการ build, update และ deploy แอปเดสก์ท็อปที่รวดเร็วมาก ขนาดเล็ก และข้ามแพลตฟอร์ม ซึ่งเขียนด้วย TypeScript ภายในใช้ bun เพื่อรัน main process และ bundle เว็บวิว TypeScript พร้อมมี native binding ที่เขียนด้วย Objc, C++ และส่วนแกนหลักที่เขียนด้วย Zig

  • ดูเหมือนว่าควรหลีกเลี่ยง โค้ดเบสขนาดใหญ่ที่สร้างด้วย LLM จนกว่าจะพิสูจน์ได้ว่าสามารถบำรุงรักษาได้ด้วย LLM หรือด้วยความพยายามของมนุษย์ในระดับสมเหตุสมผล

    • น่าแปลกใจที่ผู้คนรีบสรุปทันทีว่า Bun เป็น “ขยะ AI”
      Bun ถูกพัฒนาเกือบทั้งหมดด้วย LLM มาราว 6 เดือนแล้ว ตั้งแต่ก่อนการเขียนใหม่ด้วย Rust เสียอีก แหล่งที่มา: https://x.com/jarredsumner/status/2054525268296118363
      ดังนั้นก็ถือว่าพิสูจน์แล้วว่า LLM สามารถบำรุงรักษาโค้ดเบสลักษณะนั้นได้
    • มีวิธีดูว่าโค้ดเบสกำลังเสื่อมลงภายใต้การ บำรุงรักษาโดย AI agent หรือไม่
      ก็เก็บและวิเคราะห์ว่า coding agent อ่านโค้ดอย่างไรระหว่างทำงานพัฒนา แล้วดูว่าปริมาณการเข้าถึงโค้ดและการใช้ token ในงานพัฒนาที่คล้ายกันเพิ่มขึ้นอย่างต่อเนื่องหรือไม่ ถ้าจากมุมมองของ agent แล้วความอ่านง่ายของโค้ดไม่ได้แย่ลง ความสามารถในการบำรุงรักษาของโค้ดเบสก็น่าจะยังโอเค

  • แม้จะมีความกังขาอย่างชัดเจนต่อซอฟต์แวร์ที่เขียนหรือเขียนใหม่ด้วย LLM ล้วน ๆ แต่ในแง่ของเวกเตอร์การโจมตีทางไซเบอร์ ก็คงต้องสมมุติว่า Anthropic น่าจะทดสอบมันมาดีพอกับ โมเดล Mythos ใหม่
    ไม่แน่ว่าพวกเขาอาจเคยพูดรายละเอียดเรื่องนี้ไว้มากกว่านี้

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

  • เพิ่งเคยได้ยินชื่อ Electrobun แต่ก็ดูเหมือนอาจเป็น ทางเลือกแทน Electron ที่ดีเหมือนกัน เห็นในเว็บพูดถึงการ bundle CEF เป็นออปชันด้วย เลยสงสัยว่ามีใครเคยใช้บ้างไหม

  • วันนี้เพิ่งรู้จัก Electrobun เหมือนกัน มันเป็นอย่างไรเมื่อเทียบกับ Electron?

    • ต่างกันตรง +bu

  • คิดว่าน่าจะเปลี่ยนชื่อจะดีกว่า

  • มาถึงจุดนี้แล้วก็ชวนสงสัยว่าจะมีใคร fork Bun ที่ใช้ Zig แล้วทำอย่างอื่นต่อไหม

  • เรื่องนี้ค่อนข้างสมเหตุสมผล
    ตัวอย่างเช่น หลายที่รวมถึงที่ของเราเองพึ่งพา numpy อย่างมาก numpy อยู่มาหลายสิบปีและผ่านการพิสูจน์ในงานจริงมามากพอแล้ว ถ้ามีใครเขียน numpy เวอร์ชันใหม่ขึ้นมาใหม่ทั้งหมดด้วย vibe coding ภายในหนึ่งสัปดาห์ แล้วรับประกันว่า “ผ่านทุกเทสต์” เราจะเอามาใช้ไหม? ไม่มีทาง เราคงไม่มีความมั่นใจว่าไม่มีบั๊กแฝง และไม่มีความมั่นใจว่าจะเชื่อผลลัพธ์ของมันได้อย่างเต็มที่
    ประเด็นสำคัญไม่ใช่ว่า AI เป็นคนเขียนใหม่หรือไม่ แต่คือมันผ่านการพิสูจน์ในการใช้งานจริงตามกาลเวลาหรือยัง ต่อให้ทีมมนุษย์เขียนใหม่ทั้งหมดภายในหนึ่งสัปดาห์ เราก็ไม่ไว้ใจและไม่ใช้เหมือนกัน

    • คำว่า “ทำเสร็จในหนึ่งสัปดาห์” ถูกพูดซ้ำบ่อยมากบน HN แต่ PR นั้นยังไม่ใช่ release การ เขียนใหม่ด้วย Rust ดำเนินมาเกินหนึ่งเดือนแล้ว และยังไม่ได้ปล่อย
    • มันคล้ายกับการพูดว่า “ตู้ใบนี้ฉันทำด้วยมือใช้เวลาหนึ่งเดือน แต่ถ้ามีคนทำด้วยเครื่องจักรเสร็จในวันเดียว ฉันจะเชื่อถือมันไหม?”

  • ชื่อนี้ค่อนข้างใกล้กับ Electron ที่ขึ้นชื่อในทางลบ มันเป็นอะไรคล้าย ๆ กันหรือเปล่า?