Git ประกาศนำ Rust มาใช้และกำหนดให้เป็นข้อบังคับในระบบบิลด์

 (lore.kernel.org)
15 คะแนน โดย GN⁺ 2025-09-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โครงการ Git ประกาศอย่างเป็นทางการว่า จากนี้ไปจะ นำ Rust มาใช้ในแกนหลัก และตั้งแต่ Git 3.0 เป็นต้นไป Rust จะกลายเป็น ข้อกำหนดบังคับสำหรับการบิลด์
  • ชุดแพตช์ครั้งนี้ดำเนินไปในลักษณะของ การทดลองนำร่อง (test balloon) คล้ายกับการนำความสามารถ C99 มาใช้ในอดีต โดยมีเป้าหมายเพื่อค่อย ๆ วางโครงสร้างพื้นฐานสำหรับการนำ Rust มาใช้
  • ในขั้นแรกได้แปลงโมดูล varint.c ที่แทบไม่มี dependency ไปเป็น Rust เพื่อทดสอบ การทำงานร่วมกันระหว่าง C-Rust และเครื่องมือสำหรับการบิลด์
  • ขณะนี้รองรับเฉพาะการบิลด์ด้วย Meson เท่านั้น และในอนาคตมีแผนเพิ่ม การรองรับ Makefile รวมถึงเพิ่ม การตรวจสอบการบิลด์ Rust ใน CI และการตรวจสอบความสม่ำเสมอของรูปแบบโค้ดด้วย cargo format
  • นี่คือการเปลี่ยนแปลงสำคัญที่เปิดเวลาให้ชุมชน Git และผู้จัดทำแพ็กเกจได้ ปรับตัวกับข้อกำหนดใหม่ของ Rust toolchain พร้อมทั้งช่วยเพิ่มความปลอดภัยของโค้ดและความสามารถในการขยายในระยะยาว

ที่มาของการนำ Rust มาใช้

  • Git ได้พิจารณาวิวัฒนาการด้านภาษาเพื่อความเสถียรและการบำรุงรักษา
  • การนำ Rust มาใช้มีความหมายในแง่ของ การเสริมความปลอดภัยด้านหน่วยความจำ, การใช้ประโยชน์จาก toolchain สมัยใหม่ และ การเปิดทางสู่การปรับแต่งประสิทธิภาพ
  • อีกทั้งยังต้องการสร้าง codebase ที่แข็งแกร่งยิ่งขึ้นผ่านการนำภาษาสมัยใหม่มาใช้
  • การแจ้งล่วงหน้าว่าเมื่อถึงช่วงออก Git 3.0 จะต้องใช้ Rust เป็นการเปิดเวลาให้ ecosystem เตรียมความพร้อม
  • จะค่อย ๆ ขยายขอบเขตการใช้โค้ด Rust ทีละขั้น และมีแผนสุดท้ายที่จะนำฟังก์ชันแกนหลักบางส่วนมาเขียนใหม่ด้วย Rust

ชุดแพตช์เชิงทดลอง

  • เลือก varint.c เป็นโมดูลแรกสำหรับการนำ Rust มาใช้
    • เรียบง่ายมากและไม่มี dependency
    • สามารถตรวจสอบ interop ระหว่าง C ↔ Rust ได้
    • ทดลองได้โดยไม่กระทบต่อฟังก์ชันโดยรวมของ Git
  • การทดสอบทั้งหมดผ่านบนเวอร์ชัน varint.rs

การเปลี่ยนแปลงของระบบบิลด์

  • ตอนนี้เพิ่มการรองรับ Rust เฉพาะใน ระบบบิลด์ Meson
  • ในอนาคตมีแผนเพิ่ม การรองรับ Rust ใน Makefile
  • ยังต้องเตรียมงานที่เกี่ยวข้องกับ CI ด้วย
    • การตรวจสอบการบิลด์และการทำงานของ Rust
    • การรักษาความสม่ำเสมอของสไตล์โค้ดผ่าน cargo format
    • เครื่องมืออื่น ๆ และการทำงานอัตโนมัติด้านการบำรุงรักษา

แผนในอนาคต

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

นัยสำคัญ

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

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

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

 
GN⁺ 2025-09-21
ความคิดเห็นจาก Hacker News
  • จากการถกเถียงในอีกเธรดเรื่องการทำให้ Rust เป็นข้อบังคับ ผู้เขียนเห็นว่าควรเริ่มจากการนำ Rust มาเป็น dependency แบบเลือกใช้ก่อน แล้วค่อยเปลี่ยนเป็นข้อบังคับภายหลังเมื่อ gcc เพิ่มการรองรับ Rust แล้วจะดีกว่า
    ลิงก์การอภิปรายที่เกี่ยวข้อง
    • เน้นว่าคอมไพเลอร์ gcc มีความไม่สม่ำเสมออยู่แล้ว เช่น gcj (gcc สำหรับ Java) ก็แทบไม่มีใครใช้
      และเพราะ Rust เป็นภาษาที่ยังไม่มีมาตรฐาน จึงสงสัยว่าเมื่อเวลาผ่านไป implementation อาจล้าหลังมากขึ้นได้ (เหมือนที่เคยเกิดกับ Java)
  • สงสัยว่าทำไมถึงต้องการนำ Rust มาใช้กับ Git
    Git ดูเป็นเครื่องมือที่สุกงอมมากแล้ว น่าจะต้องการเพียงการบำรุงรักษาหรือปรับปรุงเล็กน้อยเท่านั้น ไม่ได้ดูเหมือนต้องมีโค้ดใหม่ขนาดใหญ่จนต้องนำภาษาใหม่เข้ามา
    ต่างจากกรณีอย่าง Linux ที่ยังต้องมีไดรเวอร์ใหม่ ๆ อยู่เสมอ ซึ่งสำหรับ Git ดูไม่เห็นเหตุผลแบบนั้น
    อยากให้มีคนอธิบายว่าตนกำลังมองข้ามอะไรไปหรือไม่
    • Git ยังมีการเพิ่มฟีเจอร์อย่างต่อเนื่อง แม้จะไม่ค่อยเด่นชัด
      ดูการเปลี่ยนแปลงของ Git ได้จาก RelNotes หรือถ้าอยากอ่านแบบเข้าใจง่ายขึ้นก็ดูได้ที่ หมวด Git ในบล็อก GitHub
    • ถ้าได้ลองใช้เครื่องมืออย่าง jj หรือ git-branchless มุมมองที่ว่า git เสร็จสมบูรณ์แล้วอาจเปลี่ยนไป
      ในกรณีของ git-branchless ก็มีฟีเจอร์อย่าง in-memory merge ที่เขียนด้วย Rust
    • มีหลายคำตอบในโพสต์นี้ที่น่าอ่าน
      เนื้อหาเกี่ยวกับ Rust ก็หาเพิ่มเติมได้ใน mailing list นั้น
      (ไม่ได้จะประเมินเองว่าฝั่งไหนถูก แต่คงมีคนทำแทนอยู่แล้ว)
    • โปรเจกต์ C เก่า ๆ กำลังเจอปัญหาคนพัฒนาใหม่เข้ามาน้อยลงเรื่อย ๆ
      แทบไม่มีใครอยากพัฒนา Git ด้วย C แต่มีนักพัฒนาที่สนใจการ rewrite เป็น Rust และกระตือรือร้นจะเข้าร่วม
    • C ไม่ปลอดภัย
  • สงสัยว่าทำไมจึงพยายามนำ Rust ไปใช้ในหลายที่อยู่เรื่อย ๆ
    Git มีความสุกงอมสูงและน่าจะมีโค้ดใหม่เพิ่มไม่มาก
    Rust ซับซ้อนกว่า C มาก
    ถ้าจำเป็นต้องมีความสามารถเชิงวัตถุจริง ๆ ใช้แค่ C++98 ก็น่าจะง่ายและเข้าใจได้กว่ามากเมื่อเทียบกับ C++ สมัยใหม่หรือ Rust
  • ชื่อหัวข้อชวนให้เข้าใจผิดอยู่พอสมควร
    ไม่ใช่ว่า Rust จะกลายเป็นข้อบังคับสำหรับแพตช์ในอนาคต แต่จะกลายเป็นข้อบังคับภายในระบบ build
    • มีการขอบคุณและบอกว่าได้แก้ชื่อหัวข้อให้สะท้อนประเด็นนี้แล้ว
      ถ้ายังไม่ถูกก็แก้ได้อีก
    • จากนั้นก็มีคำถามต่อว่านี่หมายถึงอะไรกันแน่
      หมายถึงต้องใช้เพื่อ build ตัวระบบ build เอง หรือจำเป็นต่อการ build แอปพลิเคชันด้วย
  • มีความเห็นบ่นว่าแม้จะคิดว่าตัวเองแก่พอที่จะต้องยอมรับความเปลี่ยนแปลง แต่เดิมรู้แค่ C ก็มีส่วนร่วมกับการพัฒนา Git หรือเคอร์เนลได้แล้ว ตอนนี้ต้องรู้ Rust เพิ่มอีก และ toolchain ก็ซับซ้อนขึ้นเรื่อย ๆ ทำให้กำแพงการเข้าถึงสูงขึ้น
    ตัวเองลงทุนกับ Git ไว้มากและสร้างหลายโปรเจกต์ จึงไม่อยากเสียความสามารถในการ hack Git ไป
    • มีคนเห็นว่าทัศนคติแบบไม่อยากเรียนรู้ของใหม่ไม่เหมาะกับอุตสาหกรรมนี้
      ในความเป็นจริง Rust เรียนรู้ง่ายกว่า C ทั่วไป (โดยเฉพาะ C ที่มีบั๊กเยอะ) และง่ายกว่าการทำความเข้าใจซอร์สของ Git หรือ Linux อย่างแน่นอน
    • ต่อให้สร้าง Git client และเว็บเซิร์ฟเวอร์ขึ้นมาเอง รูปแบบ repository ของ Git ก็ไม่ได้เปลี่ยน จึงไม่น่ากระทบกับความสามารถในการ hack
    • อีกอย่าง Git เองก็ประกอบด้วยหลายภาษาอยู่แล้ว
      ตาม GitHub มีสัดส่วนเป็น C 50%, Shell 38%, Perl 4% ที่เหลือเป็น TCL/Python เป็นต้น
      Perl/TCL ต่างหากที่ค่อนข้างเป็นข้อยกเว้น
      โปรเจกต์เติบโตมาพร้อมโค้ด hack เฉพาะกิจจำนวนมากที่ถูกแปะเพิ่มไปเรื่อย ๆ และตอนนี้ก็น่าจะถึงเวลาปรับปรุงความปลอดภัย/ประสิทธิภาพ พร้อมเก็บกวาดโค้ดเก่าเหล่านั้น
      จึงมองว่า Rust เหมาะกับงานนี้
    • สำหรับวิศวกรซอฟต์แวร์ การใช้งานได้หลายภาษาถือเป็นเรื่องปกติอยู่แล้ว ดังนั้นการเพิ่มภาษาอีกหนึ่งภาษาจึงไม่ใช่ปัญหาใหญ่
    • มีนักพัฒนารุ่นใหม่จำนวนมากรวมถึงตัวเขาเองที่ชอบ Rust และไม่อยากเรียน C
      และการที่ Git ใช้ Rust บางส่วนก็คงไม่ได้ขัดขวางการพัฒนา Git client หรือเซิร์ฟเวอร์ที่ตนสร้างเอง
  • มีการขอคำอธิบายเพิ่มเติมต่อความเห็นที่ว่าการนำ Rust มาใช้เป็นไปไม่ได้บนบางแพลตฟอร์ม และทำได้ยากบนอีกหลายแห่ง
    • บนระบบ Linux ไลบรารีทุกตัวควรใช้เป็น system library ได้ แต่ Rust ไม่มี ABI ที่เสถียร จึงใช้เป็น shared library ที่แท้จริงไม่ได้
      ใน release notes ของ Debian ก็ระบุ ปัญหาที่เกี่ยวกับแพ็กเกจ Rust/Go ไว้ชัดเจน
      เวลา build แพ็กเกจ Rust มักต้อง rebuild บ่อยเพราะปัญหา static link ทำให้ใช้งานจริงไม่สะดวก
      ถ้าฝั่ง Rust ยังเมินปัญหาเรื่อง ABI ที่เสถียร/ไลบรารีแบบแชร์ซึ่งจำเป็นมากใน Linux OS ก็อาจสร้างความไม่พอใจได้มากกว่า C เสียอีก
      จึงมองว่าสถาปัตยกรรมซอฟต์แวร์ขนาดใหญ่ควรระมัดระวังให้มากกว่านี้
    • บนแพลตฟอร์ม proprietary บางตัวที่ไม่ค่อยเปิดเผย มีการรองรับคอมไพเลอร์ C ของตัวเองแต่รองรับ LLVM ไม่ได้
      ลองค้นหาคำว่า NonStop ในบทความนี้จะเห็นตัวอย่าง
    • เพราะคอมไพเลอร์ Rust ไม่รองรับบางแพลตฟอร์ม (คู่ OS/สถาปัตยกรรม)
      ใน RESF และที่อื่น ๆ มักพูดว่า “แพลตฟอร์มไม่รองรับ Rust” แต่ความจริงคือต้องให้คอมไพเลอร์ Rust รองรับก่อนจึงจะใช้งานได้จริง
    • Rust อิงกับ LLVM จึงรองรับแพลตฟอร์มได้จำกัดกว่า GCC
    • มีการแนะนำให้ดูหัวข้อ 'Tier 3' ใน รายการแพลตฟอร์มที่ Rust รองรับ ของเอกสารทางการ
  • สงสัยว่าใน git 3.0 จะมีอะไรเปลี่ยนไปบ้าง
    git ดูเหมือนจะนิ่งและเสถียรในสาย 2.x แล้ว จึงไม่เห็นเหตุผลที่จะต้องทำ breaking compatibility
    • มีคำตอบให้ไปดูเอกสาร git 3.0 Breaking Changes
    • ฟังก์ชันแฮชเริ่มต้นจะเปลี่ยนเป็น SHA-256
  • ในอดีตเคยมองเป็นพื้นฐานอยู่แล้วว่าสภาพแวดล้อมสำหรับ cross-compile, การรัน, และการแก้ไขโค้ด มักไม่เหมือนกัน
    จึงสงสัยว่าวัฒนธรรมการพัฒนายุคหลังเริ่มห่างไกลจากการใช้ toolchain แบบนี้หรือไม่
    ทั้ง source control, การ build, และสภาพแวดล้อมรันงานมักต่างกัน ต้องอาศัยการคัดลอกไปยังรีโมตหรือการรันจากระยะไกล และกฎการ build ก็จำเป็นต้องตรวจจับแพลตฟอร์มเป้าหมายด้วย
    • กลับกัน มีคนรู้สึกว่า toolchain ของ Rust ทำให้ cross-compilation ง่ายกว่าภาษาคอมไพล์อื่น ๆ
      ใช้เพียงแฟล็ก --target ก็ build ได้ราว 100 แพลตฟอร์มโดยแทบไม่มีปัญหา
      ปัญหาจริงน่าจะมาจากที่ทีมพัฒนา Git บางคนยังยึดติดกับข้อจำกัดของเครื่องพัฒนาเก่า ๆ หรือเครื่องที่ล็อกสเปกไว้
    • มีความเห็นว่านักพัฒนาส่วนใหญ่จริง ๆ แล้วไม่ได้เรียนรู้ cross-compilation อย่างเพียงพอ
      cross-compilation มักถูกมองเป็นพลเมืองชั้นสอง และในโปรเจกต์ภายนอกก็แทบไม่คาดหวังว่าจะใช้งานได้ดี
      แม้แต่ Linux distribution บางตัวก็ให้ build สำหรับ Raspberry Pi บนฮาร์ดแวร์จริงเท่านั้น
      ด้วยเหตุนี้จึงแทบไม่มีใครพยายามสนับสนุนมันอย่างจริงจัง
    • ไม่เกี่ยวกับ Rust/ใด ๆ แต่สภาพของ cross-compilation ในปัจจุบันนั้นใกล้เคียงกับ “หายนะ”
      โดยเฉพาะบน Linux ที่แย่เป็นพิเศษ เพราะโครงสร้างของ glibc ล้าสมัยจนยากจะตั้งเป้าไปที่ glibc ขั้นต่ำบนฮาร์ดแวร์ใด ๆ
      โปรเจกต์ส่วนใหญ่แทบไม่พยายามรองรับ cross-compilation เลย
      Zig กำลังพยายามแก้ปัญหานี้อยู่
  • มีคนยืนยันว่าควรรอให้ Rust frontend ที่เกี่ยวกับ gcc เติบโตเต็มที่ก่อนค่อยนำมาใช้
    Git เป็นเครื่องมือแกนกลางของโปรเจกต์ต่าง ๆ ดังนั้นความเปลี่ยนแปลงจึงมีความเสี่ยงสูง และการทำให้เป็น dependency ที่จำเป็นภายในเวลาเพียง 6 เดือนนั้นอันตรายเกินไป
  • Rust มีเส้นโค้งการเรียนรู้สูงและซับซ้อน คล้ายภาษาเชิงฟังก์ชัน
    ความซับซ้อนนี้มีเป้าหมายเพื่อจับข้อผิดพลาดให้ได้มากขึ้นตอน compile time แต่ผลลัพธ์ก็คือภาษานั้นเองซับซ้อนมาก
    ด้วยเหตุนี้จึงไม่แนะนำให้นำมาใช้
    และเข้าใจว่าเคอร์เนลก็ปฏิเสธการนำ Rust มาใช้เช่นกัน
    การเพิ่ม type system ระดับ Haskell และ macro system ระดับ Lisp เข้าไปในเคอร์เนลที่ซับซ้อนอยู่แล้ว ยิ่งเพิ่มความซับซ้อนขึ้น
    การไล่ตามโค้ด Rust ผ่าน serde ก็ทำได้ยาก
    ตรงกันข้าม Go มี Unmarshal ที่ตามรอยได้ง่ายกว่ามาก
    • แต่อีกฝ่ายกลับรู้สึกว่าภาษาเชิงฟังก์ชันและ Rust ชัดเจนกว่า C หรือ Go เสียอีก
      เพราะสามารถใส่ข้อมูลให้คอมไพเลอร์เข้าใจได้มากกว่า
      ไม่เคยมีปัญหาใหญ่กับ Serde และกลับต้องดีบัก Go Unmarshal บ่อยกว่า
      ส่วนคำกล่าวอ้างว่าเคอร์เนลปฏิเสธ Rust นั้น ความจริงคือเป็นความขัดแย้งระหว่างนักพัฒนาสองคนเรื่องตำแหน่งเก็บ header
    • C นั้นเรียบง่าย แต่ C ที่ปลอดภัยและมีประสิทธิภาพสูงกลับซับซ้อนมาก
      Rust อาจเริ่มต้นยากกว่า C แต่ช่องว่างระหว่าง “Rust ขั้นพื้นฐาน” กับ “Rust ที่เร็วและปลอดภัย” นั้นเล็กกว่าของ C มาก
    • มีคนชี้ว่าแม้จะบอกว่า Rust ซับซ้อน แต่ C เองก็ซับซ้อนไม่แพ้กัน
    • ความสะดวกของการตรวจสอบในช่วง compile time แบบนี้เองคือจุดต่างสำคัญของ Rust
      และถูกมองว่าสำคัญพอ ๆ กับ borrow checker
    • ถ้ามีประสบการณ์กับ Typescript และคุ้นเคยกับการใช้ linter เพื่อตรวจเรื่อง reference หรือการ unwrap Result/การจัดการ error มาก่อน ก็จะเรียน Rust ได้ค่อนข้างง่าย
      ตัวภาษาก็ยืดหยุ่นพอสมควร
      และ Linux kernel ก็ไม่ได้ปฏิเสธ Rust จริง ๆ