การที่ Ubuntu ใช้ Rust หมายความว่าอย่างไร?

• การ นำ Rust มาใช้ ของ Ubuntu แสดงให้เห็นว่า Rust กำลัง ก้าวจากกลุ่มผู้ใช้ยุคแรก ข้าม chasm ไปสู่กระแสหลัก ในวงจรการยอมรับเทคโนโลยี
• Canonical รับ Rust เป็น ภาษาหลักสำหรับซอฟต์แวร์โครงฐานตัวใหม่ เพื่อทดแทนการใช้ C, C++ และ Python บางส่วน พร้อมทั้งลงทุนทั้งด้านงบประมาณและชื่อเสียงในการพัฒนา utility ที่ปลอดภัยด้านหน่วยความจำ
• ผู้ใช้กลุ่ม Early Majority ต้องการ "มาตรฐานอุตสาหกรรม" และความเข้ากันได้กับ workflow เดิม ดังนั้นการเปลี่ยน utility แบบ drop-in จึงเป็นกลยุทธ์สำคัญในการข้าม chasm
• ประเด็นเรื่อง การขยาย standard library ของ Rust ถูกหยิบยกขึ้นมาอีกครั้ง และมีการประเมินใหม่ว่าแนวคิด "Rust Platform" ที่เคยถูกปฏิเสธในปี 2016 อาจเหมาะกับกลุ่ม Early Majority มากกว่า
• โครงสร้างที่เปลี่ยนการยอมรับไปเป็นการลงทุน และความครอบคลุมที่ตั้งอยู่บน ความเข้าอกเข้าใจ (empathy) ของชุมชนโอเพนซอร์ส เป็นสิ่งจำเป็นต่อการเติบโตในระยะถัดไปของ Rust

---

การ 'ข้าม chasm' ของ Rust แตกต่างกันไปในแต่ละด้าน

• การที่ Rust ข้าม chasm ใน Technology Adoption Life Cycle ได้หรือไม่นั้น แตกต่างกันไปตามแต่ละด้าน
• ภายใน Amazon นั้น Rust ได้ปักหลักอย่างมั่นคงในการสร้าง data plane ขนาดใหญ่หรือเอเจนต์ที่รับรู้ทรัพยากร แต่สำหรับงานพัฒนาทั่วไปยังมีมุมมองว่าเกินความจำเป็น
• ในด้าน Safety Critical Software มีกรณีความสำเร็จอยู่บ้าง แต่โดยรวมอุตสาหกรรมส่วนใหญ่ยังคงอยู่ในโหมด "รอดูไปก่อน"

ความสำคัญของ "ลูกค้าอ้างอิง"

• หัวใจสำคัญของการข้าม chasm คือการมี ลูกค้าอ้างอิง (reference customers)
• ผู้ใช้งานยุคแรกซื้อสิ่งที่เป็น "ตัวขับเคลื่อนการเปลี่ยนแปลง (change agent)" แต่ กลุ่ม Early Majority ต้องการเพิ่มผลิตภาพของการดำเนินงานเดิม และพยายามลดความไม่ต่อเนื่องให้น้อยที่สุด
• การได้เห็นองค์กรที่คล้ายกับตนประสบความสำเร็จ เป็นปัจจัยที่โน้มน้าวที่สุดในการนำเทคโนโลยีใหม่มาใช้
• ความสำเร็จของทีม S3 กับ Rust นั้นโน้มน้าวทีมบริการขนาดใหญ่ได้ แต่สำหรับ ทีมบริการ CRUD กลับโน้มน้าวโดยตรงได้ไม่มาก นี่คือตัวอย่างหนึ่ง

กลยุทธ์การนำ Rust มาใช้ของ Ubuntu (Canonical)

• ในงาน Rust Nation นั้น Canonical VP of Engineering Jon Seager ได้บรรยายคีย์โน้ตหัวข้อ "Rust Adoption At Scale with Ubuntu"
• ก่อนหน้านี้ Canonical จำกัดภาษาที่ใช้พัฒนาเองไว้ที่ Python, C/C++ และ Go แต่ล่าสุดได้เพิ่ม Rust และรับให้เป็น ภาษาหลักสำหรับงานโครงฐานใหม่
• คล้ายกับคีย์โน้ตของ Lars Bergstrom เรื่องการนำ Rust มาใช้ภายใน Google ซึ่งเป็นแนวทางที่ มีทั้งวิสัยทัศน์และความเป็นรูปธรรม
  • นี่คือคุณลักษณะที่จำเป็นอย่างแม่นยำสำหรับการเปลี่ยนผ่านจากผู้ใช้ยุคแรกไปสู่กลุ่ม Early Majority

การลงทุนใน utility ที่ปลอดภัยด้านหน่วยความจำ

• Jon Seager กล่าวถึงว่า Ubuntu ควรสนับสนุน การสร้าง utility ที่ตั้งอยู่บนความปลอดภัยของหน่วยความจำ ในลักษณะของการ "pay it forward"
• Canonical กำลังสนับสนุนเงินทุนให้กับการพัฒนา sudo-rs, ntpd-rs ของ Trifecta Tech Foundation และงาน coreutils ของ uutils
• เป็นโครงสร้างที่ Ubuntu ทดลองและตรวจสอบสิ่งใหม่ก่อน แล้วเปิดโอกาสให้ดิสโทรอื่นได้รับประโยชน์ตามมา
• utility แบบ drop-in ที่เข้าแทนใน workflow เดิมได้ทันที สอดคล้องกับความต้องการของกลุ่ม Early Majority ที่ต้องการ "ลดความไม่ต่อเนื่องให้น้อยที่สุด"

ความต้องการของผู้ใช้กลุ่มใหม่: การขยาย standard library

• ระหว่างงานเลี้ยงอาหารค่ำ Jon Seager กล่าวว่าควร ทบทวนนโยบาย standard library ขนาดเล็ก ของ Rust
• นี่เป็นข้อเรียกร้องที่ถูกพูดซ้ำมาหลายปี และไม่ได้หมายถึงแค่การทำ standard library ให้ใหญ่ขึ้น แต่กำลังวางแนวทางทางเลือกในรูปโปรเจ็กต์ชื่อ "Battery Packs"
• แนวคิด Rust Platform ที่เสนอในปี 2016 (แนวคิดการยอมรับ crate บางตัวเป็น standard library แบบขยาย) เคยถูกปฏิเสธโดยผู้ใช้งานยุคแรกในเวลานั้น แต่ตอนนี้มีการประเมินใหม่ว่าอาจเหมาะกับกลุ่ม Early Majority
  • ในเวลานั้นความเห็นส่วนใหญ่คือแค่เพิ่ม dependency ลงใน Cargo.toml ก็เพียงพอแล้ว

ความจำเป็นของการเปลี่ยนแปลงเพื่อการเติบโต

• หากต้องการเปลี่ยนจากผู้ใช้ยุคแรกไปสู่กลุ่ม Early Majority จำเป็นต้องสื่อสารว่า Rust คือ "มาตรฐานอุตสาหกรรม (industry standard)" ไม่ใช่ "ล้ำสมัยที่สุด (state-of-the-art)"
• Rust ประสบความสำเร็จในการสร้างการรับรู้ในอุตสาหกรรมแล้ว และจากนี้ต้องเป็นตัวเลือกที่ดีที่สุดโดยยึดจาก "สิ่งที่มันเป็นจริง ๆ" ไม่ใช่ "สิ่งที่มันอาจเป็นได้"
  • สองสิ่งนี้บางครั้งอาจอยู่ในความตึงเครียดต่อกัน
• การทำการตลาดกับกลุ่มนักปฏิบัตินิยมต้องอาศัยความอดทน ความเข้าใจประเด็นของอุตสาหกรรมนั้น ๆ และการเข้าร่วมคอนเฟอเรนซ์ในอุตสาหกรรม

โครงสร้างที่เปลี่ยนการยอมรับไปเป็นการลงทุน

• การขยายการนำ Rust มาใช้ ย่อมมาพร้อมกับ ความต้องการที่เพิ่มขึ้น ต่อโปรเจ็กต์และ ecosystem ของ Rust
• สำหรับองค์กรโอเพนซอร์สอย่าง Canonical สิ่งที่สำคัญกว่า $$ คือ การสร้างความสัมพันธ์ระหว่างองค์กรและการมีส่วนร่วม
  • ช่วงแรกนักพัฒนา Rust for Linux ได้รับความช่วยเหลือจาก maintainer ของ Rust แต่ต่อมาก็ค่อย ๆ แก้บั๊กได้ด้วยตนเอง และ maintainer เปลี่ยนไปมีบทบาทเป็นพี่เลี้ยง
• แนวโน้มที่น่าสนใจคือ เงินทุนมักมาจาก บริษัทที่กำลังพิจารณานำ Rust มาใช้ มากกว่าบริษัทที่ใช้อยู่แล้ว
  • ผู้ใช้งานยุคแรกภายในองค์กรจะผลักดันการนำมาใช้ในระดับองค์กร และจัดสรรงบประมาณให้กับการพัฒนาฟีเจอร์แบบ "table stakes"
• ตามข้อมูลของ Alexandru Radovici จาก Rust Foundation Silver Member Directory มี บริษัทด้านซอฟต์แวร์ที่ต้องการความปลอดภัยสูง จำนวนมากที่มีงบเพื่ออุดช่องว่างของ Rust แต่ยังไม่รู้ว่าจะใช้อย่างไร

บทบาทของโอเพนซอร์สและความสำคัญของความเข้าอกเข้าใจ

• โอเพนซอร์สเป็นแพลตฟอร์มที่ยอดเยี่ยมสำหรับการข้าม chasm แต่ พวกพ้อง (cliques) และ "ธรรมเนียมบอกเล่า (oral traditions)" อาจกลายเป็นอุปสรรคต่อการเข้ามามีส่วนร่วม
• การใช้คำศัพท์ไม่ถูกต้องแล้วถูกปฏิเสธไอเดีย หรือการตอบกลับอย่างหยาบคายเพียงครั้งเดียว อาจทำให้ผู้ร่วมพัฒนาใหม่ตัดสินใจจากไป
• สิ่งที่จำเป็นที่สุดต่อการเติบโตระยะถัดไปของ Rust คือ ความเข้าอกเข้าใจในโอเพนซอร์ส (Empathy in Open Source)
• หัวใจสำคัญคือการเข้าไปยังจุดที่ Rust สามารถช่วยผู้คนได้ แล้ว สนับสนุนและเสริมพลังให้พวกเขา

[GN⁺]

ความคิดเห็นจาก Hacker News

• การที่ Ubuntu ใช้ userland ที่ไม่ได้ใช้ไลเซนส์ GPL หมายความว่าอาจเปิดทางให้มี TiVoization ในระบบนิเวศลินุกซ์มากขึ้น
  หากรวมกับทิศทางที่ Amutable ฝั่ง systemd กำลังผลักดัน ก็อาจได้เห็น ดิสโทรลินุกซ์แบบปิดที่ผู้ใช้แก้ไขไม่ได้
  จากมุมมององค์กร สภาพแวดล้อมแบบปิดที่ตรวจสอบลายเซ็นได้ครบถ้วนก็ดูน่าสนใจ โลกที่แม้แต่ “ls” หรือ “cd” ยังกลายเป็นซอร์สปิด ฟังดูเหมือนบรรยากาศวันสิ้นโลกแบบแปลก ๆ

  • ไม่ใช่ว่า util-linux หรือ BSD จะหายไป ถ้าไม่ชอบ Ubuntu ก็ไม่ต้องใช้ Debian เสถียรกว่ามากอยู่แล้ว
  • ที่จริงมันมีเหตุผลที่เคยเรียกว่า GNU/Linux ส่วน Android/Linux ก็ไม่ได้ใช้ GPL userland และคู่แข่งสาย embedded ส่วนใหญ่ก็ไม่ใช้ GPL เหมือนกัน สุดท้ายแล้ว Linux ก็เป็นแค่เคอร์เนล
  • มองในเชิงประวัติศาสตร์ ผมอาจจะมองโลกสวยไปหน่อย แต่ก็ไม่คิดว่าการเปลี่ยนแปลงแบบนี้จะแย่เสมอไป ผมยังชอบยูทิลิตีโอเพนซอร์สมากกว่า แต่การมี ทางเลือกแบบปิดที่ทำตามสเปก ก็ไม่ใช่เรื่องเสียหาย องค์กรอาจเลือกทำแบบนั้นแล้วนำเงินกลับมาสนับสนุนโปรเจกต์โอเพนซอร์สมากขึ้นก็ได้
  • พูดตรง ๆ Ubuntu เหมือน Apple แห่งโลก Linux ที่แข่งด้วยการตลาดมากกว่าคุณภาพ ตระกูล Debian ถูกใช้เพราะต้นทุนดูแลรักษาต่ำ ส่วนตัวผมมองว่า Fedora หรือ OpenSUSE คืออนาคต
  • ถ้าการเปลี่ยนแปลงแบบนี้ทำให้ผู้ใช้ลินุกซ์ 95% ใช้ OS เดียวกันได้ มันก็อาจไม่ใช่เรื่องเลวร้ายนัก

• ช่องว่าง (chasm) ที่แท้จริง ที่ Rust ต้องข้ามให้ได้คือ การรองรับ dynamic linking ที่มี ABI ปลอดภัย
  ต้องสามารถแก้ไลบรารีหนึ่งตัวได้โดยยังคงความปลอดภัยไว้ และต้องมีเสถียรภาพของ ABI ระดับเดียวกับ C ถึงจะทำให้ฝั่ง C/C++ หันมารับ Rust ได้

  • Rust สื่อสารผ่าน C ABI ได้อยู่แล้ว และมีความสามารถด้าน dynamic linking ในระดับเดียวกับ C++
  • ความเสถียรของ ABI ใน C++ เป็นตัวการสำคัญที่ฉุดรั้งการพัฒนาภาษา เปลี่ยน layout ของคลาสใน STL ก็ไม่ได้ เทมเพลตที่ถูกใส่ไว้ใน header ก็ปรับแต่งทีหลังได้ยาก Rust ไม่ควรรองรับ “stable ABI” แบบนี้
  • ประสิทธิภาพของ Rust พึ่งพา การ monomorphization ตอนคอมไพล์ หากจะสร้าง ABI ก็ต้องคำนึงถึงการทำ specialization ตอนลิงก์ด้วย มันไม่ใช่แค่ย้ายการสร้างโค้ดไปไว้ที่ linker แต่ต้องจัดการ “shape” ของพารามิเตอร์ฟังก์ชันอย่างระมัดระวัง
  • dynamic linking ยังช่วย ลดเวลาในการคอมไพล์ ใน debug build ได้ด้วย ไลบรารีที่ไม่เปลี่ยนไม่จำเป็นต้อง build ใหม่ และ overhead ตอนรันก็แทบไม่มีนัยสำคัญ
  • น่าเสียดายที่ชุมชน Rust มักชอบ MIT มากกว่า GPL ทั้งที่ GPL เป็นมิตรกับผู้ใช้ ส่วน MIT เป็นมิตรกับองค์กร ผมคิดว่าขบวนการ “Rewrite-it-in-Rust” สนใจแค่การขยายการใช้ภาษา มากกว่าการปกป้องผู้ใช้

• ปัญหาใหญ่กว่าเรื่องที่ Ubuntu นำ Rust มาใช้ คือมันยังคงใช้ สคริปต์ curl|bash กับบิลด์สำคัญอยู่
  ดูได้ชัดจาก snapcraft.yaml ของ firefox-snap

  • พอพูดถึง “curl|bash” คนมักนึกถึงการแก้ค่าคอนฟิกมั่ว ๆ หรือไปยุ่งกับ .bashrc แต่ในกรณีนี้มันแค่รัน สคริปต์ติดตั้ง toolchain แบบ static เท่านั้น เป็นวิธีแบบยุค 90 แต่ก็ค่อนข้างปลอดภัยกว่า
  • มีดิสโทรจำนวนมากที่ใช้ Rust เวอร์ชันเก่าเกินไป Rust ใน Debian หรือ Ubuntu LTS ล้าสมัยมาก เลยดูเหมือนพวกเขาจะไม่ชอบ static linking
  • ต่อให้รันอะไรผ่าน curl ถ้า ตรวจสอบ hash ดี ๆ ก็ถือว่าโอเค

• ผมติดใจตรงที่โปรเจกต์ Rust Coreutils ใช้ ไลเซนส์ MIT
  แม้บางครั้งจะมีคนวิจารณ์แนวคิดของ FSF แต่ GPL ปกป้องโอเพนซอร์ส ถ้า Canonical เปลี่ยน Ubuntu ทั้งระบบไปเป็น MIT จะเกิดอะไรขึ้นก็ไม่รู้

  • แต่ก่อน GPL เคยทรงพลังมาก แต่ตอนนี้ด้วย ระบบฟอกลิขสิทธิ์อัตโนมัติ ทำให้โค้ดจำนวนมากถูกแปลงเป็น MIT/BSD หรือโค้ดเชิงพาณิชย์ได้อยู่ดี FSF เองก็ไม่มีทางแก้
  • การถกเรื่องไลเซนส์ไม่มีวันจบ GPL จำกัดการนำไปใช้ แต่ MIT ยืดหยุ่นกว่า สุดท้ายก็ขึ้นอยู่กับว่า เป้าหมายคืออะไร — อยากได้ OSS ที่ทุกคนใช้ได้ หรืออยากกันไม่ให้องค์กรเอาไปหากำไรโดยไม่ต้องมีส่วนร่วม
  • ผมสงสัยว่าการที่ Coreutils เป็น MIT จะเปิดช่องให้ทำ “เรื่องแย่ ๆ” อะไรได้อย่างเป็นรูปธรรมบ้าง

• rust-coreutils เคยทำให้ ติดตั้ง CUDA Toolkit ไม่ได้ ประเด็นนี้มีอยู่ใน ฟอรัม NVIDIA

  • เธรดที่ลิงก์ไว้น่าจะเป็นปัญหาเกี่ยวกับ gzip มากกว่า ไม่น่าใช่เพราะ dd
  • พูดตรง ๆ rust-coreutils ไม่มีเหตุผลให้มีอยู่เลย หลังติดตั้ง Ubuntu สิ่งแรกที่ควรทำคือ ติดตั้ง coreutils ตัวจริงกับ sudo ใหม่

• แนวคิดเรื่อง “Crossing the chasm” น่าสนใจ นอกจากกรณี coreutils ของ Ubuntu แล้ว Rust ยังมีช่องว่างอีกหลายจุดที่พยายามจะข้าม
  มีทั้ง Rust for Linux และ Rust สำหรับอุตสาหกรรมยานยนต์ แต่ตอนนี้ก็ดูเหมือนยังอยู่แค่ระดับไดรเวอร์

  • Rust กำลังขยายตัวไปหลายทิศทาง เช่น pyo3 (ใช้แทนโมดูล Python), Dioxus (เว็บเฟรมเวิร์กคล้าย React), Ferrocine (คอมไพเลอร์สำหรับงานยานยนต์) และโปรเจกต์ DARPA TRACTOR ก็ช่วยเร่งการนำ Rust ไปใช้ด้วย
  • หากดูเอกสาร Project Goals ของ Rust (ลิงก์) ก็จะเห็นทิศทางที่ชุมชนกำลังลงทุนอย่างจริงจัง
  • ตัว Rust เองยอดเยี่ยม แต่ปัญหาคือบางส่วนของชุมชนเอาแต่ “เขียนของเดิมใหม่ด้วย Rust” ในลักษณะ ฉกแบรนด์ ของซอฟต์แวร์ที่เสถียรอยู่แล้ว Ubuntu เองก็ดูเหมือนกำลังตกอยู่ในกับดัก การส่งสัญญาณเชิงคุณธรรม (virtue signaling) แบบนั้น

• ตรรกะที่บอกว่าค่อยไปเปลี่ยน standard library ทีหลังเป็นแนวคิดที่อันตราย ผู้ใช้ต้องการ ระบบที่เสถียรและมีคุณภาพสูง มากกว่า “ช่องว่าง” ต่าง ๆ

  • สำหรับ Rust นั้น ไม่ใช่การ “เปลี่ยน” stdlib แต่เป็นการ เพิ่มเข้าไป ซึ่งทำได้ง่าย ทุก 6 สัปดาห์จะมีรีลีสใหม่ และแต่ละครั้งก็เพิ่มฟีเจอร์เกิน 10 อย่าง ตอนนี้มีฟีเจอร์หลายร้อยรายการอยู่ใน stdlib แล้ว

• ความยังไม่สุกงอม ของ ecosystem Rust เป็นปัจจัยที่ขัดขวางการยอมรับ crate จำนวนมากยังไม่ถึงเวอร์ชัน 1.0 หรือเป็นแค่ wrapper ของ C แบบง่าย ๆ ด้านคริปโตถือว่าโอเค แต่ของอย่าง SAML หาได้ยาก

  • เวอร์ชัน pre-1.0 ไม่ได้น่ากังวลขนาดนั้น เพราะมีวัฒนธรรม ยึด SemVer อย่างเคร่งครัด หลายโปรเจกต์จึงเลื่อนการประกาศ 1.0 ออกไป crate อย่าง libc ที่ผูกกับ API ลึกมากก็ขึ้นเวอร์ชันได้ยากเหมือนกัน ส่วนตัวผมอ้างอิงลิสต์แบบ คัดสรรมาแล้ว อย่าง blessed.rs
  • gettext ก็เพิ่งได้ 1.0 หลังผ่านไป 30 ปี
  • โมดูล cryptography ของ Python ต้องใช้ Rust toolchain ทำให้ ติดตั้งในสภาพแวดล้อม Termux ไม่ได้ มันน่าหงุดหงิดที่แม้แต่โปรเจกต์ Python ก็หนักขึ้นเพราะต้องพึ่ง Rust

• มีความพยายามจะ “แปลตามฟีล (vibe-translate)” โค้ด C++ เป็น Rust แล้ว เปลี่ยนไลเซนส์ ไปพร้อมกัน ตัวอย่างเช่น sudo-rs กลับมี สถิติด้านความปลอดภัยแย่กว่า เวอร์ชัน C เสียอีก

  • กระแสโหมว่า Rust, AI, และความปลอดภัย เป็นเหมือน โฆษณาชวนเชื่อ (propaganda) มากเกินไป ตอนแรกผมชอบ Rust มาก แต่ประเด็นเรื่องไลเซนส์ MIT และการโปรโมตเกินจริงเริ่มทำให้รู้สึกล้า

• standard library ขนาดใหญ่ ของ .NET น่าใช้งานมาก งานส่วนใหญ่ทำได้ตามแนวทางมาตรฐาน และถ้ามี implementation แปลก ๆ คนส่วนมากก็มักผลักดันให้มันกลายเป็นมาตรฐาน

  • ผมคิดว่า stdlib ที่เล็ก ของ Rust เป็นความผิดพลาด เพราะ stdlib คือ dependency เดียวที่มีอยู่เสมอ ต่อให้ไม่สมบูรณ์แบบ ก็ควรมีเครื่องมือให้มากกว่านี้
  • แต่มองจากฝั่งโปรแกรมเมอร์ระบบ stdlib ใหญ่ก็เป็นปัญหาได้เช่นกัน .NET ใช้ GC จึงไม่ค่อยมีปัญหา แต่ Rust หรือ C++ ต้องไปรันใน สภาพแวดล้อม bare metal ได้ด้วย stdlib ขนาดใหญ่เป็นภาระในสภาพแวดล้อมหน่วยความจำจำกัด (<64K)
    std/core ของ Rust เองก็ใหญ่เกินไปสำหรับไมโครคอนโทรลเลอร์อยู่แล้ว จนต้องใช้ลูกเล่นอย่าง weak symbol
    stdlib ที่เล็กช่วยเรื่อง การรักษาเสถียรภาพของ API และลดภาระการบำรุงรักษา ได้มาก C++ เจอปัญหานี้มาแล้ว ดังนั้น Rust ควรระมัดระวัง