ผู้ดูแล Git คือ Patrick Steinhardt ได้ประกาศแผนการนำ Rust เข้ามาใช้ในโค้ดหลักของ Git โดย Git 3.0 จะกำหนดให้ Rust เป็นข้อกำหนดบังคับสำหรับการ build ข้อเสนอนี้ได้จุดประกายการอภิปรายอย่างเข้มข้นในชุมชนเกี่ยวกับความเข้ากันได้ของแพลตฟอร์มและทิศทางในอนาคตของหนึ่งในเครื่องมือสำคัญที่สุดสำหรับนักพัฒนาทั่วโลก
การประกาศครั้งนี้เป็นการทดลองความเป็นไปได้ - เป็นวิธีการวัดปฏิกิริยาของชุมชนก่อนที่จะตัดสินใจเปลี่ยนแปลงอย่างเต็มที่ Steinhardt ซึ่งทำงานเป็นผู้จัดการฝ่ายวิศวกรรมที่ GitLab และเป็นผู้มีส่วนร่วมใน Git อย่างสม่ำเสมอ ได้เริ่มต้นด้วยการแปลงระบบ varint ของ Git เป็น Rust อย่างง่าย ๆ เป็นการพิสูจน์แนวคิด
การเปลี่ยนแปลงที่วางแผนไว้สำหรับ Git 3.0:
- Rust กลายเป็นสิ่งจำเป็นสำหรับการสร้าง Git
- SHA-256 กลายเป็นอัลกอริทึมแฮชเริ่มต้น
- คาดว่าจะมีการเปลี่ยนแปลงที่ทำลายความเข้ากันได้
- ยังไม่ได้กำหนดกรอบเวลาที่แน่นอน
ความกังวลเรื่องความเข้ากันได้ของแพลตฟอร์มขับเคลื่อนการถกเถียงครั้งใหญ่
การอภิปรายที่เข้มข้นที่สุดเน้นไปที่แพลตฟอร์มที่ไม่สามารถรองรับการคอมไพล์ Rust ได้ ระบบที่เป็นกรรมสิทธิ์หลายระบบ โดยเฉพาะแพลตฟอร์ม NonStop ของ IBM ที่ใช้ในบริการทางการเงิน อาศัย C compiler เฉพาะของผู้ขายโดยไม่มีการรองรับ LLVM หรือ GCC สิ่งนี้สร้างความท้าทายอย่างมากเนื่องจาก Rust ต้องพึ่งพา compiler backend สมัยใหม่เหล่านี้
สมาชิกในชุมชนแบ่งออกเป็นสองฝ่ายในการจัดการกับข้อจำกัดนี้ บางคนโต้แย้งว่าแพลตฟอร์มเก่าควรปรับตัวหรือเสี่ยงที่จะถูกทิ้งไว้ข้างหลัง ในขณะที่คนอื่น ๆ กังวลเกี่ยวกับผลกระทบในวงกว้างต่อการเข้าถึง Git ได้อย่างสากล การพึ่งพาของภาคการเงินต่อระบบเหล่านี้เพิ่มความซับซ้อนให้กับการถกเถียง เนื่องจากโครงสร้างพื้นฐานการประมวลผลบัตรเครดิตและธนาคารมักจะทำงานบนแพลตฟอร์มดังกล่าว
น่าเสียดายสำหรับแพลตฟอร์มนั้น? จริง ๆ แล้วฉันเดาว่าพวกเขาต้องอยู่โดยไม่มี git หากพวกเขาไม่เต็มใจที่จะรับผิดชอบในการรองรับ tool chain ของมัน
กำลังมีการสำรวจแนวทางแก้ไขทางเทคนิค รวมถึง Rust backend ทดลองที่คอมไพล์เป็นโค้ด C และเครื่องมือแปลง WebAssembly-to-C อย่างไรก็ตาม วิธีแก้ปัญหาเหล่านี้ยังไม่ได้รับการทดสอบสำหรับการใช้งานจริง
ระดับการรองรับแพลตฟอร์มของ Rust:
- Tier 1: รับประกันว่าใช้งานได้ ( x86-64 , ARM64 บนระบบปฏิบัติการหลัก)
- Tier 2: รับประกันว่าสามารถ build ได้ (แพลตฟอร์มเพิ่มเติมจำนวนมาก)
- Tier 3: การสนับสนุนแบบพยายามอย่างดีที่สุด (รวมถึงเป้าหมายทดลองเช่น PlayStation , N64 )
- ไม่รองรับ: แพลตฟอร์ม compiler แบบกรรมสิทธิ์ ( NonStop , ระบบ embedded บางประเภท)
ผลกระทบต่อประสบการณ์ของนักพัฒนาและเส้นโค้งการเรียนรู้
การเปลี่ยนแปลงนี้ทำให้เกิดคำถามเกี่ยวกับการเข้าถึงได้ของ Git สำหรับผู้มีส่วนร่วม ปัจจุบัน Git ใช้หลายภาษารวมถึง C, Shell, Perl และ Python แต่ C ยังคงเป็นภาษาหลักสำหรับฟังก์ชันหลัก การเพิ่ม Rust เป็นส่วนประกอบบังคับหมายความว่าผู้มีส่วนร่วมในอนาคตจะต้องคุ้นเคยกับทั้งสองภาษา
นักพัฒนาบางคนแสดงความกังวลเกี่ยวกับความซับซ้อนที่เพิ่มขึ้นและเวลา build ที่นานขึ้น คนอื่น ๆ โต้แย้งว่าคุณสมบัติความปลอดภัยของ Rust และเครื่องมือสมัยใหม่จะเป็นประโยชน์ต่อความสามารถในการดูแลรักษาและความปลอดภัยระยะยาวของโครงการในที่สุด
การเปลี่ยนผ่านดูเหมือนจะได้รับการออกแบบให้เป็นไปอย่างค่อยเป็นค่อยไป โดยข้อเสนอปัจจุบันส่งผลกระทบต่อโครงสร้างพื้นฐานการ build เท่านั้น แทนที่จะต้องเขียนโค้ดใหม่ทั้งหมดใน Rust ทันที
องค์ประกอบภาษาปัจจุบันของ Git:
- C: 50%
- Shell: 38%
- Perl: 4%
- TCL: 4%
- Python: 1%
- อื่นๆ: 3%
การจับเวลาเชิงกลยุทธ์และบริบทของอุตสาหกรรม
การเคลื่อนไหวนี้เกิดขึ้นในขณะที่ Git เตรียมตัวสำหรับเวอร์ชัน 3.0 ซึ่งจะทำให้ SHA-256 เป็นอัลกอริทึมแฮชเริ่มต้นด้วย การจับเวลาแสดงให้เห็นว่าผู้ดูแล Git มองว่านี่เป็นโอกาสในการปรับปรุง toolchain ทั้งหมดให้ทันสมัยในขณะที่การทำลายความเข้ากันได้ได้รับการคาดหวังไว้แล้ว
การตัดสินใจนี้สะท้อนแนวโน้มของอุตสาหกรรมในวงกว้างที่มุ่งไปสู่ภาษาที่ปลอดภัยต่อหน่วยความจำ คล้ายกับความคิดริเริ่มใน Linux kernel และโครงการโครงสร้างพื้นฐานที่สำคัญอื่น ๆ อย่างไรก็ตาม บทบาทของ Git ในฐานะเครื่องมือสำคัญสำหรับนักพัฒนาทำให้ความเข้ากันได้ของแพลตฟอร์มมีความสำคัญเป็นพิเศษเมื่อเปรียบเทียบกับซอฟต์แวร์เฉพาะทางมากกว่า
การตอบสนองของชุมชนน่าจะมีอิทธิพลต่อการที่ข้อเสนอนี้จะดำเนินไปตามแผนหรือต้องการการปรับเปลี่ยนเพื่อแก้ไขความกังวลเรื่องความเข้ากันได้ ในฐานะหนึ่งในเครื่องมือนักพัฒนาที่ใช้กันอย่างแพร่หลายที่สุดทั่วโลก การเลือกภาษาของ Git มีผลกระทบอย่างกว้างขวางต่อระบบนิเวศการพัฒนาซอฟต์แวร์ทั้งหมด
อ้างอิง: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty