ความคืบหน้าในการพัฒนาคอมไพเลอร์ Rust บน GCC

 (lwn.net)
2 คะแนน โดย GN⁺ 2023-12-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • gccrs เป็นโครงการที่เริ่มในปี 2014 เพื่อพัฒนาคอมไพเลอร์ Rust ภายใน GCC แม้ยังห่างไกลจากความสมบูรณ์ แต่ก็มีความคืบหน้าไปสู่การคอมไพล์ไลบรารีมาตรฐานและการรวมเข้ากับ GCC 14
  • โครงการตั้งเป้าไปที่ Rust 1.49 แทนที่จะไล่ตาม Rust เวอร์ชันล่าสุดที่เปลี่ยนแปลงอย่างรวดเร็ว แต่เพราะ dependency ภายในไลบรารีมาตรฐาน สุดท้ายจึงต้อง implement ฟีเจอร์อย่าง const generics ด้วย
  • การคอมไพล์ core และ alloc ยังติดปัญหาเรื่องการ resolve ชื่อ macro, decorator macro, compiler intrinsic ของ LLVM ที่ไม่มีใน GCC และการไม่มี borrow checker
  • rustc_codegen_gcc เป็นแนวทางที่ mature กว่า โดยใช้บางส่วนของ rustc และใช้ GCC เป็น backend สำหรับสร้างโค้ด และ ณ เดือนตุลาคม 2023 สามารถคอมไพล์ Rust for Linux ได้โดยไม่ต้องมี patch เพิ่มเติม
  • gccrs มีแรงจูงใจชัดเจนจาก plugin ด้านความปลอดภัยของ GCC, static analysis, สถาปัตยกรรมที่ LLVM ไม่รองรับ และ Rust for Linux แต่ความใช้งานได้จริงยังจำกัดกว่า rustc_codegen_gcc

เป้าหมายและสถานะปัจจุบันของ gccrs

  • gccrs เป็นโครงการที่ต้องการ implement คอมไพเลอร์ Rust ภายใน GNU Compiler Collection(GCC)
  • เริ่มต้นในปี 2014 และตามรายงานของโครงการหลังจากที่ LWN เคยนำเสนอไปก่อนหน้านี้ ก็มีความคืบหน้าเกิดขึ้น
  • ในปี 2022 เคยตั้งเป้ารวมเข้ากับ GCC 13 แต่ไม่สำเร็จ และตามรายงานประจำเดือนพฤศจิกายน 2023 เป้าหมายคือการรวมเข้ากับ GCC 14
    • GCC 14 ถูกกล่าวถึงว่าเป็นเวอร์ชันที่อาจออกในช่วงกลางปี 2024
  • ในงาน EuroRust 2023 เดือนตุลาคม 2023 Arthur Cohen อธิบายงานคอมไพล์ไลบรารีมาตรฐานของ Rust และเหตุผลที่ยังคอมไพล์ไม่ได้ ในหัวข้อ “The road to compiling the standard library with gccrs”

เหตุผลที่ตั้งเป้าไปที่ Rust 1.49

  • gccrs ตั้งเป้าไปที่ Rust 1.49 แทนที่จะไล่ตาม Rust เวอร์ชันล่าสุดอย่างต่อเนื่อง
  • Rust 1.49 ออกช่วงปลายปี 2020 และเป็นเวอร์ชันสุดท้ายก่อนการรองรับ const generics ซึ่งเปิดให้ใช้งานทั่วไปใน Rust 1.50
  • โครงการพยายามหลีกเลี่ยง const generics แต่ภายในไลบรารีมาตรฐานของ Rust 1.49 ก็มีการใช้งานอยู่แล้ว จึงไม่อาจละเลยได้ในที่สุด
  • ต่อมา const generics ถูก implement อย่างสมบูรณ์แล้ว และไม่ใช่อุปสรรคอีกต่อไป
  • gccrs ไม่ได้ต้องการสร้าง superset ของ Rust หรือภาษา “GNU Rust” แยกต่างหาก
    • เป้าหมายคือการทำซ้ำผลลัพธ์ bug และพฤติกรรมเฉพาะของ rustc
    • เพื่อสิ่งนี้จึงใช้ทั้ง Rust test suite และ GCC test suite

จุดที่ติดขัดในการคอมไพล์ไลบรารีมาตรฐาน

  • ไลบรารีมาตรฐานของ Rust ประกอบด้วย crate หลายตัว
  • gccrs กำลังทำงานเพื่อรองรับการคอมไพล์ crate สำคัญที่สุดสองตัว คือ core และ alloc
    • core implement ฟีเจอร์พื้นฐานของไลบรารีมาตรฐาน เช่น primitive type และ macro
    • alloc จัดการการ allocate หน่วยความจำ heap และ container type หลายชนิด
  • ขณะนี้ gccrs ยังไม่สามารถคอมไพล์ crate เหล่านี้ได้ เพราะยังขาดฟีเจอร์ต่อไปนี้
    • พฤติกรรมการ resolve ชื่อ macro ยังไม่ถูกต้อง
    • การรองรับ decorator macro ยังไม่สมบูรณ์
    • ไม่มี borrow checker จึงไม่สามารถตรวจสอบความปลอดภัยของโค้ดได้อย่างเหมาะสม
    • ต้อง implement compiler intrinsic ของ LLVM ที่ไม่มีใน GCC
  • การไม่มี borrow checker ไม่ได้ทำให้คอมไพล์ไม่ได้โดยตรง แต่ทำให้ไม่สามารถตรวจสอบความปลอดภัยของโค้ด Rust ได้อย่างเหมาะสม

Procedural macro และงานผสานรวมกับ GCC

  • ในงาน GNU Tools Cauldron เดือนกันยายน 2023 Pierre-Emmanuel Patry บรรยายโดยเน้นสถานะการรวมเข้ากับ GCC 14 และงานเกี่ยวกับ macro
  • วิธี implement procedural macro ต้องมีการเปลี่ยนแปลงระบบ build ของ GCC
  • procedural macro เป็น macro แบบฟังก์ชันที่ส่งออก token stream ไม่ใช่ source text แบบง่าย ๆ เหมือน macro ของ C หรือ C++
  • ใน Rust implement ผ่าน crate ในตัวชื่อ proc_macro
  • procedural macro implement ยาก แต่เปิดทางให้ฟีเจอร์ที่ทรงพลัง
    • decorator แบบ #[attribute]
    • decorator แบบ #[derive()]
    • การสร้าง domain-specific language จากการประเมินผล ณ เวลา compile
  • ตามการบรรยายที่ GNU Cauldron ตอนนั้น gccrs มี commit มากกว่า 800 รายการที่ต้อง upstream เข้า GCC

เหตุผลที่ต้องการนำ ecosystem ของ GCC มาใช้กับ Rust

  • หนึ่งในแรงจูงใจหลักของ gccrs คือการนำ plugin ด้านความปลอดภัย ของ GCC มาใช้กับโค้ด Rust ด้วย
  • GCC มี plugin หลากหลายที่ช่วยด้าน debugging, static analysis และ hardening โดย plugin เหล่านี้ทำงานบน intermediate representation ของ GCC
  • gccrs ต้องการรองรับ workflow ที่นักพัฒนา Rust สามารถนำ plugin ของ GCC ที่มีอยู่กลับมาใช้ได้
  • Cohen ยกตัวอย่างว่าโปรแกรมเมอร์ C ทำผิดพลาดเรื่องไม่ปิด file descriptor มานาน จึงมี plugin จำนวนมากที่ช่วยจับปัญหานี้
  • เป้าหมายคือทำให้สามารถใช้ plugin และ static analyzer ของ GCC ที่มีอยู่ในการจับ bug ในโค้ด unsafe ของ Rust ได้

พื้นที่ที่มีการใช้งานแล้วบางส่วน

  • Cohen ระบุว่า community homebrew ของ Sega Dreamcast กำลังใช้ gccrs เพื่อสร้างเกมใหม่สำหรับคอนโซล Dreamcast
  • เหตุผลที่ community Dreamcast สนใจคือ LLVM backend ของ rustc ไม่รองรับสถาปัตยกรรม Hitachi SH-4 ของคอนโซล แต่ GCC รองรับ
  • แม้ gccrs ยังไม่สมบูรณ์ แต่ก็ช่วยได้ใน use case แบบ embedded เหล่านี้
  • การทำ static analysis กับโค้ด Rust แบบ unsafe โดยใช้ plugin ของ GCC ก็ทำได้แล้ว
  • ระหว่างการทำงานบน gccrs มีการเผยให้เห็นฟีเจอร์ของภาษาที่ยังระบุสเปกไม่เพียงพอ เช่น Deref และการ resolve ชื่อ macro และโครงการก็มีส่วนช่วยเพิ่มสเปกของ Rust ได้ด้วย
    • ปัจจุบัน Rust ยังไม่มีสเปกอย่างเป็นทางการ แต่มีงานจัดทำสเปกกำลังดำเนินอยู่ตาม RFC 3355

ฟีเจอร์หลักที่ยังอยู่ระหว่างพัฒนา

  • gccrs ยังขาดฟีเจอร์แกนหลักของคอมไพเลอร์ Rust อีกจำนวนมาก
  • ฟีเจอร์หลักที่ยังไม่ได้ implement หรือกำลังพัฒนาอยู่มีดังนี้
    • async/await
    • LLVM intrinsic ที่ไม่มีใน GCC
    • macro format_args!() ที่ macro สำหรับ output อย่าง println!() ใช้งาน
    • borrow checker ที่บังคับใช้กฎ reference ของ Rust
  • ทางออกที่มีแนวโน้มมากสำหรับ borrow checker คือโครงการแยกชื่อ Polonius
  • Cohen กล่าวว่ามีความเป็นไปได้สูงที่ gccrs จะผสานรวม Polonius ในอีกไม่กี่เดือนข้างหน้า
  • Jakub Dupak ทำความคืบหน้าในงานนี้ในช่วงไม่กี่เดือนล่าสุด
  • Polonius เป็นไลบรารีที่ implement borrow checker ซึ่งเทียบเท่าในเชิงความหมายกับ borrow checker ของ rustc ในปัจจุบัน
    • ใช้อัลกอริทึมอีกแบบในการคำนวณ lifetime ของ reference
    • ในระยะยาวมีเป้าหมายเพื่อแก้ข้อจำกัดและ corner case ของ borrow checker ปัจจุบันใน rustc
    • เมื่อ mature แล้ว rustc ก็มีโอกาสนำ Polonius มาใช้ในอนาคต

เหตุผลที่ต้องมี format_args!()

  • ตามรายงานประจำเดือนพฤศจิกายน 2023 ของ gccrs งานเกี่ยวกับ macro format_args!() ได้เริ่มขึ้นแล้ว
  • format_args!() เป็น macro ช่วยที่สร้าง argument เพื่อส่งต่อให้ macro สำหรับ string formatting
  • ฟีเจอร์นี้เกี่ยวข้องกับ trait Display และ Debug
  • จำเป็นสำหรับการเตรียม argument ที่จะส่งให้ macro อย่าง format!() และ println!()
  • หากไม่มี format_args!() โปรแกรม Rust จะสร้าง output ที่จัดรูปแบบแล้วไม่ได้
  • ดังนั้นจึงเป็นฟีเจอร์ที่จำเป็นแม้ก่อนที่ gccrs จะคอมไพล์โปรแกรม “Hello, World” ได้
  • มีการกล่าวถึงบทความบล็อกของ Mara Bos เพื่ออธิบายเชิงลึกเกี่ยวกับ format_args!() ด้วย

ความแตกต่างจาก rustc_codegen_gcc

  • rustc_codegen_gcc เป็นโครงการ Rust บน GCC อีกโครงการหนึ่งที่ต่างจาก gccrs
  • mature กว่า gccrs แต่ scope จำกัดกว่า
  • ไม่ใช่วิธี implement คอมไพเลอร์ Rust ทั้งหมดตั้งแต่ต้น
  • ใช้ไลบรารี libgccjit เพื่อเชื่อมกับ LLVM backend API ของ rustc
  • งาน compile หลายส่วนดำเนินการโดย rustc และใช้ GCC ในขั้นตอนหลังจากนั้น
  • แม้ชื่อ libgccjit จะมีคำว่า JIT แต่ rustc_codegen_gcc มีเป้าหมายสำหรับการ compile แบบ ahead-of-time
  • เป้าหมายหลักคือทำให้สามารถสร้างโค้ด Rust บนแพลตฟอร์มที่ LLVM ไม่รองรับได้
  • ณ เดือนตุลาคม 2023 rustc_codegen_gcc สามารถคอมไพล์ Rust for Linux ได้โดยไม่ต้องมี patch เพิ่มเติม
  • ในช่วงหนึ่งปีที่ผ่านมาได้เพิ่มการรองรับ SIMD และ link-time optimization
    • ทั้งสองฟีเจอร์เคยถูกชี้ว่าเป็นสาเหตุของ test failure
  • Cohen แนะนำหลายครั้งในการบรรยายที่ EuroRust ว่าในระยะนี้ควรใช้ rustc_codegen_gcc แทน gccrs
  • rustc_codegen_gcc ถูกรวมเข้า upstream repository ของ Rust แล้ว

Rust for Linux และช่องว่างของเวอร์ชัน

  • Rust for Linux เป็น initiative ที่ต้องการเพิ่มการรองรับ Rust ให้กับ Linux kernel
  • Cohen ยก Linux kernel เป็นแรงจูงใจหลักของโครงการ gccrs
    • เพราะผู้เกี่ยวข้องกับ kernel จำนวนมากต้องการให้ kernel สามารถ compile ได้ด้วย GNU toolchain เพียงอย่างเดียว
  • ปัจจุบันโครงการ Rust for Linux ระบุวิธี build โค้ด Rust ของ kernel ด้วย rustc หรือ rustc_codegen_gcc ไว้ในเอกสาร
  • kernel ยังมีเอกสารเวอร์ชันขั้นต่ำที่รองรับของเครื่องมือ build หลายชนิดด้วย
    • rustc ไม่ได้ถูกมองเป็นเวอร์ชันขั้นต่ำ แต่เป็นเวอร์ชันที่ต้องตรงกันพอดี
    • เวอร์ชัน rustc ที่รองรับในปัจจุบันคือ 1.73.0 ซึ่งออกในเดือนตุลาคม 2023
  • ระหว่าง Rust 1.49 ที่ gccrs ตั้งเป้าไว้ กับ Rust 1.73.0 ที่ Rust for Linux ต้องการ มีช่องว่างขนาดใหญ่
  • การรองรับ Rust for Linux เป็นเป้าหมายที่ระบุไว้ของ gccrs แต่ด้วยช่องว่างด้านเวอร์ชันนี้จึงยังค่อนข้างห่างไกล

ภาพรวมการประเมิน

  • repository ของ gccrs มี commit มากกว่า 3,000 รายการนับตั้งแต่วันที่ 1 มกราคม 2023
  • ในช่วงหนึ่งปีที่ผ่านมา โครงการมีความคืบหน้าอย่างมาก
  • อย่างไรก็ตาม ขอบเขตของการ implement คอมไพเลอร์ Rust แบบเต็มรูปแบบตั้งแต่ต้นนั้นใหญ่มาก ทำให้สำหรับการใช้งานจริงแทบทุกกรณี ยังไม่อยู่ในสถานะที่ใช้งานได้
  • rustc_codegen_gcc ถูกรวมเข้า upstream repository ของ Rust แล้ว และถูกใช้งานจริงใน Rust for Linux
  • ภาษา Rust ยังไปไม่ถึงขั้นที่มี implementation คอมไพเลอร์อิสระหลายตัว แต่กำลังเข้าใกล้ทิศทางนั้นมากขึ้น

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

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

 
GN⁺ 2023-12-19
ความคิดเห็นบน Hacker News

  • จากข้ออ้างในบทความเพียงอย่างเดียว แรงจูงใจของ gccrs ดูค่อนข้างอ่อน
    ปลั๊กอินความปลอดภัยของ GCC หรือความชอบใช้ GNU toolchain ฝั่งเคอร์เนล Linux อธิบายได้ว่าทำไมถึงอยากใช้ GCC เป็นแบ็กเอนด์ แต่ไม่ได้อธิบายว่าทำไมจึงต้องมี ฟรอนต์เอนด์ซ้ำอีกตัว
    ไม่อยากให้ Rust ทำพลาดซ้ำแบบ C++ ที่การพัฒนาข้ามแพลตฟอร์มยากขึ้นเพราะสวิตช์ของคอมไพเลอร์หลายเจ้า ระดับการรองรับภาษาแตกต่างกัน และบั๊กเฉพาะแพลตฟอร์ม
    ดังนั้นคงดีถ้าช่วยอธิบายว่า gccrs เป็นแนวทางที่ดีกว่า rustc_codegen_gcc อย่างไร เพราะอย่างหลังดูเหมือนบรรลุเป้าหมายเดียวกันได้ด้วยความพยายามและความเสี่ยงที่น้อยกว่ามาก

    • การมี implementation ของ Rust เพิ่มอีกหนึ่งตัวสามารถช่วยตรวจสอบสเปกของ Rust และทำหน้าที่เป็นการ audit เพื่อลด undefined behavior ได้
      ถ้าเจอบั๊กของคอมไพเลอร์ใน MSVC ก็รายงานแล้วสลับไปใช้ GCC เพื่อทำงานต่อได้ แต่ใน Rust ตอนนี้ยังไม่มีตัวเลือกแบบนั้น
    • Rust กำลังเรียนรู้จากความผิดพลาดของ C++ อยู่แล้ว
      อย่างที่อ้างไว้ การระวังไม่ให้กลายเป็น superset ของ Rust ก็เป็นตัวอย่างหนึ่ง
      ปัญหาของ C/C++ เกิดจากผู้ผลิตคอมไพเลอร์แข่งขันกันว่าใคร “ดีกว่า” และฟรอนต์เอนด์หลายตัวโดยทั่วไปมีข้อดีตรงที่ช่วยเปิดเผยบั๊กและ implementation ที่ผิดพลาดจำนวนมาก
    • ไม่เข้าใจว่าทำไมคำถามแบบนี้ถึงถูกถามซ้ำ ๆ
      Rust ไม่ได้ศักดิ์สิทธิ์ในความหมายใดจนห้าม เขียนฟรอนต์เอนด์ใหม่ และการ bootstrap Rust บนสถาปัตยกรรมใหม่ก็ยังเจ็บปวดอยู่
      สถาปัตยกรรมที่ LLVM ไม่รองรับก็ไม่มีคอมไพเลอร์ Rust ที่ใช้งานได้
      codegen_rust_gcc ก็มีปัญหา bootstrap แบบเดียวกับคอมไพเลอร์ Rust เดิม และต้องใส่การรองรับสถาปัตยกรรมลงในหลายส่วนของ Rust ซึ่งผู้ดูแล Rust ก็ไม่ค่อยอยากทำ
      ดังนั้นถ้าในอนาคตอันใกล้มีคอมไพเลอร์ Rust ที่ใช้ได้ทันที ทำให้แม้แต่สถาปัตยกรรมอย่าง Alpha ก็สามารถ build ไลบรารีที่ถูกเขียนใหม่เป็น Rust ได้อีกครั้งโดยไม่เจ็บปวดมาก ก็น่ายินดีมาก
    • ถ้าใช้ตรรกะนั้น ก็ต้องถามว่าทำไมชุมชน LLVM ไม่ใช้ DragonEgg ต่อไป แต่ไปสร้าง Clang, Clang++, libc++ และอื่น ๆ
      ทั้งที่มี GCC, G++, libstdc++, EDG C++ front-end อยู่แล้ว
      GCC, Clang, MSVC และคอมไพเลอร์อื่น ๆ เติมเต็มกัน รับผิดชอบเป้าหมายและตลาดที่ต่างกัน และช่วยให้ภาษามีความแข็งแกร่งตามสเปก ไม่ใช่ตามคุณลักษณะบังเอิญของ implementation เดียว
      ทั้ง GNU Toolchain Project, LLVM Project และโปรเจกต์ Rust ต่างก็เคยเจอปัญหามาแล้ว ดังนั้นการไม่พึ่งพาจุดล้มเหลวเดียวจึงดีกว่า และ redundancy กับ antifragility คือมิตรของเรา
    • การที่ Rust ควรเรียนรู้จากความผิดพลาดของ C++ และ C หมายถึงให้เรียนรู้จากความผิดพลาดของภาษาที่ดำรงอยู่ยาวนานที่สุด มีอิทธิพลสูงสุด และถูกเผยแพร่ใช้งานกว้างที่สุดในประวัติศาสตร์หรือเปล่า
      เป็นเรื่องชวนสับสนที่มองมาตรฐานภาษาในแง่ร้าย และชอบพูดว่า “โค้ดนี้ทำงานกับไบนารี/ซอร์สของ rustc ที่มีแฮช SHA256 e49d560cd008344edf745b8052ef714b07595808898c835f17f962a10012f964” มากกว่าจะพูดว่า “โค้ดนี้คือ C99/C++11”

  • Rust จำเป็นต้องมี มาตรฐานภาษา
    https://blog.m-ou.se/rust-standard/
    https://rust-lang.github.io/rfcs/3355-rust-spec.html
    https://github.com/rust-lang/rfcs/pull/3355
    มีองค์กรและอุตสาหกรรมจำนวนมากที่จะไม่รับ Rust ไปใช้จนกว่าจะมีมาตรฐาน
    C, C++, C# แม้กระทั่ง JavaScript(ECMAScript) ก็มีมาตรฐานภาษา ไม่มีเหตุผลที่ Rust ไม่ควรมี
    C: https://www.iso.org/standard/74528.html
    C++: https://isocpp.org/std/the-standard
    C#: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
    JavaScript / ECMAScript: https://ecma-international.org/publications-and-standards/st...

    • RFC นั้นได้รับอนุมัติไปแล้ว และในทางปฏิบัติก็เริ่มเดินหน้าแล้ว
      ความคืบหน้าอาจช้าจนน่าผิดหวัง แต่โปรเจกต์ยังมีชีวิตอยู่ และมีโอกาสจะเร่งความเร็วขึ้นในปีหน้า
      https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...
    • บล็อกโพสต์ของ Mara หรือก็คือลิงก์แรก ค่อนข้างไปในทางว่า Rust มีวิธีเพิ่มฟีเจอร์และรักษาความเข้ากันได้อยู่แล้ว จึงโดยพื้นฐานแล้ว ไม่จำเป็นต้องมีมาตรฐาน
    • ด้วย สเปก Ferrocene อุตสาหกรรมเหล่านั้นก็สามารถใช้ Rust ได้
    • Go มีสเปกที่ทำได้ดีจริง ๆ และมี implementation หลายตัว
      https://go.dev/ref/spec
    • เพื่อตอบโต้คำกล่าวที่ว่ามีองค์กรและอุตสาหกรรมจำนวนมากจะไม่รับไปใช้หากไม่มีมาตรฐาน: Rust ก็ยังไปได้ดีแม้ไม่มีองค์กรและอุตสาหกรรมเหล่านั้น
      ไม่เห็นว่าทำไมต้องเปลี่ยนวิธีที่กำลังทำงานได้ดีอยู่

  • น่าแปลกใจที่มีปฏิกิริยาเชิงลบต่อ GCC-RS เยอะมาก
    ผมมองว่าถ้าภาษาหนึ่งไม่มี หลาย implementation ก็ถือว่าเป็นภาษาที่ค่อนข้างดูด้อย

    • เมื่อก่อนสิ่งนี้เคยเป็นความเข้าใจทั่วไป โดยเฉพาะเพราะ C/C++ แต่ทุกวันนี้เป็นประเด็นที่ถกเถียงกันมากขึ้นมาก
      ฉันทามติของชุมชน Rust คือแนวทางปัจจุบัน—มีคอมไพเลอร์เดียวที่โดยนิยามแล้วเป็นมาตรฐาน, มีเอกสารจำนวนมาก, มีสเปกขั้นต่ำสำหรับอุตสาหกรรมที่ต้องการความปลอดภัย, และมีสเปกของส่วนย่อยบางโมดูล—ให้ข้อดีส่วนใหญ่ของการมีหลาย implementation พร้อมหลีกเลี่ยงข้อเสียได้
    • ในระยะยาว ปัญหาคือ ความเสถียรของไวยากรณ์ และการป้องกันไม่ให้ฟีเจอร์บวมจาก extension/attribute
      ใน C เราเจอเรื่องนี้จริง ๆ อยู่แล้ว ส่วน C++ แทบเกินเยียวยาไปแล้วเพราะความซับซ้อนที่ไร้สาระและประหลาด
      ถ้าไม่มีสิ่งนี้ ก็ยากที่จะเกิด implementation ทางเลือกที่ใช้งานได้จริง
    • ส่วนตัวเข้าใจคุณค่าของการมีหลาย implementation แต่ปัญหาคือมันสร้างอยู่บน GCC
      GNU toolchain เป็นอะไรที่ยุ่งเหยิง และผมไม่รู้จริง ๆ ว่าคนเขาพัฒนาบนมันกันอย่างไร
      ไม่ใช่ประเด็นเชิงอุดมการณ์ แต่หมายถึงตามตัวอักษรเลยว่าผมไม่เข้าใจว่าจะตั้งสภาพแวดล้อมพัฒนา GCC เองอย่างไร
      เคยโชคร้ายต้อง bootstrap มันอยู่สองสามครั้ง และมันเป็นซอฟต์แวร์ที่ทำงานแย่ที่สุดเท่าที่เคยเห็นมา

  • ชอบตรงที่คอมมูนิตี้โฮมบรูว์ของ Sega Dreamcast ใช้ gccrs สร้างเกมใหม่ได้ และใช้ GCC plugin ทำ static analysis กับโค้ด unsafe Rust ได้
    สถาปัตยกรรม Hitachi SH-4 ของ Dreamcast ไม่ได้รับการรองรับโดย LLVM backend ของ rustc แต่ GCC รองรับ ดังนั้นแม้ gccrs ยังไม่สมบูรณ์ ก็ยังมีประโยชน์กับ การใช้งานแบบ embedded แบบนี้

    • ตรงนี้อาจทำให้เข้าใจผิดเล็กน้อย
      สำหรับเรื่องนี้ไม่ได้ต้องการ GCC frontend แค่มี GCC backend ก็พอ

  • ต่อไปคงได้เห็นการรองรับ Rust บนสถาปัตยกรรมอย่าง Alpha, SuperH, VAX ที่ LLVM ไม่รองรับแต่ GCC รองรับ

    • รวมถึง mips64 ด้วย ซึ่ง rustc เพิ่งเลิกรองรับหลังพยายามดึงเงิน/ทรัพยากรสนับสนุนจาก Loongson แต่ไม่สำเร็จ
      https://github.com/rust-lang/compiler-team/issues/648
      ปัญหาใหญ่ที่สุดของวิธีคิดแบบ LLVM คือการใช้การรองรับสถาปัตยกรรมเป็นเครื่องมือดึงการสนับสนุนจากบริษัทฮาร์ดแวร์ หรือก็คือตำแหน่งนักพัฒนาที่มีค่าจ้าง
      GNU อาจมีเกณฑ์การ merge การเปลี่ยนแปลงที่สูงจนน่ารำคาญ แต่เมื่อเข้าไปและได้รับการรองรับแล้ว ก็จะดูแลต่อในระยะยาว
      เหมือนความต่างระหว่างการซื้อกับการเช่า การใส่การรองรับเข้า GCC ใช้เวลาพัฒนามากกว่ามาก แต่พอเข้าไปแล้วมันก็ยังอยู่
    • แม้แต่สถาปัตยกรรมที่รองรับอยู่แล้ว ก็น่าจะมี ตัวเลือกการคอนฟิก เพิ่มขึ้น
      เช่น เมื่อไม่นานมานี้เพิ่งรู้ว่าใน RISC-V นั้น GCC รองรับ target RV32E แต่ LLVM ไม่รองรับ
    • อยากเห็น machine code ของ PDP-11 ที่ออกมาจาก Rust เร็ว ๆ
      ครั้งล่าสุดที่ตรวจดู ใน GCC การคอมไพล์ C แบบ standalone ยังใช้งานได้อยู่

  • จากประสบการณ์ ผมมองว่าการที่ gccrs ไม่สร้างภาษาเฉพาะชื่อ “GNU Rust” แต่พยายามทำซ้ำ output ของ rustc รวมถึงบั๊กและลักษณะประหลาด ๆ ด้วย เป็นความผิดพลาดครั้งใหญ่
    Rust ไม่มีสเปก มีเอกสารอ้างอิงก็จริง แต่ระบุชัดว่าไม่ใช่ข้อกำหนดเชิงบรรทัดฐาน
    ภาษาที่ไม่มีเอกสารกำกับนอกเหนือจาก reference implementation เดียว มีจุดอ่อนในระยะยาว
    เป้าหมายที่จะรับประกันว่าโค้ดเดิมทำงานได้กับทั้งสอง implementation นั้นสมเหตุสมผล แต่ถ้าถึงขั้นสัญญาเรื่อง bug compatibility ก็จะทำให้การตัดสินใจผิด ๆ และบั๊กกลายเป็นฟอสซิล
    Microsoft ใช้คนจำนวนมากเพื่อให้โปรแกรมเก่ายังรันต่อได้ ขณะเดียวกันก็แก้บั๊กด้านความปลอดภัยและความน่าเชื่อถือ แต่ Rust ไม่จำเป็นต้องแบกรับภาระแบบนั้นตั้งแต่ช่วงต้นอายุของภาษา
    ถ้าอยากให้ภาษาวิวัฒนาการ ก็ต้องยอมรับการประกันคุณภาพและการควบคุมคุณภาพ
    คุณภาพไม่สามารถฉีดเติมทีหลังด้วยการทดสอบได้ แต่ต้องทำให้มันทำงานถูกต้องผ่านสถาปัตยกรรมและการออกแบบ รวมถึงกระบวนการอย่างการรีวิวดีไซน์และโค้ด และแม้จะล้มเหลวก็ต้องล้มเหลวไปในทิศทางที่ถูกต้อง
    มาตรฐานที่แข็งแรงอย่าง Common Lisp, C++, FORTRAN ยอมรับความเชื่อนี้ ส่วนภาษาที่อ่อนกว่าแต่แทบเป็นมาตรฐานโดยพฤตินัยอย่าง Python ก็อาจได้รับความนิยมได้ แต่ความยากในการเปลี่ยนแปลงเห็นได้จากการย้ายผ่านอันยาวนานจาก Python 2 ไป 3 และจำนวน implementation ที่น้อย

    • ถ้าพบบั๊กใหญ่ ก็น่าจะรายงาน upstream แล้วเปลี่ยนทั้งสอง implementation ได้

  • มาตอบช้าในช่วงท้ายของเธรดนี้ แต่เรื่องนี้อาจไม่ใช่เรื่องดีเสมอไป
    ดิสโทรตามภาษาใหม่ ๆ ที่ออกเวอร์ชันทุกไม่กี่เดือนไม่ทันอยู่แล้ว ทำให้ตอนนี้ใช้ rustc หรือ Go จากแพ็กเกจของดิสโทรได้ยาก
    ตอนนี้มีระบบที่น่าประหลาดใจคือไม่ต้องใช้ GCC แล้วจึงลบทิ้ง และคงไว้แค่ Go กับ Rust จาก upstream เพื่ออัปเดตซอฟต์แวร์เดิม
    เมื่อไม่กี่เดือนก่อน ตอนอัปเดต Go เพราะ CVE ผมเห็นว่าแอปที่เขียนด้วย Go เก็บสภาพแวดล้อม Go ของตัวเองไว้ถึงสี่ที่ ฝันร้ายชัด ๆ

  • ถ้าต้องการ Linux ก็สามารถคอมไพล์ด้วย Clang ได้อยู่แล้ว และใช้ toolchain ที่อิง LLVM ทั้งหมดได้
    ความพยายามซ้ำซ้อน ในการพัฒนาและบำรุงรักษาสิ่งนี้เพื่อ “ความบริสุทธิ์” แบบ GNU ดูไม่คุ้มค่า

    • ไม่ใช่เรื่องความบริสุทธิ์ แต่เป็นเรื่องของ ทางเลือก
      ชุมชน ClangBuiltLinux เคยโต้แย้งว่า Linux ไม่ควรพึ่งคอมไพเลอร์เดียว แต่พอ Rust เข้ามา คนกลุ่มเดียวกันจำนวนไม่น้อยกลับเริ่มมองว่าคอมไพเลอร์เดียวก็โอเค
    • ดูเหมือนตรงนี้มีความเข้าใจผิด
      ไม่ได้จะผูก kernel ไว้กับ GNU เท่านั้น แค่ต้องการให้สามารถเลือกใช้ GNU toolchain ล้วน ได้เท่านั้น