- บทความสรุปประสบการณ์นำ Rust มาใช้จริงในการทำงานตลอด 10 ปีนับตั้งแต่หลังการเปิดตัว Rust 1.0 และความคาดหวังต่ออีก 10 ปีข้างหน้า
- ในช่วงแรก ปัญหาความเข้ากันได้ของเวอร์ชัน, เวลาคอมไพล์, และการปรับตัวกับ borrow checker เป็นเรื่องยาก
- ชุมชนและอีโคซิสเต็มของ Rust เติบโตอย่างรวดเร็วจาก “สัญชาตญาณการเขียนโปรแกรมอันยอดเยี่ยม” และวัฒนธรรมชุมชนที่แข็งแกร่ง จนเห็นได้ชัดว่านักพัฒนาฝีมือดีจำนวนมากหลั่งไหลมาที่ Rust
- ตอนนี้ Rust ได้กลายเป็น “ตัวเลือกที่มั่นคง” สำหรับงานระบบและแบ็กเอนด์ทั่วไปแล้ว และด้วยการพัฒนาของ standard library กับความสุกงอมของอีโคซิสเต็มครेट จึงทำให้ความไม่แน่นอนลดลงมาก
- ระบุอย่างเป็นรูปธรรมถึงโจทย์ที่ Rust ยังต้องแก้และทิศทางการพัฒนา เช่น ความเร็วในการ build, portability, ความสามารถของ const, concurrency, และการขยายไปยังโดเมนที่หลากหลาย
- อีก 10 ปีข้างหน้าถูกคาดว่าจะมีคอมไพล์ที่เร็วขึ้น การขยายไปสู่โดเมนที่กว้างขึ้น และนวัตกรรมด้านประสบการณ์นักพัฒนา พร้อมความหวังว่า positive feedback loop ของอีโคซิสเต็ม Rust จะยิ่งเร่งตัว
- เดือนมิถุนายน 2015 ราวหนึ่งเดือนหลังความตื่นตัวจากการเปิดตัว Rust 1.0 เริ่มซาลง ผู้เขียนได้เขียนโค้ด Rust ชิ้นแรก
- หลังจากเคยใช้ C, Python, JavaScript แล้วได้มาสัมผัส Rust ก็แทบไม่หันกลับไปมองอีก
- ผู้เขียนแบ่งปันการทบทวนตลอด 10 ปีจากประสบการณ์ในสตาร์ตอัปที่ใช้ Rust สองแห่ง และการเขียนโค้ดมากกว่า 500,000 บรรทัด
ช่วงแรกเป็นเวลาที่ยากลำบาก - The early days were painful
- ตอนเริ่มนำ Rust มาใช้ ความเข้ากันได้ของเวอร์ชันระหว่าง crate กับคอมไพเลอร์ยังไม่เสถียรอย่างมาก และแม้เป็นการแก้บั๊กเล็กน้อยก็มักต้องอัปเดตสภาพแวดล้อมการ build ทั้งหมดแบบบังคับ
- แนวคิดของ borrow checker และการจัดการ lifetime ให้ความรู้สึกว่ายาก, และเมื่อประเภทข้อมูลซับซ้อนขึ้น ปัญหาเวลาคอมไพล์ที่เพิ่มขึ้นอย่างรวดเร็วก็รุนแรงมาก
- ทุกครั้งที่ต้องการฟีเจอร์ใหม่หรือบั๊กฟิกซ์ ก็แทบต้องอัปเดต “ทุกเวอร์ชันในโลก” และ เสียเวลาอย่างมากไปกับการหาเวอร์ชันที่เข้ากันได้
ความยอดเยี่ยมของชุมชน Rust - The people were and are exceptional
- อีโคซิสเต็ม Rust มีวัฒนธรรมการเขียนโปรแกรมที่โดดเด่น โดยมุ่งสู่ การใช้งานที่เรียบง่ายและสง่างาม พร้อมประสิทธิภาพที่รวดเร็วและแข็งแกร่ง
- เมื่อเทียบกับตอนใช้ TypeScript หรือ Python แล้ว โครงสร้าง dependency ของ Rust สะอาดกว่ามากและ build ก็เรียบง่ายกว่า
- การอุทิศตนของอาสาสมัครในชุมชนและท่าทีระมัดระวังแบบ “ยังไม่ใช่ตอนนี้/ยังไม่ถึงเวลา” มีบทบาทสำคัญอย่างยิ่ง
- ในลอนดอน Rust ให้ข้อได้เปรียบมากในการสรรหานักพัฒนา และ โดยเฉลี่ยแล้วนักพัฒนา Rust มีศักยภาพสูงมาก
Rust กลายเป็นตัวเลือกที่ปลอดภัยแล้ว (ในบางโดเมน) - Rust has become a safe bet (in some domains)
- ในช่วงแรก การขาด standard library (
std) ทำให้ต้องสร้างฟังก์ชันอรรถประโยชน์และแพตช์ขึ้นมาเอง, แต่ตอนนี้ความสามารถส่วนใหญ่มีอยู่ใน std และ crate ต่างๆ แล้ว จึงลดความไม่แน่นอนได้มาก
- ความคาดเดาได้ของการ build และการอัปเกรด, การลด dependency ภายนอก, การยึดตาม semver, และการพัฒนาของ borrow checker กับ inference engine ทำให้ประสบการณ์ใช้งาน Rust มีเสถียรภาพขึ้นอย่างมาก
- crate รุ่นใหม่ๆ เช่น
jiff, polars, tauri ถูกพัฒนาบนพื้นฐานของบทเรียนจากอดีต ขณะที่ tokio, hyper, regex ก็ผ่านการพิสูจน์ในงานจริงแล้ว
- ในอดีตการ “สร้างล้อขึ้นใหม่” เป็นสิ่งเลี่ยงไม่ได้ แต่ตอนนี้สามารถโฟกัสกับ business logic และพัฒนาแอปพลิเคชันที่ทั้งประสิทธิภาพสูงและแข็งแกร่งได้
สภาพแวดล้อมการพัฒนาที่ Rust วันนี้แสดงให้เห็น - Rust today feels like what programming should be
- Rust เป็นภาษาที่มีความเข้าใจนักพัฒนาอย่างแท้จริง ทั้งในแง่ของ ระบบ build ที่กระชับและแข็งแรง, ข้อความ error และ lint ชั้นยอด, เอกสารและการผสานกับ IDE ที่ยอดเยี่ยม, รวมถึง CI/การทดสอบ regression ที่ทรงพลัง
- ในบรรดาโปรเจกต์โอเพนซอร์สขนาดใหญ่ แทบไม่มีภาษาไหนเป็นมิตรกับโปรแกรมเมอร์ได้เท่า Rust
- “การลงทุนระยะยาว” ของชุมชนและผู้มีส่วนร่วมจำนวนมหาศาลคือปัจจัยหลักที่สร้าง Rust ในปัจจุบัน
สิ่งที่คาดหวังในอีก 10 ปีข้างหน้า - What I’m looking forward to over the next 10 years
build ที่ง่ายและเร็วขึ้น - Simpler and faster builds
- คาดหวังว่างาน แทนที่ dependency ที่ซับซ้อนหรือช้าด้วยสิ่งที่เรียบง่ายและรวดเร็วกว่า จะดำเนินต่อไป
- มีความคาดหวังต่อความพยายามใหม่ๆ เช่น standard library แบบ pure Rust, การลดการพึ่งพา system linker และ dependency ของไลบรารี, ระบบเข้ารหัสแบบ pure-Rust, persistent BTreeMap, และ game engine ที่สร้างด้วย Rust
- ที่ Tably เอง ในช่วงไม่กี่เดือนที่ผ่านมา ความเร็วการคอมไพล์ฝั่งฟรอนต์เอนด์/แบ็กเอนด์ดีขึ้น 60%
portability ที่ดีขึ้นและ #[cfg()] ที่น้อยลง - Improved portability and less #[cfg()]
- การทดสอบชุดค่าผสมของแพลตฟอร์ม/ออปชันที่หลากหลายทำได้ยาก และยังเกิดปัญหาอย่าง โค้ดที่ไม่ได้รับการตรวจสอบเพราะ
#[cfg()], เอกสารไม่สมบูรณ์, และปัญหากับ IDE
- คาดหวังว่าจะย้าย
#[cfg()] เข้าไปใน trait system เพื่อให้เกิด การรับประกันด้านแพลตฟอร์ม/ออปชัน, ลดการคอมไพล์ซ้ำ, ใช้ MIR cache, และทำให้ CI เร็วขึ้น
ขอให้ทุกโค้ดเป็น const ได้ - Everything being const
- การ ทำงานให้มากขึ้นตั้งแต่ตอนคอมไพล์ จะช่วยลดการพึ่งพา macro/build script และป้องกันข้อผิดพลาดขณะรันได้ล่วงหน้า
- แม้ตอนนี้ยังมีข้อจำกัด แต่ในอนาคตมุ่งสู่ Rust ที่ “โค้ดทุกส่วนสามารถรันใน const context ได้”
ทำให้ concurrency ง่ายขึ้น - Simpler concurrency
- โมเดล async ของ Rust ในปัจจุบันมีความซับซ้อนสูง ทั้งเรื่อง
static bound, cancellation-safety, ข้อจำกัดของ trait ฯลฯ จนสร้างความยากในการใช้งานจริง
- จำเป็นต้องมุ่งสู่ concurrency ที่เรียบง่ายในระดับภาษา แบบเดียวกับ user-space green thread (
libgreen) ในอดีต
แข่งขันได้ดีขึ้นในโดเมนที่หลากหลาย - Excelling in more domains
- การใช้งาน Rust ภายในเว็บเบราว์เซอร์ (โดยเฉพาะ wasm/rustwasm) ยังเป็นพื้นที่ที่เปิดไม่สุด และยังมีโจทย์อีกหลายอย่าง เช่น stack trace ข้ามเบราว์เซอร์
- แม้เฟรมเวิร์กอย่าง
leptos, sycamore จะพัฒนาอย่างต่อเนื่อง แต่ก็ยังมีพื้นที่ให้ปรับปรุงอีกมาก
- คาดหวังว่าโดเมนที่ Rust ยังเจาะได้ไม่เต็มที่ เช่น rapid prototyping, business logic, GUI, machine learning, game development ก็จะดีขึ้นต่อเนื่องเช่นกัน
บทสรุป
- อนาคตการเติบโตของ Rust ชัดเจนและเปี่ยมความหวังอย่างมาก
- ยิ่งมีการนำไปใช้มากขึ้น ความสามารถด้านวิศวกรรม/การทดสอบก็ยิ่งเพิ่มขึ้น และนำไปสู่วงจรเชิงบวกของการยอมรับที่กว้างขึ้นและการปรับปรุงที่มากขึ้น
- 10 ปีข้างหน้าจะทำให้ การคอมไพล์ที่เร็วขึ้น การประยุกต์ใช้ในหลายสาขา และประสบการณ์พัฒนาที่ลื่นไหล กลายเป็นจริง
- ตั้งตารอ 10 ปีบทใหม่ของ Rust
5 ความคิดเห็น
Rust ดีทุกอย่าง แต่ภาษานี้เรียกร้องจากผู้ใช้มากเกินไป
พอใช้ Rust ไปเรื่อย ๆ ก็รู้สึกเหมือนกำลังศึกษาภาษา Rust เอง มากกว่าจะโฟกัสกับการลงมือทำไอเดียให้เป็นจริง
ถ้าเป็นการย้ายโปรเจ็กต์ที่มีอยู่แล้ว อย่างเช่นย้ายมาจาก C++ ก็คงไม่มีปัญหาอะไรมาก
แต่ถ้าจะใช้มันเพื่อทำไอเดียใหม่ ๆ ว่าสะดวกไหม อันนี้ก็ยังไม่แน่ใจครับ
แนะนำ Python สำหรับการทำต้นแบบครับ
โดยส่วนตัวแล้วผมชอบระบบชนิดข้อมูล ตอนนี้เลยใช้ C# อยู่ และคิดว่าระดับนี้ก็น่าพอใจแล้วครับ
โดยส่วนตัวแล้ว ถ้าคิดถึงสิ่งแวดล้อมของโลก ก็ต้อง RUST เอาโค้ด Spring แบบ legacy ไปใช้กับ Axum เลย!!!
ความคิดเห็นบน Hacker News
"async มีต้นทุนด้านความซับซ้อนค่อนข้างสูง เนื่องจากข้อจำกัดอย่าง static bound, cancellation safety, trait และข้อจำกัดที่เกี่ยวกับ dyn ตอนนี้ยังไม่เห็นแววว่าปัญหานี้จะถูกแก้ได้ การแยกระหว่าง synchronous/asynchronous primitives และลักษณะเฉพาะของ ecosystem ทำให้ async tax (ต้นทุนส่วนเพิ่ม) สูงขึ้น ส่วนโซลูชันที่อิงกับ Effects ก็ไม่ได้ดูมีความหวังนัก"
"ใน Rust ก่อน 1.0 เคยมีแนวทางแก้ชื่อ libgreen มันทำ concurrent programming ใน user space โดยไม่มี bifurcation (การแยกออกเป็นสองทาง) แต่ด้วยต้นทุนด้านประสิทธิภาพ ความพกพา และการบำรุงรักษาที่สูงมาก สุดท้ายจึงถูกถอดออกไป ฉันคิดว่าถ้ามีกำลังทางวิศวกรรมมากพอ ก็น่ากลับมาทบทวนอีกครั้ง สักวันหนึ่งฉันอยากทำ PoC ที่ zero-cost wrapping
std::{fs, net}กับfiber::{spawn, select}ด้วย generator"spawn,spawn_blocking,futures::streamก็ครอบคลุมการใช้งาน 90% แล้ว และถ้าวาง "ขอบเขต" ไว้ให้เหมาะสม ก็ไม่จำเป็นต้องปล่อยให้ async แพร่ไปทั่วทั้งโปรแกรม