ฟีเจอร์ใหม่ของภาษา Rust สำหรับการพัฒนาเคอร์เนล Linux

 (lwn.net)
13 คะแนน โดย GN⁺ 2025-10-17 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • โปรเจกต์ Rust for Linux กำลังผลักดัน ฟีเจอร์ภาษาหลักที่จำเป็นต่อการพัฒนาเคอร์เนล พร้อมทั้งมีส่วนช่วยต่อยอดตัวภาษา Rust เอง
  • หัวใจสำคัญมี 3 อย่างคือ Field Projection, In-place Initialization และ Arbitrary Self Types
  • ฟีเจอร์เหล่านี้ช่วยให้สามารถเขียน โครงสร้างเฉพาะของเคอร์เนล เช่น smart pointer, หน่วยความจำแบบตรึงตำแหน่ง (Pin), RCU ใน Rust ได้อย่างเป็นธรรมชาติมากขึ้น
  • ทีม Rust ให้ความสำคัญกับความมั่นคงของการออกแบบ จึงพัฒนาอย่างค่อนข้างช้า แต่เพราะมี เป้าหมายที่ชัดเจนอย่าง Linux kernel ทำให้โฟกัสการพัฒนาสูงขึ้น
  • การเปลี่ยนแปลงนี้จะส่งผลต่อ ecosystem ของ Rust นอกเหนือจากเคอร์เนลด้วย และคาดว่าจะช่วยมากในเรื่อง การจัดการ smart pointer และการทำโค้ดให้เรียบง่ายขึ้น

การปรับปรุงภาษา Rust และบทบาทของ Linux kernel

  • สาเหตุที่การพัฒนาฟีเจอร์ใหม่ของภาษา Rust ค่อนข้างช้า มาจาก ความระมัดระวังเพื่อไม่ให้การออกแบบที่ไม่ดีถูกตรึงไว้ในภาษา และปัญหาเรื่อง "alignment in attention"
    • โปรเจกต์ Rust ดำเนินงานโดยอาศัยอาสาสมัครเป็นหลัก ดังนั้นหากไม่มีคนที่โฟกัสกับฟีเจอร์ใดโดยเฉพาะ การพัฒนาก็จะล่าช้า
  • โปรเจกต์ Rust for Linux เป็นหัวข้อที่หลายคนให้ความสนใจอย่างมาก จึงช่วยให้ สามารถรวมแรงไปที่ฟีเจอร์หลักบางอย่างที่เคอร์เนลต้องการ ได้
  • Tyler Mandry ผู้ร่วมเป็นผู้นำทีมภาษา Rust กล่าวในงาน Kangrejos 2025 ถึงฟีเจอร์ภาษาที่กำลังจะมาถึง พร้อมระบุว่าโปรเจกต์ Linux kernel ทำหน้าที่เป็น ตัวเร่ง ให้กับพัฒนาการของ Rust
    • ฟีเจอร์หลักได้แก่ Field Projection, In-place Initialization, Arbitrary Self Types
    • การพัฒนาเคอร์เนลช่วยชี้ให้เห็น กรณีใช้งานจริงและข้อกำหนดทางเทคนิค อย่างชัดเจน ทำให้ทิศทางการออกแบบภาษาของ Rust เป็นรูปธรรมมากขึ้น
    • ลำดับความสำคัญสูงสุดตอนนี้คือการทำให้ ฟีเจอร์ unstable ที่ถูกใช้ใน kernel bindings อยู่แล้ว กลายเป็นมาตรฐาน

Field Projection

  • เป็นความสามารถในการดึงพอยน์เตอร์ของฟิลด์เฉพาะออกมาจากพอยน์เตอร์ของ struct โดยเป็นความพยายามที่จะทำให้รูปแบบ C ของ &(r->field) ใช้งานใน Rust ได้อย่างทั่วไป
  • เดิมทีทำได้เฉพาะกับ reference (&) และ pointer (*mut) เท่านั้น แต่ยังมีข้อจำกัดเมื่อใช้กับ smart pointer ที่ผู้ใช้กำหนดเอง
  • Rust for Linux กำลังผลักดันให้ขยายสิ่งนี้ เพื่อให้ เข้าถึงฟิลด์ด้วยไวยากรณ์เดียวกันได้กับพอยน์เตอร์ทุกชนิด
  • โดยเฉพาะเมื่อจัดการกับชนิด Pin (struct ที่ห้ามย้ายตำแหน่ง) ระบบจะออกแบบให้ตอนทำ field projection สามารถแปลงเป็น Pin<&mut Field> หรือ &mut Field ได้โดยอัตโนมัติ
  • หากฟีเจอร์นี้ถูกนำมาใช้ จะช่วยให้รองรับแพตเทิร์น RCU (Read-Copy-Update) ใน Rust ได้อย่างปลอดภัย ทำให้เข้าถึงข้อมูลประสิทธิภาพสูงได้โดยไม่ต้องใช้ lock
  • ขณะนี้กำลังมีการหารือใน tracking issue บน GitHub และตั้งเป้าให้เสถียรก่อน Debian 14 (2027)

Arbitrary Self Types

  • เป็นฟีเจอร์ที่ทำให้ สามารถนิยามเมธอดที่รองรับ smart pointer ได้
  • เดิมรองรับเพียงรูปแบบ fn method(&self) แต่ตอนนี้จะสามารถใช้รูปแบบอย่าง fn method(self: Pin<&mut MyStruct>) ได้ด้วย
  • ในเคอร์เนลมีการใช้ตัวครอบพอยน์เตอร์หลายแบบ เช่น Arc, Pin, Mutex จึงเป็นฟีเจอร์ที่จำเป็น
  • ระหว่างการพัฒนามีปัญหาเรื่อง ชนกับ trait Deref แต่กำลังแก้ด้วยการเพิ่ม trait Receiver แบบใหม่
  • Receiver มีหน้าที่ระบุว่าพอยน์เตอร์ใดสามารถใช้เป็น arbitrary self type ได้
  • สำหรับการพัฒนาเคอร์เนล ฟีเจอร์นี้ช่วยให้ การเรียกผ่านสายโซ่ของพอยน์เตอร์ ยังคงกระชับอ่านง่าย
  • Ding กำลังใช้เครื่องมือ Crater เพื่อตรวจสอบความเข้ากันได้กับแพ็กเกจ Rust ที่มีอยู่ และระบุว่ามีโอกาสทำให้เสถียรได้ภายใน 1 ปี

In-place Initialization

  • เป็นฟีเจอร์ที่จะรองรับ pin_init!() macro ที่ใช้อยู่ในเคอร์เนลในระดับภาษา
  • เป็นความสามารถในการ กำหนดค่าเริ่มต้นให้วัตถุโดยตรงในหน่วยความจำโดยไม่ต้องย้ายหลังสร้างเสร็จ ซึ่งมีประโยชน์กับ struct แบบ Pin, Future, dyn trait เป็นต้น
  • ขณะนี้มีข้อเสนอ 3 แนวทางที่กำลังพิจารณาควบคู่กัน
    • แนวทางคีย์เวิร์ด init: เพิ่มไวยากรณ์น้อยที่สุดและใช้ trait PinInit ที่มีอยู่เดิม
    • แนวทาง reference แบบ &out: เพิ่ม reference สำหรับเขียนอย่างเดียวคล้าย out pointer ใน C และรองรับการกำหนดค่าเริ่มต้นระดับฟิลด์
    • แนวทางออปติไมซ์แบบ C++: หากวัตถุจะถูกย้ายไป heap ทันที ก็สร้างบน heap โดยตรงตั้งแต่แรก
  • แผนสุดท้ายคือจะ ทดลองทั้งแนวทาง PinInit และ out-reference เพื่อพิสูจน์การใช้งานจริง
  • หากฟีเจอร์นี้ถูกนำมาใช้ คาดว่าจะช่วย ทำให้โครงสร้างของโค้ด Rust ฝั่ง asynchronous เรียบง่ายขึ้นโดยรวม ไม่ใช่แค่ในเคอร์เนล

อิทธิพลของ Rust for Linux ต่อ Rust

  • Linux kernel กำลังทำหน้าที่เป็น สนามทดสอบที่สมจริง สำหรับการพัฒนาภาษา Rust
  • แม้ทั้ง 3 ฟีเจอร์จะเริ่มต้นจากความต้องการเฉพาะของเคอร์เนล เช่น smart pointer, หน่วยความจำแบบตรึงตำแหน่ง, โครงสร้างด้าน concurrency แต่ท้ายที่สุดนักพัฒนา Rust ทั่วไปก็จะได้รับประโยชน์ด้วย
  • การเปลี่ยนแปลงเหล่านี้ถูกมองว่าเป็นตัวอย่างของ วงจรเสริมแรงเชิงบวก ระหว่างการพัฒนาเคอร์เนลกับการพัฒนาภาษา

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

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

 
GN⁺ 2025-10-17
ความคิดเห็นจาก Hacker News

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

    • จากประสบการณ์ของผม C++ ซับซ้อนกว่า rust มาก เช่น แค่รูปแบบการ initialisation ก็มีตั้ง 8 แบบ ประเภทของ value ก็มีถึง 5 แบบอย่าง xvalues ทั้งเรื่อง formatting และ naming convention ก็ไม่สม่ำเสมอ ไหนจะ rule of 5, exception handling, เวลาทำ move assignment ก็ต้องเช็ก this != other ตลอด, perfect forwarding, SFINAE, ปัญหาเรื่องตัวแทนของ trait และจุดซับซ้อนอื่น ๆ อีกมาก ถ้าจะใช้ C++ ให้ถูกต้องก็ต้องเรียนรู้ convention ที่กองทับอยู่บนมาตรฐานเพื่อให้เขียนโค้ดได้ปลอดภัยและเร็วไปพร้อมกัน และหลายอย่างอย่าง exception handling ก็ชนกันเองหมด หรือไม่ก็ต้องเลือกแนวทางที่ไม่ค่อยเหมาะนัก

    • ในชุมชน rust บรรยากาศต่อข้อเสนอ lightweight clones เริ่มเป็นลบมากขึ้นเรื่อย ๆ เพราะมันซับซ้อนเกินไป เอกสารทางการของ rust เกี่ยวกับทิศทางการออกแบบ ก็ระบุว่าความซับซ้อนเป็นอุปสรรคใหญ่ที่สุด แม้ว่าฟีเจอร์ที่ถูกเสนอใน rust ไม่จำเป็นต้องเรียบง่ายเสมอไป แต่ lightweight clone แค่ทำให้สิ่งที่ทำได้อยู่แล้วง่ายขึ้นนิดหน่อยเท่านั้น และถ้าคนเข้าใจมันได้ยาก นั่นก็เป็นปัญหา

    • rust ดูยิ่งใหญ่มหาศาลเมื่อมองจากไกล ๆ แต่พอเขียนจริงกลับชินได้เร็ว ตัวอย่างเช่น ตอนแรกผมไม่เข้าใจแนวคิด lifetime เลย ก็เลยเขียนโดยใช้แค่ Rc<> พอได้พื้นฐานแล้วกลับไปเรียน lifetime ใหม่ก็เข้าใจง่ายขึ้นมาก จริง ๆ แล้วผู้ใช้ส่วนใหญ่แทบไม่ต้องสนใจฟีเจอร์อย่าง lightweight clones เลยด้วยซ้ำ

    • ถ้าเทียบกับ C มันซับซ้อนกว่ามาก แต่ถ้าเทียบกับ C++ มันง่ายกว่ามาก แทบไม่ถึงขั้นต้องไปคุ้ยเอกสารหรือหนังสืออ้างอิงเพื่อทำความเข้าใจโค้ด rust อยู่ในจุดที่พอดีมาก คือ "ไม่ซับซ้อนจนปวดหัว แต่ก็ไม่ง่ายจนโค้ดกลายเป็นยุ่งเหยิง" แถมโดยพื้นฐานแล้วโค้ดก็มี correctness มาด้วย

    • ความซับซ้อนของ rust ไม่เหมือน C++ ตรงที่โอกาสใช้ผิดแบบไม่ตั้งใจมีน้อยกว่า และถ้าใช้ clippy ก็จะช่วยแปลงเป็นโค้ดที่ idiomatic มากขึ้นให้อัตโนมัติ ดังนั้นแม้จะไม่รู้จักฟีเจอร์ใหม่อย่าง lightweight clones โดยตรงก็ยังถูกแนะนำได้ ส่วนใหญ่แค่ใช้ตัวเลือก --fix ของ clippy ก็เอามาใช้ได้ง่าย นี่เป็นจุดที่ต่างจาก c++ อย่างชัดเจน เพราะ c++ มักมีผลข้างเคียงคือฟีเจอร์ที่ไม่ได้ใช้สะสมขึ้นเรื่อย ๆ หรือไม่ก็ถูกใช้แบบซับซ้อนเกินจำเป็น ทำให้ความซับซ้อนพอกพูนต่อไป

  • เห็นมีคนบอกว่าโครงการ Rust for Linux ช่วย rust ได้มาก ผมเลยลองหาไฟล์ "*.rs" ใน kernel tree ด้วยความอยากรู้ ดูแล้วพบว่ามีเลเยอร์ความเข้ากันได้ของ API อยู่ใต้โฟลเดอร์ rust และใน kernel tree ก็มีแค่ไดรเวอร์ proof of concept บางตัวที่เป็นการ rewrite ไดรเวอร์เดิมแบบตรง ๆ เท่านั้น (ยกเว้นไดรเวอร์ nvidia ที่ยังไม่เสร็จ) ดูเหมือนแทบยังไม่มีอะไรที่ถูกใช้งานจริง การ rewrite android binder เป็น rust ก็ดูเหมือนแทบจะค้างอยู่เฉย ๆ ความรู้สึกโดยรวมคือมันเหมือนโครงการทดลองเล็ก ๆ น่ารัก ๆ และก็อดสงสัยไม่ได้ว่าจำเป็นด้วยหรือที่จะทำการทดลองร่วมพัฒนาภาษาแบบนี้ใน source tree ของซอฟต์แวร์ที่สำคัญที่สุดในโลก ผมกลับคิดว่าทำใน OS ที่เน้นการทดลองมากกว่าอย่าง redox น่าจะเหมาะกว่า

    • ไดรเวอร์ GPU สำหรับ Apple silicon เขียนด้วย rust และผู้เขียนเองก็บอกว่าถ้าพัฒนาเป็น C จะยากกว่านี้มาก แม้ยังไม่ได้ upstream แต่เขากล่าวไว้ว่า "เวลาเขียนไดรเวอร์เคอร์เนลที่ซับซ้อนขึ้นมาใหม่ มักจะเจอปัญหาสารพัดอย่าง race condition, memory leak, use-after-free ฯลฯ แต่พอเขียนด้วย rust ปัญหาเหล่านั้นแทบไม่มีเลยและทำงานได้เสถียรมาก ฟีเจอร์ด้านความปลอดภัยทำให้มั่นใจได้ว่าไดรเวอร์นี้ทั้ง thread-safe และ memory-safe และตัวการออกแบบเองก็ไหลไปในทิศทางที่ดีอย่างเป็นธรรมชาติ ผมคิดว่านี่คือเวทมนตร์ของ rust" ลิงก์ประสบการณ์ของผู้เขียน และสำหรับคำถามว่าควรทำการทดลองแบบนี้ใน kernel tree หรือไม่ ก็มีการกล่าวว่า Torvalds ไม่เห็นด้วยกับข้อกังวลนั้น

    • ความเห็นที่ว่า "การ rewrite android binder เป็น rust เหลือแค่ค้างอยู่เฉย ๆ" ไม่เป็นความจริง โครงการนี้มีแผนจะมาแทนที่ implementation ภาษา C อย่างสมบูรณ์ บทความที่เกี่ยวข้อง ไดรเวอร์หลักสำหรับฮาร์ดแวร์ Apple ตระกูล M ก็เขียนด้วย rust เช่นกัน และไม่ใช่แค่การ rewrite แบบตรง ๆ หรือ proof of concept

    • ถ้าจะสร้างไดรเวอร์ที่ซับซ้อน ก็ต้องมีชั้น interface ก่อน โครงการ RfL กำลังทำงานเพิ่มชั้นโครงสร้างพื้นฐานแบบนั้นเข้าไปใน upstream และเมื่อฐานเหล่านี้สะสมมากพอ จึงจะเขียนไดรเวอร์ที่ซับซ้อนได้ Redhat กำลังทำ nova, asahi กำลังทำ Apple GPU, collabora กำลังทำสำหรับ ARM Mali ถ้ายังจะบอกว่าไดรเวอร์ GPU ทั้งสามตัวนี้ไม่ใช่ไดรเวอร์ที่ซับซ้อน ก็ไม่รู้แล้วว่าอะไรถึงจะเรียกว่าซับซ้อน

    • สำหรับข้ออ้างที่ว่าการ rewrite binder เป็น rust ยังแค่ค้างอยู่เฉย ๆ หากดูจากข้อความ commit ใน Linus tree จะเห็นว่าสถานะของมันสมบูรณ์มาก Rust binder ผ่านการทดสอบ binder ของ Android Open Source Project ทั้งหมดแล้ว และแอปกับฟีเจอร์ต่าง ๆ ก็ทำงานได้โดยแทบไม่มีปัญหา บนทั้งอีมูเลเตอร์ cuttlefish และ Pixel 6 Pro ก็สามารถบูตและรันแอปได้ปกติ ตอนนี้ฟังก์ชันการทำงานก็เทียบเท่า C binder แล้ว เหลือเพียงฟีเจอร์ด้านดีบักบางส่วนที่กำลังจะถูกเพิ่มเข้ามา อีกทั้งโครงการ rust for linux เดิมก็เริ่มนอก kernel tree แต่สุดท้ายถ้าจะทดลองการรวมเข้าจริง ก็ต้องทดลองภายใน tree อยู่ดี

    • เป้าหมายของโครงการนี้ไม่ใช่การทดลองร่วมพัฒนาภาษา แต่คือการใช้ rust ในการพัฒนา linux kernel เป็นจุดประสงค์หลัก นักพัฒนาหลักเป็นคนเริ่มโครงการนี้เองเพราะอยากใช้ rust เนื่องจากมันเป็นซอฟต์แวร์ที่สำคัญมาก จึงต้องเดินอย่างระมัดระวังและใช้เวลาสร้างพื้นฐานพอสมควร ส่วนที่ rust ได้ประโยชน์ตามมาจากโครงการนี้ก็เป็นเพียงผลพลอยได้

  • ผมเพิ่งเห็นในบทความส่วนที่พูดถึง <i>field projection ว่าตอนนี้มีการตัดสินใจแล้วว่าฟิลด์ของ struct ทุกตัวจะถูก pin แบบเชิงโครงสร้าง ทำให้ได้ชนิดอย่าง Pin<&mut Field> ออกมาเสมอ</i> ก่อนหน้านี้ผมพลาดประเด็นนี้ไป แม้จะเป็นเรื่องที่ซับซ้อนเชิงเทคนิค แต่ก็ดีใจที่การตัดสินใจนี้ช่วยคลายปัญหาที่เคยเป็นตัวถ่วงในการถกเถียงหลายครั้ง

  • ผู้คนกำลังถกเถียงกันเรื่อง <i>แบบออกแบบสุดท้ายที่ได้แรงบันดาลใจจาก C++ ซึ่งเป็นเทคนิคการคาดการณ์การปรับให้เหมาะสม โดยเมื่อสร้างค่าใหม่เพื่อเอาไปจัดสรรบน heap แล้วต้องย้ายทันที ก็จะสร้างมันขึ้นมาบน heap ตั้งแต่แรก</i> ตรงนี้ชื่อว่า 'optimization' อาจทำให้เข้าใจผิดได้ จึงมีการคุยกันเรื่องเปลี่ยนชื่อ

    • ผมอาจยังไม่เข้าใจความซับซ้อนของปัญหานี้ดีพอ แต่รู้สึกว่าแค่กำหนด calling convention ที่เหมาะสมก็น่าจะแก้ได้ง่ายไม่ใช่หรือ เช่น ถ้า struct มีขนาดเกิน x หรือมี marker type ก็ให้ caller ส่งบัฟเฟอร์มาแบบ outref แล้ว callee ก็เขียน struct ลงบัฟเฟอร์นั้นโดยตรง แบบนั้นถึงจะเขียนโค้ดทั่วไปก็ยังเลี่ยงการจัดสรรบนฮีปซ้ำซ้อนได้ และยังลดการคัดลอกที่ไม่จำเป็นในสถานการณ์อื่น ๆ ด้วย เป็นหัวข้อที่ลงทุนความพยายามกันมาเยอะแล้ว ผมเลยยิ่งสงสัยว่าทำไมวิธีแก้ที่เสนอถึงดูใช้งานยากกว่า

    • ผมคิดว่าถ้าไม่ทำฟีเจอร์นี้เป็นการ optimization ภายใน แต่ทำให้ชัดเจนเป็นฟังก์ชันอย่าง new ไปเลย จะเข้าใจตรงกันง่ายกว่าสำหรับทุกคน

    • ใน C++ semantics แบบนี้เรียกว่า elision

    • ขอเสนอชื่ออย่าง 'coalesced heap construction' หรือ 'coalesced heap allocation'

  • ทุกครั้งที่ได้ยินคนพูดถึงฟีเจอร์ต่าง ๆ ของ rust ผมก็อดปล่อยมุกไม่ได้ว่า "อย่างน้อยอย่าเอา tokio เข้าไปใส่ในเคอร์เนลก็แล้วกัน" แต่ถ้าวันหนึ่ง rust พัฒนาไปมากพอและมี direct composition renderer เกิดขึ้น จนสามารถมีแอปที่รันทั่วทั้งเคอร์เนลได้ แบบนั้นก็คงเป็นสถานการณ์ที่น่าสนใจไม่น้อย

    • การทำ async runtime ภายในเคอร์เนลนั้น trivial มาก จริง ๆ แล้ว workqueue ของ kernel เองก็เป็น runtime อยู่แล้ว

    • ถ้าไม่ได้พูดเล่น ก็แปลว่าเข้าใจโครงสร้างของการเขียนโค้ดเคอร์เนลด้วย rust (และ C) ผิดไปแบบพื้นฐานเลย เวลาเขียนในเคอร์เนล rust ก็ทำงานแบบ no_std เหมือนกัน ไม่มี C stdlib และใช้ cargo หรือ crates ไม่ได้ ถ้าจะใช้ tokio ก็ต้องเขียนมันใหม่ไปครึ่งหนึ่ง แล้วเปลี่ยนการโต้ตอบกับ OS ทั้งหมดอย่าง socket ให้เป็นแบบของเคอร์เนล

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

    • เท่าที่ผมเข้าใจ systems programming คือพื้นที่ใช้งานลำดับแรกของ rust อยู่แล้ว ไม่ว่าจะเป็น OS, embedded หรือระบบที่ซับซ้อนซึ่งอิง C โดยแก่นสำคัญคือ interoperability ฟีเจอร์รอบนี้จริง ๆ แล้วไม่ได้มีไว้เพื่อเคอร์เนลเท่านั้น แต่ดูเป็นยูทิลิตีทั่วไปที่จำเป็นสำหรับการทำ systems programming ในโลกจริง

    • มีความคืบหน้าเพื่อการพัฒนาเคอร์เนล/เฟิร์มแวร์เกิดขึ้นหลายด้านอยู่แล้ว เพียงแต่ไม่ใช่สิ่งที่ทุกคนพูดถึงกันตลอด Philipp เป็นคนหนึ่งที่ผลักดันการเปลี่ยนแปลงใหญ่ในด้านนี้โดยเฉพาะ

    • บทบาทหลักของ rust คือการเขียนโปรแกรมระบบระดับล่าง ส่วนพื้นที่อื่น ๆ ภาษาจัดการหน่วยความจำแบบ managed ที่คอมไพล์สำหรับ userspace มักเป็นตัวเลือกที่ดีกว่ามาก และในระบบที่จัดโครงสร้างแบบ Self หรือ Inferno หรือสถาปัตยกรรมแบบ Android ผมก็คิดว่าไม่เป็นปัญหาถ้าจะโฟกัสกับความสามารถสไตล์ C ระดับล่างแบบนี้

  • ฟีเจอร์เหล่านี้ยอดเยี่ยมพอที่จะช่วยได้ในด้านอื่นนอกเหนือจากเคอร์เนลด้วยเช่นกัน (โดยเฉพาะ generalized projections) ผมพอใจมากที่ Linux มีส่วนผลักดันการพัฒนาของภาษา rust

  • ผมสงสัยว่ามีงานวิจัยหรือเครื่องมือที่ใช้ LLM เพื่อแปลงโค้ด c เป็น rust แบบอัตโนมัติหรือไม่ ลองคิดดูว่าถ้าให้ LLM สร้างโค้ด rust สำหรับ chat, usb, i2c, GPU driver แล้วให้มัน build/test ได้จริงจะเป็นไปได้แค่ไหน หรืออาจลองกับโปรเจกต์ที่ 'เล็กกว่า' อย่าง sqlite, apache, nginx ได้หรือเปล่า

    • ถ้าไม่นับแนวทาง LLM ก็มีโครงการ c2rust ที่มีกรณีใช้งานจริงอยู่แล้ว LLM โดยพื้นฐานยังเป็นแค่การประมาณ จึงทำให้ถูกต้องแม่นยำไม่ได้และก่อ subtle bug เยอะมาก ถ้าไม่ผูกเข้ากับ formal method ก็ยังไม่ค่อยใช้ได้จริง หลายปัญหาก็ไม่สามารถเจอได้ด้วย unit test อย่างเดียว และตัวอย่างโปรเจกต์ที่เสนอว่า 'เล็กกว่า' นั้นจริง ๆ ก็ไม่ได้เล็กพอ ดูกรณีใช้งานจริง

    • ทาง Darpa ก็สนใจงานวิจัยลักษณะนี้และเริ่มให้ทุนแล้ว แต่ยังไม่ถึงขั้นมีผลงานออกมาชัดเจน
 
ahwjdekf 2025-10-17

การจัดแนวแบบคลั่งไคล้ (alignment in dogmatism)