Rust ในปี 2025: มุ่งสู่ซอฟต์แวร์รากฐาน

• Rust กำลังก้าวเข้าสู่ปีที่ 10 ในปีนี้ และกำลังวางตำแหน่งตัวเองเป็นภาษาหลักสำหรับการพัฒนา ซอฟต์แวร์รากฐาน (Foundational) ในอนาคต
• ซอฟต์แวร์รากฐานหมายถึง ชั้นที่เป็นฐานของทุกสิ่ง เช่น เคอร์เนลระบบปฏิบัติการ แพลตฟอร์มคลาวด์ อุปกรณ์ฝังตัว และเครื่องมือ CLI
• Rust มอบ ประสิทธิภาพและความน่าเชื่อถือ ระดับ C/C++ พร้อมทั้งลดอุปสรรคด้วยระบบชนิดข้อมูลที่รับประกันความปลอดภัยของหน่วยความจำ
• พันธกิจของ Rust ไม่ได้จำกัดอยู่แค่ในพื้นที่รากฐานเท่านั้น แต่ยังส่งอิทธิพลต่อการพัฒนาแอปพลิเคชันระดับบนผ่านโครงการอย่าง Dioxus, Tauri, Leptos
• ต่อจากนี้มีแผนลงทุนหลักในด้าน การทำงานร่วมกันระหว่างภาษา, การขยายระบบชนิดข้อมูล, การเสริมความแข็งแกร่งของ ecosystem เป็นต้น

---

วิสัยทัศน์ของ Rust: ซอฟต์แวร์รากฐาน

• วิสัยทัศน์หลักของ Rust คือการทำให้ การเขียนและดูแลรักษาซอฟต์แวร์รากฐานทำได้ง่ายขึ้น
  • ซอฟต์แวร์รากฐานครอบคลุมเคอร์เนลระบบปฏิบัติการ โครงสร้างพื้นฐานคลาวด์ อุปกรณ์ฝังตัว เครื่องมือ CLI และอื่น ๆ ที่เป็นฐานของทุกระบบ
  • ปัจจุบันถูกนำไปใช้แล้วในหลากหลายที่ เช่น Windows และ Linux kernel, เอนจินค้นหาของ VSCode อย่าง ripgrep, Deno, และตัวจัดการแพ็กเกจ Python อย่าง uv
• ซอฟต์แวร์ประเภทนี้ต้องให้ความสำคัญกับ ประสิทธิภาพ ความน่าเชื่อถือ และผลิตภาพ พร้อมกัน
  • หากชั้นฐานพัง จะส่งผลต่อชั้นบนทั้งหมด จึงต้องมีเสถียรภาพเป็นสิ่งจำเป็น
  • หากประสิทธิภาพลดลง ก็จะกลายเป็นเพดานประสิทธิภาพของชั้นบน จึงต้องมี overhead ให้น้อยที่สุด

ประสิทธิภาพ ความน่าเชื่อถือ และผลิตภาพของซอฟต์แวร์รากฐาน

• ซอฟต์แวร์รากฐานก็มีข้อกำหนดหลากหลายเช่นเดียวกับซอฟต์แวร์ทุกประเภท แต่ทุกปัจจัยล้วนสำคัญยิ่งกว่าเดิม
  • ความน่าเชื่อถือ คือภารกิจอันดับแรก หากฐานล้ม สิ่งทั้งหมดที่อยู่บนนั้นก็จะล้มตามไปด้วย
  • overhead ด้านประสิทธิภาพ เป็นตัวกำหนดขีดจำกัดของประสิทธิภาพชั้นบน จึงต้องลดให้ต่ำที่สุด
• ก่อนหน้านี้มีทางเลือกอยู่สองแบบในการตอบโจทย์ความต้องการเหล่านี้
  • C/C++ : ให้อิสระสูง แต่ก็ต้องแลกมาด้วยความสมบูรณ์แบบในการใช้งานในระดับเดียวกัน
  • ภาษา ระดับสูงอย่าง Java, Go เป็นต้น: จำเป็นต้องมีรูปแบบการเขียนโค้ดเฉพาะเพื่อรักษาประสิทธิภาพ และถูกจำกัดในการใช้ abstraction กับความสะดวกต่าง ๆ
• Rust เปลี่ยนแนวทางเดิมด้วยการผสาน zero-cost abstraction เข้ากับ ระบบชนิดข้อมูลที่รับประกันความปลอดภัยของหน่วยความจำ
• จึงกลายเป็นเครื่องมือที่ช่วยให้เขียนโค้ดระดับสูงได้อย่างปลอดภัย พร้อมบรรลุทั้งประสิทธิภาพระดับต่ำและความเสถียรของหน่วยความจำไปพร้อมกัน

ลดกำแพงการเริ่มต้นและเสริมพลังให้นักพัฒนา

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

• คำพูดของ Yehuda Katz ที่ว่า "abstraction ที่สร้างขึ้นในช่วงมีสมาธิ ช่วยเหลือตัวฉันในอนาคตยามที่อ่อนล้า" ก็สรุปประเด็นนี้ได้อย่างดี

พื้นที่นอกเหนือจากซอฟต์แวร์รากฐาน

• แม้พันธกิจของ Rust จะมุ่งไปที่ซอฟต์แวร์รากฐาน แต่ก็ไม่ได้หมายความว่าพื้นที่อื่นจะถูกมองข้าม
• โครงการอย่าง Dioxus, Tauri, Leptos กำลังใช้ Rust ขยายไปสู่แอปพลิเคชันระดับสูงอย่าง GUI และเว็บเพจ
• จุดแข็งหลักของ Rust อาจมุ่งอยู่ที่ซอฟต์แวร์รากฐานโดยธรรมชาติ แต่ความพยายามเหล่านี้ก็ไม่ควรถูกมองข้าม

เป้าหมายแบบ stretching และการเติบโต

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

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

ความสำคัญของการรองรับทั้งสแตก

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

ประสบการณ์ของการลงลึกแบบค่อยเป็นค่อยไป (Iterative Deepening)

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

แผนต่อจากนี้

• บทความนี้เป็นตอนแรกของซีรีส์ และในอีกสี่ตอนถัดไปมีแผนจะนำเสนอ ด้านการลงทุนที่จำเป็นเพื่อให้ Rust เหมาะกับซอฟต์แวร์รากฐานมากยิ่งขึ้น
  • การทำงานร่วมกันระหว่างภาษา (smooth language interop) และ ความสามารถในการขยาย (extensibility)
  • การทำให้เป้าหมายชัดเจนผ่านระบบชนิดข้อมูล (clarity of purpose)
  • การเสริม ecosystem: แนวทางปฏิบัติที่ดีขึ้น เครื่องมือที่ดีขึ้น และการใช้ประโยชน์จาก Rust Foundation
  • บทความสุดท้ายจะกล่าวถึง การดำเนินงานขององค์กรโอเพนซอร์ส Rust โดยมุ่งหาวิธีทำให้การมีส่วนร่วมและการดูแลรักษาเป็นกิจกรรมที่ เข้าถึงง่ายและสนุกที่สุดเท่าที่จะเป็นไปได้

[yeorinhieut]

ถึง Rust จะดูเหมือนใช้ได้อยู่บ้าง แต่ก็รู้สึกว่าเป็นภาษาเดียวที่ไม่ค่อยอยากแตะเพราะแฟนด้อมสายพิษ(?)

[aer0700]

คงจะดีถ้า C หรือ C++ มีตัวจัดการแพ็กเกจมาตรฐานนะครับ/ค่ะ พอเห็น Cargo ทีไรก็คิดแบบนั้นอยู่เสมอ

[cosine20]

ผักโขมอร่อยจะตายไป....

[t7vonn]

ช่วงนี้แทบไม่มีที่ไหนที่ไม่ใช้ Rust

[lostid]

ถึงจะทำงานอยู่บริษัทใหญ่พอสมควร แต่ก็ไม่มีสายงานที่ใช้ Rust เลยครับ กรุณาอย่าชี้นำเกินจริง

[t7vonn]

อย่ามาหาเรื่องนะ

[bobross0]

ว้าววววววว;;

[crawler]

อย่ามาหาเรื่องนะ shiver

[shakespeares]

โหดมาก ;;

[qwas5544]

โห;;;;

[lostid]

เอาเรื่องอื่นไว้ก่อน ทุกวันนี้พวกคลั่ง Rust ทำเอาแทบจะเป็นลมกันเลยทีเดียว ออฟไลน์นี่ก็เป็นชนกลุ่มน้อยมากๆ อยู่แล้ว แต่พอออนไลน์นี่แทบจะเป็น isis... เอ่อ คืออยากให้ไปรวมกันอยู่ที่ไหนสักแห่งแล้วเล่นกันเองมากกว่า...

[ifmkl]

หลายคนที่ทำตัวเหมือนสาวก Rust ก็ยังน่าสงสัยเลยว่าจริง ๆ แล้วตัวเองได้ใช้อย่างจริงจังแค่ไหน

[skageektp]

ถึงอย่างนั้น... ก็ยังรัก Rust ใช่ไหม?
จะเกลียดสาวก Rust ก็ได้ แต่ช่วยรัก Rust ด้วยนะ ฮือๆ

[taeunlee99]

ถึงจะโดน FFmpeg ซัดมาก็ยังจะให้เขียนโค้ดทั้งหมดด้วย rust อะไรทำนองนั้น

[GN⁺]

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

• เมื่อพูดถึงซอฟต์แวร์แกนหลัก สิ่งที่น่าเสียดายที่สุดใน Rust คือ ABI หากจะสร้าง OS ด้วย Rust และให้บริการที่หลากหลายได้ ต่อให้ OS อัปเกรดแล้ว แอปพลิเคชันก็ควรยังใช้งานได้โดยไม่ต้องคอมไพล์ไลบรารีใหม่ ฝั่ง Windows แก้ปัญหานี้ด้วย COM, Apple เคยใช้ dynamic dispatch ของ ObjC (และตอนนี้คือ Swift ABI), ส่วน Android ใช้ JVM และ bytecode แต่ Rust รองรับได้แทบแค่ extern "C" จึงมีข้อจำกัดในการใช้ dynamic library การให้ ABI โดยไม่มีชั้น VM (JVM, .NET) นั้นยากมาก และเมื่อกำหนดรายละเอียดการติดตั้งใช้งานแล้วก็แทบห้ามเปลี่ยน จึงเข้าใจได้ว่าทำไมเรื่องนี้ถึงไม่ใช่ลำดับความสำคัญสูง โมเดลแบบนี้ที่ประสบความสำเร็จจริง ๆ ก็มีประมาณ Swift กับ COM เท่านั้น ถ้า Rust มี ABI แบบสมบูรณ์ก็น่าจะเข้าใกล้ภาษาเกือบสมบูรณ์แบบมาก (และถ้าจัดการ dependency ในรูปแบบไบนารี เวลาคอมไพล์ก็จะลดลงมากด้วย)

  • มีคำอธิบายว่าที่ Rust ตั้งใจจะมี ABI stability แบบเลือกใช้ (opt-in) เป็นหลัก ก็เพราะมุ่งไปที่ zero-cost abstraction โดย ABI ที่เสถียรย่อมมาพร้อมการลดทอนประสิทธิภาพ ซึ่งกรณีของ C++ ก็เป็นหลักฐานประกอบได้ (คำอธิบายเกี่ยวกับ C++ ABI) ถ้าต้องการโหลดปลั๊กอิน Rust ด้วยกันแบบไดนามิก (dlopen) ก็มีเครื่องมืออย่าง stabby และ abi_stable ซึ่งใช้งานได้ค่อนข้างดี ส่วนการทำงานร่วมกันข้ามภาษาในภาพกว้างกว่าเดิม crABI(ข้อเสนอ crABI) อาจเป็นทางเลือกในอนาคต อย่างไรก็ตาม นี่ไม่ใช่ปัญหาที่ Rust แก้ได้ลำพัง แต่ต้องอาศัยแรงสนับสนุนและความร่วมมือจากหลายชุมชน ทั้งภาษาอื่นและ Linux distribution ต่าง ๆ อีกทั้ง Rust เป็นภาษาที่ให้เลือกวิธี I/O และการจัดสรรหน่วยความจำอย่างชัดเจน จึงอาจไม่เหมาะกับโครงสร้างแบบ Swift ที่แก้ทุกอย่างด้วย shared library เพียงอย่างเดียว
  • ตอนนี้ก็มีความพยายามจะแก้ปัญหาเกือบเดียวกันด้วย Wasm Components ถ้า WebAssembly คือฟอร์แมตคำสั่งที่พกพาได้ WebAssembly Components ก็คือฟอร์แมตการรัน/ลิงก์ที่พกพาได้ แม้จะไม่ง่ายถึงขั้น repr(wasm)/extern "wasm" แต่ก็ใช้งานได้ไม่ยากนักผ่าน wit-bindgen หรือ target wasm32-wasip2 วิดีโอแนะนำ Wasm Components
  • มีการตั้งข้อสงสัยว่านี่จำเป็นจริงหรือไม่ แน่นอนว่าถ้าส่ง 'สิ่งต่าง ๆ' ที่หลากหลายกว่าเดิม (เช่น slices, trait objects เป็นต้น) ผ่านอินเทอร์เฟซได้ก็จะสะดวกขึ้น แต่ในทางปฏิบัติ extern "C" ABI อย่างเดียวก็ทำสิ่งที่จำเป็นได้ครบอยู่แล้ว และก็เคยเห็นข้อเสนอให้ขยาย extern ABI ให้รองรับชนิดมากขึ้นด้วย
  • เคยเห็นงานพูดในงานประชุม Rust เรื่องนี้ โดยอ้างอิงแนวทางของ Swift ค่อนข้างมาก จึงคาดว่าอนาคตน่าจะพัฒนาไปในทางนั้น
  • ที่จริงของแบบนั้นมีอยู่แล้ว ชื่อว่า 'C'

• ชอบ Rust มากจริง ๆ แต่ก็อยากให้มีคนสนใจปัญหาเรื้อรังที่ชวนหงุดหงิดอีกหลายเรื่องมากขึ้น

  • 1. มีปัญหาเรื่อง self-referencing struct เช่น อยากเก็บ source file และ AST ที่ parse แล้วไว้ใน struct เดียวกัน ปัจจุบันทำได้ไม่ง่าย ถ้ามีอะไรอย่าง offset reference ก็น่าจะดี
  • 2. orphan rule (กฎ orphan trait) เข้าใจเหตุผลนะ แต่ก็ยังเป็นกฎที่น่ารำคาญอยู่ดี ฟีเจอร์ใหม่ ๆ ช่วยแก้ได้บ้าง (บางครั้งถึงขั้นต้องห่อซ้อน 2-3 ชั้น!) แต่ก็ยังสงสัยว่าจำเป็นต้องเป็นแบบนี้จริงหรือ
  • 3. ถ้าอยากได้เวลา compile ที่เหมาะสม ต้องแยกโปรเจกต์ออกเป็น crate เล็ก ๆ จำนวนมาก เข้าใจเหตุผล แต่ผลลัพธ์ออกมาไม่ค่อยดี crate ถูกมองเป็นหน่วยคอมไพล์เดียว เพราะอนุญาตให้มี circular dependency ได้ แต่โค้ดส่วนใหญ่จริง ๆ แล้วไม่มี circular dependency ดังนั้นน่าจะมีทางแบบ opt-in หรือให้แยก item/file ภายใน crate ออกเป็นหน่วยคอมไพล์ตาม dependency graph โดยอัตโนมัติได้ก็คงดี
  • ที่นึกออกมีเท่านี้ แต่คงยังมีอีกเยอะ ถึงอย่างนั้น Rust ก็ยังเป็นภาษาที่ดีที่สุดในชีวิตผม แม้จะเป็นการวิจารณ์อย่างสร้างสรรค์ก็ตาม
    • มีการชี้ว่า Rust ไม่อนุญาต circular dependency ระหว่าง crate แต่อนุญาต circular dependency ระหว่างโมดูลภายใน crate แม้จะคิดว่าโค้ดส่วนใหญ่ไม่มี circular dependency แต่ตัวอย่างเช่นโมดูลใดก็ตามที่มี test submodule ก็ถือว่าใช้ circular dependency ไปด้วย ถ้าจะให้แยกเทสต์อย่างถูกต้องจริง ๆ ก็ต้องนิยามฟังก์ชันเทสต์ทั้งหมดไว้ที่ crate root ซึ่งในความเป็นจริงไม่มีประสิทธิภาพ
    • เห็นด้วยเต็มที่กับข้อ 1 และ 2 และขอเพิ่มข้อ 4 ว่าอยากได้ partial self borrows (ฟีเจอร์ที่ให้เมธอดยืมเฉพาะบางส่วนของ struct) ส่วนข้อ 3 มองว่าควรมีการรองรับที่ดีกว่านี้ก่อน เช่น การปล่อยหลาย crate พร้อมกันได้ในครั้งเดียว
    • เรื่อง orphan rule อยากให้ช่วยอธิบายเพิ่มว่าหมายถึง Rust ควรมีทางเลือกที่ดีกว่านี้จริง ๆ หรือแค่ต้องมีฟีเจอร์มาทดแทนก็พอ
    • เห็นด้วยกับ orphan rule แบบเต็ม ๆ อยากให้ใน application crate ปิดกฎนี้ได้ หรืออย่างน้อยถ้ามีการรับประกัน hygiene ที่เพียงพอ เช่น ผ่าน proc macro ก็น่าจะผ่อนกฎลงได้

• พอนึกทบทวนคำว่า “Smooth, iterative deepening” ก็รู้สึกว่า Rust ให้ความสำคัญกับ cross-language compatibility มากเกินไป จนอาจเพิ่มแต่ความซับซ้อนและเสี่ยงทำลายความปลอดภัย ในกรณีแบบนี้น่าจะเป็นประโยชน์กว่าถ้าทำในรูปแบบแทนที่ส่วนล่างสุดของระบบแบบ libc ฝั่ง Go แทบไม่ค่อยเรียกข้ามภาษา Google ลงมือสร้าง core library เองเพื่อวางรากฐานให้แน่น แต่ Rust กลับมี foundational library หลายเวอร์ชันกระจัดกระจาย และหลายตัวก็ยังไม่สมบูรณ์

  • มีการชี้ว่า หนึ่งในโจทย์หลักของวิทยาการคอมพิวเตอร์ตลอด 20 ปีที่ผ่านมาคือทำอย่างไรให้หลายโปรแกรมสื่อสารกันอย่างมีประสิทธิภาพภายในเครื่องเดียวกัน ส่วนใหญ่ก็พยายามอ้อมข้อจำกัดของ DLL แบบ Microsoft ด้วยซอร์สและสถานะ หรืออย่าง object request broker แบบ CORBA ก็ไม่เคยตั้งหลักได้ เช่นเดียวกับ RPC แบบ qnx สุดท้ายจึงยังคงเป็นการพยายามจับสิ่งที่ไม่ค่อยเข้ากันให้มาอยู่ด้วยกัน
  • ที่จริงจะใช้ socket ทำทุกอย่างก็ได้ แต่ socket เป็น byte stream ระดับล่างจึงเป็น abstraction ที่ไม่ค่อยเหมาะ แม้อย่างนั้นก็ยังต้องใช้เพราะมันใช้งานสะดวก
    • ในมุมผม ประเด็นในโพสต์นี้ไม่ใช่การจะสร้างตัวแทน shared library ข้ามภาษาของจริงแบบ DLL/COM/Wasm components แต่เป็นความต้องการเชิงปฏิบัติที่จะ migrate จาก C++ มา Rust แบบค่อยเป็นค่อยไป เพื่อเพิ่ม memory safety โดยรวม คำถามใหญ่คือจะทำอย่างไรกับโปรแกรมที่มีอยู่แล้ว ซึ่งตอนนี้ระดับการทำงานร่วมกันระหว่าง Rust กับ C++ ยังไม่ดีพอ ถ้าทั้งสองภาษาร่วมงานกันได้ลื่นไหลในระดับซอร์ส ก็มีโอกาสจริงมากขึ้นที่ Rust จะมาแทนหมวดหมู่การใช้งานจำนวนมากของ C++
    • บางครั้งก็รู้สึกว่าแค่ socket กับ protocol ที่เข้ากันได้ก็เกือบเป็น cross-language abstraction ที่ดีที่สุดแล้ว ถ้าอย่างนั้นก็เลยอยากรู้ว่าคนที่ว่าเรื่องนี้ มอง abstraction สำหรับการเรียกข้ามภาษาที่ “อุดมคติจริง ๆ” ว่าเป็นแบบไหน

• มีการเน้นว่า “หลีกเลี่ยงการจัดสรรหน่วยความจำ, อย่าให้ GC ถูก trigger” นั้นไม่สอดคล้องกับแนวคิด GC และ JIT ยุคใหม่ GC สมัยใหม่หลายตัวแทบไม่มี stop-the-world latency แล้ว และการใช้ CPU ของ GC โดยรวมขึ้นกับสัดส่วนระหว่าง resident set กับขนาด heap เป็นหลัก ส่วน JIT มีโอกาสในการ optimize มากกว่า AOT และยังสำรวจได้เชิงรุกกว่า (ด้วย speculative optimization) สิ่งที่สำคัญจริง ๆ คือเวลาเริ่มต้น/วอร์มอัป, overhead ด้านหน่วยความจำ และประสิทธิภาพเฉลี่ย ไม่ใช่ worst-case ที่แย่ลงไป ยิ่งไปกว่านั้น การจัดการหน่วยความจำด้วยมือก็ไม่ได้แปลว่ามีประสิทธิภาพมากกว่าเสมอไป และถึงการใช้ RAM จริงจะเพิ่มขึ้น 3 เท่า ต้นทุนก็อาจไม่ต่างเลยก็ได้ ขอแนะนำ งานบรรยายในงานประชุม ISMM ที่พูดเรื่องนี้ได้ดี

  • มีคำถามว่าที่บอกว่า JIT เห็นโอกาสในการ optimize มากกว่า หมายถึงอะไรอย่างเป็นรูปธรรม เพราะท้ายที่สุด JIT ก็เป็นเพียงส่วนเสริมของ AOT
  • มีคำถามว่า 'GC สมัยใหม่' ที่พูดถึงนี้ หมายถึง implementation แบบใดบ้าง

• มองว่าคอมเมนต์และการถกเถียงที่ถูกติดธงไว้ จับประเด็นสำคัญได้ดี ทั้งเรื่อง “มาสร้างมาตรฐานภาษาที่มีสเปกอย่างเป็นทางการกันเถอะ” และ “จำเป็นต้องมีหลาย implementation” ซึ่งเป็นคำถามสำคัญในโลกจริง โดยเฉพาะ @infogulch ที่ชี้ได้ดีว่า ถ้าภาษาจะเป็นรากฐานของอุตสาหกรรมจริง ก็ต้องมีสเปกอย่างเป็นทางการ (คอมเมนต์อ้างอิง)

  • มีการยกตัวอย่างแบบมีชั้นเชิงว่า ไม่เพียงเหตุผลที่คอมเมนต์นั้นถูกติดธงจะไม่ชัดเจน แต่ในทางปฏิบัติก็มีหลายภาษาที่กลายเป็นภาษารากฐานของอุตสาหกรรมได้ ทั้งที่ไม่มีสเปกมาตรฐานหรือไม่มีหลาย implementation เช่น Ruby แม้จะมีมาตรฐาน ISO เก่าอยู่ แต่ก็ครอบคลุมแค่เวอร์ชันนั้น ส่วน Python นั้น implementation เองต่างหากที่เป็นมาตรฐานโดยพฤตินัย Rust ก็เช่นกัน และในมุมผู้ใช้กระแสหลักก็ไม่ได้รู้สึกว่านี่เป็นเหตุผลที่จะต้องเปลี่ยนภาษา
  • พอสงสัยคำว่า “official language standard” ก็เลยลองค้นดู พบว่ามีเอกสารอ้างอิงที่ rust-lang/reference โครงการ Rust จริงจังกับการทำ language specification มาก และใน โพสต์วิสัยทัศน์บนบล็อก ล่าสุดก็อธิบายความคืบหน้าไว้อย่างละเอียด งานด้านสเปกนี้ใหญ่และยากมาก แต่ก็ยังเดินหน้าอย่างคึกคัก ถึงขั้นมี PR merge เข้า master branch กันในช่วงสุดสัปดาห์
  • ส่วนเรื่องต้องมีหลาย implementation นั้น ก็หวังว่าการที่มี คอมไพเลอร์ Rust ทางเลือกอย่าง gccrs เป็นต้น พัฒนาอย่างเป็นทางการอยู่แล้ว จะช่วยได้บ้าง
  • มีมุมมองแบบกังขาว่าทั้ง LLM และ Rust ต่างก็เป็นสิ่งที่ตอบโจทย์ได้เพียงบางส่วนและเพิ่ม productivity ได้เล็กน้อย แต่ก็ไม่เห็นด้วยกับท่าทีของชุมชนที่พยายามขยายอิทธิพลโดยไม่รับผิดชอบ
  • มีการขอให้อธิบายเพิ่มว่า “published language standard” คืออะไรแน่ และในโลกจริงช่วยอะไรได้บ้าง
  • ไม่ได้มีปัญหากับตัว Rust เอง แต่รู้สึกเสียดายที่ผู้ใช้บางส่วนไม่เข้าใจว่าทำไม formal specification ถึงสำคัญมาก ระบบเชิงคำนวณทุกระบบมีอายุและความน่าเชื่อถือขึ้นกับว่าจัดการกับสเปกอย่าง formal แค่ไหน ถ้าไม่มีข้อกำหนดที่ชัดเจน ก็เท่ากับต้องพึ่งเพียงว่า implementation ไหนบังเอิญทำงานกับ input ไหนได้ ซึ่งเป็นฐานที่เปราะบางเกินไปสำหรับการวางระบบ ในโลกคอมพิวติ้ง สเปกก็คือตัวระบบนั่นเอง (ส่วน implementation เป็นเพียง optimization ประกอบ)

• ผู้คนมักตั้งคำถามกันตั้งแต่ต้นว่า Rust จำเป็นต้องมีสเปกจริงหรือไม่ ซึ่งยิ่งสะท้อนว่าใน software engineering มีความเป็นวิศวกรรมจริง ๆ น้อยเกินไป

  • มองว่า software engineering ไม่ใช่วิศวกรรมจริง ๆ สำหรับสะพานหรืออาคารสูง เราไม่จำเป็นต้องสร้างซ้ำ 3 ครั้งกว่าจะทำให้ถูกต้อง แต่ในซอฟต์แวร์กลับกลายเป็นว่านั่นอาจเป็นแนวทางที่ดีเสียด้วยซ้ำ

• ต่อคอมเมนต์ที่บอกว่า Rust เป็น “ภาษาที่มีแต่คนที่อยากดูเหมือนโปรแกรมเมอร์เท่านั้นที่ใช้” เจ้าตัวบอกว่าตนเองเป็นคนที่รักการเขียนโปรแกรมจริง ๆ และ Rust ก็เป็นประสบการณ์ที่สดใหม่มาก ไม่อยากย้อนกลับไปสู่ยุคที่ C++ ทรมานอย่างหนักอีกแล้ว และก็ไม่คิดว่ามาตรฐานภาษา (การบริจาคสเปก Ferrocene) หรือจำนวน implementation จะสำคัญขนาดนั้น Python กับ Java ก็พึ่ง implementation หลักตัวเดียวและเดินหน้าได้ดี C++ พยายามรองรับหลายคอมไพเลอร์ สุดท้ายก็มีแต่เพิ่มปัญหาซับซ้อนเฉพาะแพลตฟอร์ม ส่วนคำว่า cargo “ยุ่งเหยิง” หมายถึงอะไรนั้นก็ไม่ชัด เพราะมองว่าฝั่ง C++ ยุ่งยากกว่ามาก

  • มีคำถามว่ากับ cargo แล้วมีปัญหาอะไรบ้างแบบเจาะจง
  • ยังเสริมว่าก็อดสงสัยไม่ได้ว่าเรื่องมาตรฐานของภาษาและความหลากหลายของ implementation สำคัญจริงหรือไม่ หรืออาจจะยังเร็วเกินไป และถ้า Rust ทุ่มพลังกับเรื่องพวกนี้ตั้งแต่แรก จะประสบความสำเร็จได้เท่าปัจจุบันหรือไม่ ในบทความต้นทางก็ดูเหมือนไม่ได้เรียกร้องให้เป็นตัวแทนของทุกอย่างแบบครอบจักรวาล แต่เป็นการเน้นว่ารองรับ/เหมาะกับงานเป้าหมายบางประเภท
  • มองว่า cargo เป็น package manager ที่ดีที่สุดในบรรดาภาษาหลักของโลกตอนนี้ มันเรียนรู้จากความล้มเหลวของ package manager รุ่นก่อน ๆ ได้ดีมาก จนออกมาละเอียดและแข็งแรงในฐานะโครงสร้างพื้นฐาน อาจยังมีจุดให้ปรับเล็กน้อย เช่น namespace หรือ repeatable build ที่สมบูรณ์ แต่การจะยก cargo ปัจจุบันไปวางบนภาษาอื่นแทบเป็นไปไม่ได้เลย แทบไม่มีภาษาไหนมีโครงสร้างพื้นฐานระดับนี้