Ladybird เลือกใช้ Rust และเร่งการเปลี่ยนผ่านด้วยความช่วยเหลือจาก AI

 (ladybird.org)
5 คะแนน โดย GN⁺ 2026-02-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โปรเจกต์เบราว์เซอร์ Ladybird เลือกใช้ Rust เป็นภาษาแบบ memory-safe เพื่อมาแทนที่ C++ และ ใช้เครื่องมือ AI ในกระบวนการเปลี่ยนผ่าน
  • เดิมเคยพิจารณา Swift แต่พบข้อจำกัดด้าน การทำงานร่วมกับ C++ และข้อจำกัดของแพลตฟอร์ม จึงเปลี่ยนทิศทางมาใช้ Rust
  • เป้าหมายการพอร์ตแรกคือ JavaScript engine LibJS โดยใช้ Claude Code และ Codex เพื่อทำการแปลแบบมีมนุษย์คอยกำกับผ่านพรอมป์ต์หลายร้อยรายการ
  • ใช้เวลาเพียงราว 2 สัปดาห์ในการเขียนโค้ด Rust 25,000 บรรทัด และยืนยันได้ว่า ทั้งผลลัพธ์และประสิทธิภาพเหมือนกับเวอร์ชัน C++ ทุกประการ
  • ในระยะนี้โปรเจกต์จะยังคง พัฒนา C++ และ Rust ควบคู่กัน และมีแผนเสริมความปลอดภัยและความสามารถในการบำรุงรักษาในระยะยาว

เหตุผลเบื้องหลังการเลือกใช้ Rust

  • Ladybird ได้พิจารณาหลายภาษาเพื่อหา ภาษาแบบ memory-safe ที่จะมาแทน C++
    • Swift ถูกตัดออกเพราะขาดความสามารถในการทำงานร่วมกับ C++ และมีข้อจำกัดด้านการรองรับแพลตฟอร์มนอก ecosystem ของ Apple
  • Rust ถูกประเมินว่า มี ecosystem สำหรับ system programming ที่เติบโตเต็มที่ และ ผู้มีส่วนร่วมจำนวนมากก็มีความคุ้นเคยกับภาษาอยู่แล้ว
  • ในปี 2024 เคยชะลอการนำ Rust มาใช้เพราะ ไม่เหมาะกับ OOP แบบ C++ แต่ภายหลังตัดสินใจนำกลับมาใช้อีกครั้งด้วยเหตุผลด้าน ความปลอดภัยและความพร้อมของ ecosystem
  • ทีมอ้างอิงกรณีที่ Firefox และ Chromium นำ Rust มาใช้แล้ว และมองว่า เหมาะกับ Ladybird เช่นกัน

กระบวนการพอร์ต LibJS

  • เป้าหมายแรกของการเปลี่ยนผ่านคือ LibJS JavaScript engine ของ Ladybird
    • ด้วยองค์ประกอบที่แยกอิสระอย่าง lexer, parser, AST, bytecode generator และมี test262-based test coverage จึงเหมาะจะเป็นจุดเริ่มต้น
  • การพอร์ตใช้ Claude Code และ OpenAI Codex
    • ไม่ใช่การสร้างอัตโนมัติ แต่เป็น การแปลที่มีมนุษย์เป็นผู้กำกับ โดยตัดสินใจเองทั้งลำดับการพอร์ตและโครงสร้างโค้ด
    • มีการสั่งงานอย่างละเอียดผ่านพรอมป์ต์หลายร้อยรายการ และหลังจากนั้นยัง ใช้โมเดลหลายแบบเพื่อตรวจสอบโค้ดและค้นหาข้อผิดพลาด

ผลลัพธ์และการตรวจสอบ

  • เป้าหมายคือให้ ผลลัพธ์จาก pipeline ของ C++ และ Rust เหมือนกันทุกไบต์
  • สร้าง โค้ด Rust ราว 25,000 บรรทัด เสร็จภายใน 2 สัปดาห์ ช่วยย่นงานที่เดิมอาจต้องใช้เวลาหลายเดือน
  • AST และ bytecode ตรงกันอย่างสมบูรณ์ และ ไม่พบประสิทธิภาพลดลงในการทดสอบและ JS benchmark
  • ทีมใช้ การทดสอบ lockstep ที่รัน pipeline ของ C++ และ Rust พร้อมกัน เพื่อตรวจสอบว่าผลลัพธ์ตรงกันระหว่างการท่องเว็บหรือไม่
  • ปัจจุบันโค้ดยังคง รักษารูปแบบที่แปลมาจาก C++ และ เลียนแบบแม้กระทั่งรูปแบบการจัดสรรรีจิสเตอร์
    • เพราะลำดับความสำคัญสูงสุดคือ การคงความเข้ากันได้กับ pipeline ของ C++
    • ในอนาคตเมื่อถึงเวลายกเลิก pipeline ฝั่ง C++ ก็จะมีการ ทำให้โค้ด Rust เรียบง่ายขึ้นและจัดระเบียบใหม่

แผนในอนาคต

  • การเปลี่ยนผ่านไปสู่ Rust จะดำเนินไปในฐานะ งานคู่ขนาน ไม่ใช่ทิศทางการพัฒนาหลักของโปรเจกต์
  • โค้ด C++ และ Rust จะอยู่ร่วมกัน โดยรักษาขอบเขตการทำงานร่วมกันให้ชัดเจน
  • ลำดับและขอบเขตของการพอร์ตจะถูก ทีมหลักเป็นผู้ดูแล และผู้ร่วมพัฒนาภายนอกจำเป็นต้องประสานงานล่วงหน้า
  • ในระยะยาวจะผลักดันการเปลี่ยนผ่านแบบค่อยเป็นค่อยไป โดยมีเป้าหมายเพื่อ เพิ่มความปลอดภัยและความสะดวกในการบำรุงรักษา
  • แม้จะยอมรับว่าการตัดสินใจนี้อาจก่อให้เกิดข้อถกเถียง แต่ทีมก็ประเมินว่า เป็นทางเลือกที่ถูกต้องสำหรับอนาคตของ Ladybird

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

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

 
GN⁺ 2026-02-24
ความคิดเห็นจาก Hacker News

  • จุดที่ฉลาดที่สุดของโปรเจ็กต์นี้คือการกำหนดให้ผลลัพธ์ต้อง เหมือนกันทุกไบต์
    ทำให้สามารถรัน pipeline เดิมกับ pipeline ใหม่ไปพร้อมกันแล้วเทียบ diff ได้ และจับบั๊กที่เกิดขึ้นระหว่างการแปลย้ายได้ทันที
    สาเหตุที่การรีไรต์จำนวนมากล้มเหลวก็เพราะผู้คนพยายาม “ปรับปรุง” ระหว่างการพอร์ต จนสุดท้ายต้องไล่ตาม บั๊กผี ที่เกิดจากความต่างระหว่างเวอร์ชันเก่า เวอร์ชันใหม่ หรือแค่พฤติกรรมที่ไม่เหมือนเดิม
    ถึงเวอร์ชันที่แปลจาก C++ เป็น Rust ช่วงแรกจะดูขัด ๆ ก็ไม่เป็นไร พอปลดระวางฝั่ง C++ ได้หมดแล้ว ค่อย ๆ ปรับให้เป็นสไตล์ที่ idiomatic มากขึ้นทีหลังก็ได้

    • การพอร์ตเป็นจังหวะที่ดีในการปรับปรุงหลายอย่าง แต่ไม่ใช่จังหวะในการเพิ่มฟีเจอร์ใหม่
      สามารถทำ refactor, ปรับประสิทธิภาพ, ทำเอกสารประกอบ ได้ ตราบใดที่ผลลัพธ์ยังเหมือนเดิม
      ผมคิดว่าช่วงที่กำลังอ่านโค้ดเพื่อนำมาทำเอกสารนี่แหละเป็นเวลาที่ดีที่สุด สำหรับโปรเจ็กต์ดังอย่าง Ladybird การทำเอกสารก็คือวิธีเร่งความเร็วการพัฒนา
    • อยากเห็นการพอร์ตแบบล้วน ๆ ด้วยวิธีนี้มากขึ้น
      เมื่อก่อนต้นทุนการย้ายระบบสูงมาก จนต้องหาเหตุผลแนว “ไหน ๆ ก็ทำแล้วก็ปรับปรุงไปเลย” แต่สุดท้ายกลับต้องไล่ตาม บั๊กผี มากกว่าเดิม
    • ชอบแนวทางนี้มาก มีบทความที่เขียนจากมุมมองเรื่อง การทดสอบและการตรวจสอบ เมื่อไม่กี่วันก่อน พอเห็นมันถูกนำมาใช้กับโปรเจ็กต์ซับซ้อนแบบนี้ก็ยิ่งน่าทึ่ง
    • ผมก็เคยแปลงเว็บเฟรมเวิร์กในลักษณะนี้มาหลายรอบแล้ว ทำให้สตริงผลลัพธ์ HTTP จากโค้ดใหม่ตรงกันทุกอย่างก่อน แล้วค่อย ลบของเก่าทิ้งทั้งหมด
    • ถ้ามี test suite ที่ดี วิธีนี้จะยิ่งเวิร์กมากขึ้น และคิดว่า Ladybird ก็น่าจะเป็นแบบนั้น

  • พวกเขาใช้ Claude Code และ Codex แปลโค้ด C++ ไปเป็น Rust
    ไม่ได้อัตโนมัติทั้งหมด แต่มีคนคอยกำหนดทิศทางและปรับด้วยพรอมป์เล็ก ๆ หลายร้อยครั้ง
    ตั้งเงื่อนไขตั้งแต่แรกว่าผลลัพธ์ของสอง pipeline ต้อง เหมือนกันทุกไบต์ และสุดท้ายก็ได้โค้ด Rust 25,000 บรรทัดภายใน 2 สัปดาห์
    ทั้ง AST และไบต์โค้ดตรงกัน และทำได้ ไม่มี regression เลย 0 ครั้ง
    ผมคิดว่านี่แหละคือวิธีที่ถูกต้องในการใช้ AI กับการพอร์ตข้ามภาษา

    • ผมเองก็เคยใช้ Claude ย้ายสคริปต์ Perl ที่พัง ๆ ไปเป็น Rust
      ใช้เวลา 80 นาทีในการวิเคราะห์โครงสร้าง Drupal และสร้างทั้งดีไซน์เดิมกับโครงสร้างโมดูลกลับขึ้นมาใหม่ รวมถึงทำ custom plugin ให้ด้วย
      ตอนนี้ได้ยินมาว่าเว็บนั้นย้ายไป WordPress, ProcessWire, Node.js และตอนนี้ก็ถึง Next.js แล้ว
    • น่าเสียดายที่บริษัท AI ไม่ค่อยโฟกัสกับ รูปแบบการใช้งานแบบร่วมมือกัน แบบนี้
      สิ่งที่ผมต้องการไม่ใช่ “โค้ดเสร็จสมบูรณ์จากพรอมป์ครั้งเดียว” แต่เป็นเครื่องมือที่คุยกับ AI ต่อเนื่องเป็นเซสชันยาว ๆ เพื่อ ขยายสติปัญญามนุษย์ (IA)
      แต่เครื่องมือแบบนี้คงมีแต่คนที่มีความรู้ด้านพัฒนาเท่านั้นที่ใช้ได้ เลยอาจเป็นตลาดที่เล็ก
    • ผมก็เรียน Rust ไปพร้อมกับสร้างสกิลชื่อ “teach” ให้ Claude ใช้อยู่เหมือนกัน
      Claude จะไม่เขียนโค้ดเอง แต่ ให้แค่ hint และช่วยรีวิว
      Rust เป็นภาษาที่ด้วยธรรมชาติแล้วเขียนสดแบบด้น ๆ ยาก วิธีนี้เลยน่าพอใจมาก
    • ผมก็ใช้ Claude แบบนี้เหมือนกัน ไม่ใช่ “ให้ AI ทำทุกอย่าง” แต่ใช้เป็นพาร์ตเนอร์ช่วย ออกแบบ รีวิว และทดสอบ
    • ผมเคยใช้ Claude ย้าย bash script ซับซ้อนที่ทำไว้ไปเป็น golang แล้วความเร็วกับความเสถียรก็ดีขึ้นมหาศาล
      ตอนนี้ยังมีเวอร์ชัน wasm ที่รันในเบราว์เซอร์ได้ด้วย
      ส่วนที่เกี่ยวกับคริปโตผมไม่ได้ให้มันเขียนเอง ดังนั้นไม่ต้องห่วง

  • ข่าวการย้ายไปใช้ Rust น่าสนใจ แต่ก็แปลกใจเพราะก่อนหน้านี้ทีม Ladybird เคยมีท่าที “anti-Rust hype” ค่อนข้างชัด
    ถึงอย่างนั้นถ้าย้ายมา Rust ผมน่าจะมีส่วนร่วมได้ง่ายขึ้นมาก

    • ผมก็ชอบ Rust แต่บางครั้ง ความคลั่งไคล้เกินพอดี ต่อภาษานี้ก็ทำให้รู้สึกเหนื่อย
      ภาษาเป็นแค่เครื่องมือ และไม่จำเป็นต้องผูกอัตลักษณ์ตัวเองไว้กับภาษาใดภาษาหนึ่ง
    • ผมไม่ได้ชอบ Rust แต่ในเชิง ปฏิบัติแล้วมันอาจเป็นตัวเลือกที่ดีที่สุด
    • มี ลิงก์ ที่บอกว่า Ladybird ตอนนี้ไม่ได้เน้น C++/Swift แล้ว
    • การเปลี่ยนทิศทางของภาษาบ่อย ๆ ทำให้รู้สึกกังวลนิดหน่อย เพราะ ความต่อเนื่อง ของโปรเจ็กต์อาจสั่นคลอน

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

    • Andreas ไม่ใช่แค่นักธุรกิจ แต่เป็นวิศวกรที่สร้าง Serenity OS มาคนเดียวหลายปี
      มองได้ว่าโปรเจ็กต์นี้เติบโตขึ้นอย่างเป็นธรรมชาติ
    • เขาบอกว่าการตัดสินใจเลือก Swift ก็เป็น การตัดสินใจอย่างมีเหตุผล หลังจากได้ลองหลายภาษาเองแล้ว
    • เผื่อใครยังไม่รู้ เขาเคยทำงานอยู่ในทีม Apple Safari engine มาก่อน
    • ถึงอย่างนั้นก็ยังไม่แน่ใจว่าสุดท้ายมันจะกลายเป็นเบราว์เซอร์ใหม่จริง ๆ ได้หรือเปล่า
    • ตอนที่บอกว่า “กังวล” นั้น กังวลเรื่องอะไรเป็นพิเศษหรือเปล่า

  • คำพูดที่ว่า “เป็น Rust code ที่ไม่ปกติแต่จะค่อยมาเก็บทีหลัง” ฟังดูเหมือนกำลังบอกใบ้ถึง การรีไรต์อีกรอบ ซึ่งน่ากังวล
    เวลาสตาร์ตอัปเปลี่ยนภาษา มันมักถูกมองว่าเป็น สัญญาณอันตราย

    • แต่ C++ กับ Rust ต่างก็เป็น ภาษาแบบ multi-paradigm เหมือนกัน จึงย้ายโครงสร้างให้คล้ายกันได้
    • มันทำให้นึกถึง “กับดักของการรีไรต์” ที่ Joel on Software เคยพูดถึง
      ถ้าการพัฒนาเวอร์ชันใหม่เดินคู่ไปกับการเพิ่มฟีเจอร์ให้ของเดิม จะเกิด การแข่งขันด้านความเร็ว และเวอร์ชันใหม่อาจตามไม่ทัน
    • แต่ Ladybird ไม่ใช่สตาร์ตอัป เป็นโปรเจ็กต์โอเพนซอร์ส ดังนั้นจึงเทียบกันตรง ๆ ไม่ได้
      Linux, PHP และ musl libc ก็เคยผ่าน การรีไรต์ทั้งก้อน มาหลายครั้ง
    • ถ้าเป็นผมในสถานการณ์แบบนี้ก็คงใช้ Firefox ต่อไป
    • การพอร์ตด้วย LLM อยู่หลายสัปดาห์ก็ดูเป็น ทางเลือกที่แปลกพอสมควร

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

    • ผมเองก็เคยใช้ AI สร้างไลบรารี Python CLI สำหรับโปรเจ็กต์ส่วนตัว
      การได้ลอง UI หลายแบบอย่างรวดเร็ว เช่น Streamlit, Shiny, Dash ทำให้ การทำต้นแบบ สนุกมาก
    • ในระยะยาว เมื่อ AI พัฒนาขึ้น ความหมายของ ภาษาโปรแกรมเอง อาจลดลง
      ตอนนี้บางโปรเจ็กต์ก็รันได้สบายด้วยการจับคู่ low-code + agent แล้ว

  • ประโยคที่ว่า “ให้ AI รีวิวโค้ด” ฟังดูน่ากังวล
    โมเดลยังมีข้อจำกัดในการจับ ข้อผิดพลาดเชิงตรรกะ

    • แต่ถ้าผลลัพธ์สุดท้ายคือผ่านการทดสอบ 65,000 เคสด้วย ไม่มี regression + ผลลัพธ์เหมือนเดิม ก็อาจมองข้ามไปทั้งหมดไม่ได้
      อย่างไรก็ตาม ประเด็นสำคัญคือการ “เก็บงาน (cleanup)” ภายหลังจะเกิดขึ้นจริงหรือไม่
    • ผู้รีวิวที่เป็นมนุษย์ก็ไม่ได้สมบูรณ์แบบ ถ้ารีวิวจากหลายมุมมอง ไม่ว่าจะ AI หรือคน ก็อาจจับ ข้อผิดพลาดคนละแบบ ได้
    • เรื่องพวกนี้ควรเป็นหน้าที่ของ test suite ในการยืนยัน
    • แต่ก็มีคนที่ไม่อยากแตะ Rust code แบบไม่เป็นมาตรฐาน ที่ AI สร้างขึ้น
      ถ้าพึ่งโค้ดจาก AI มากขึ้นเรื่อย ๆ ก็จะเกิดวงจรที่ พึ่งพา AI มากขึ้นเรื่อย ๆ

  • การที่โปรเจ็กต์พัฒนา C++ กับ Rust ควบคู่กันไป ดูไม่มีประสิทธิภาพ
    บางคนเลยคิดว่าน่าจะดีกว่าถ้ารวมให้เหลือภาษาเดียวที่มีความปลอดภัยด้านหน่วยความจำ

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

  • ตอนที่ประกาศใช้ Swift ในปี 2024 Andreas เคยทวีตถึง Rust ไว้
    เขาบอกว่า Rust เยี่ยมสำหรับโปรแกรมที่รันไม่นาน แต่ ไม่สะดวกกับโปรแกรมระยะยาวที่ต้องรักษา object graph ซับซ้อน
    และยังบอกด้วยว่าคอมมูนิตี้มีความ เป็นพิษ
    ลิงก์ทวีตที่เกี่ยวข้อง

    • เขาเปลี่ยนใจแล้วหรือ? หรือจริง ๆ แล้วตั้งแต่แรกอาจไม่จำเป็นต้องเปลี่ยนจาก C++ ก็ได้
    • ผมก็เข้าใจความเห็นเรื่อง บรรยากาศที่ค่อนข้าง排他 ของคอมมูนิตี้ Rust
    • หรืออาจเป็นไปได้ว่าพวกเขาผลักดันการย้ายไป Rust ด้วย AI เพราะ ข้อเรียกร้องจากสปอนเซอร์

  • อยากรู้ว่า Rust code ที่ไม่เป็นมาตรฐานนี้จะกลายเป็น หนี้ทางเทคนิค ในภายหลังหรือเปล่า

    • ความเสี่ยงหลักอยู่ที่ขั้นตอนเก็บงานภายหลัง รูปแบบ pointer แบบ C++ อาจชนกับ กฎ ownership ของ Rust
      โปรเจ็กต์ Servo ก็เคยเจอปัญหานี้ แต่ในกระบวนการนั้นก็สามารถจับ บั๊กแฝง ได้ด้วย
    • ไม่ใช่ว่า C++ เองมีปัญหา แต่เหตุผลที่ย้ายมา Rust คือ ความปลอดภัยด้านหน่วยความจำ
    • ก่อนหน้านี้ Andreas ก็เคยพูดถึงปัญหา ความปลอดภัยของ GC ใน JS runtime และต้องการภาษาที่ปลอดภัยกว่า
      การย้ายไป Rust จึงดูเป็น การตัดสินใจที่สุกงอม ซึ่งสอดคล้องกับแนวคิดนั้น