รีวิวภาษาโปรแกรม Rust: คุ้มค่าที่จะเรียนไหม?

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

ความขัดแย้งนี้คือแก่นแท้ของคำถามที่ว่า “Rust คุ้มค่าที่จะเรียนไหม” และเป็นเหตุผลที่คำตอบ “คุ้ม” แบบเหมารวมไม่มีประโยชน์อะไรกับคุณ Rust เป็นภาษาแบบคอมไพล์ ซึ่งส่วนที่ปลอดภัย (safe subset) ของมันบังคับใช้กฎความปลอดภัยของหน่วยความจำตั้งแต่ตอนคอมไพล์ โดยไม่ต้องมี garbage collector ตอนรันไทม์

ผมจึงจะให้คำตอบที่ชัดเจน บอกเงื่อนไขที่คำตอบนั้นขึ้นอยู่กับ และแสดงให้เห็นว่าเงื่อนไขนั้นมีต้นทุนเท่าไร

เวอร์ชันสั้น

Rust คุ้มค่าที่จะเรียน ถ้าคุณกำลังสร้างสิ่งที่ต้องอยู่ไปอีกนาน และการที่คอมไพเลอร์ช่วยดักบั๊กทั้งกลุ่มนั้นคุ้มที่จะจ่าย แต่มันไม่เหมาะถ้าคุณต้องส่งแอป CRUD ภายในเดือนนี้ กำลังเริ่มเรียนเขียนโปรแกรม หรือกำลังนับจำนวนประกาศรับสมัครงาน 4 จาก 5 คะแนน, หักคะแนนเพราะต้นทุนที่ต้องจ่ายก่อนจะได้ผลตอบแทน

• สิ่งที่คุณได้: ใน safe Rust กฎ ownership และ borrowing จะเปลี่ยนบั๊กแบบ use-after-free, double-free, การอ้างอิงที่ไม่ถูกต้อง และ data race ให้กลายเป็นข้อผิดพลาดตอนคอมไพล์ แทนที่จะเป็นเหตุขัดข้องบน production นั่นคือจุดขายทั้งหมด และเป็นจุดขายที่ดี
• สิ่งที่คุณจ่าย: คอมไพเลอร์บังคับให้คุณเขียนการตัดสินใจเรื่องหน่วยความจำที่ภาษาที่คุณใช้อยู่ทำให้แบบเงียบ ๆ ออกมาอย่างชัดเจน และช่วงแรกจะรู้สึกเหมือนเครื่องมือกำลังหาเรื่อง
• คำถามเรื่องความยั่งยืนได้ข้อยุติแล้ว ผู้ดูแล kernel สรุปปิดการทดลอง Rust ในงาน Maintainers Summit เดือนธันวาคม 2025 และป้าย “experimental” ก็ถูกถอดออกใน Linux 7.0
• คำถามเรื่องกระแสความนิยมยังไม่ได้ข้อยุติ และเป็นคนละคำถามกัน Rust อยู่อันดับ #10 ในดัชนี TIOBE เดือนกันยายน 2026 ขึ้นมาจาก #18 เมื่อหนึ่งปีก่อน
• บริการ Rust ที่ผมทดสอบต้องใช้หน่วยความจำตอนคอมไพล์มากกว่าตอนรันอย่างมาก: ตอน build พุ่งสูงสุดเกือบ 1 GB และตอนรันขณะ idle อยู่ที่ประมาณ 3.5 MB
• เหมาะกับคุณถ้า คุณส่งงานด้วยภาษาอื่นอยู่แล้วและกำลังสร้างสิ่งที่บั๊กหน่วยความจำจะมีราคาแพง หรือคุณทำงานใกล้กับซอฟต์แวร์ระดับระบบ ไม่เหมาะกับคุณถ้า คุณมีเดดไลน์ เริ่มจากศูนย์ หรือกำลังเลือกภาษาที่มีตำแหน่งงานเปิดมากที่สุด

รีวิวนี้ทำอย่างไร: ตัวเลขการ build และรันไทม์ในบทความนี้เป็นของผมเอง ผมติดตั้ง Rust 1.98.1 เขียนเว็บเซอร์วิส Axum ขนาดเล็ก แล้ววัดว่าต้องใช้อะไรบ้างในการคอมไพล์และในการรัน การทดสอบนี้รันในคอนเทนเนอร์แบบ sandbox ไม่ใช่บนฮาร์ดแวร์เฉพาะ และเป็นแค่โปรเจกต์เดียว จึงควรมองตัวเลขเหล่านี้เป็นจุดข้อมูลหนึ่ง ไม่ใช่กฎตายตัว ส่วนที่เหลือทั้งหมดมาจากแหล่งข้อมูลปฐมภูมิหรือแหล่งที่เชื่อถือได้: แพตช์ kernel และรายงานของ LWN เกี่ยวกับแพตช์นั้น โพสต์ด้านความปลอดภัยของ Android จาก Google ดัชนีของ TIOBE เอง (พร้อมความเห็นเดือนเมษายนผ่านบันทึกของ Slashdot) บทความของ Phoronix เรื่อง merge window ของ Linux 7.0 บันทึก CVE ของ Linux kernel สำหรับช่องโหว่ใน Binder แถลงการณ์ของ Canonical เอง และแบบสำรวจ Stack Overflow ปี 2025 ผมอ่านแพตช์ kernel แล้ว แต่ไม่ได้ตรวจสอบโค้ด Rust ใน kernel และผมไม่ได้เขียน Rust มาหลายปี ดังนั้นส่วนที่รีวิวนี้ตัดสินตัวภาษาเอง คือการอ่านความเห็นของผู้ใช้จริงที่เขียนมานาน และระบุชื่อพวกเขาไว้

สิ่งที่คอมไพเลอร์ซื้อให้คุณ

ส่ง mutable reference ไปยัง vector เดียวกันให้สองเธรดใน Rust แล้วโค้ดจะคอมไพล์ไม่ผ่าน ไม่ใช่คำเตือน ไม่ใช่ lint ที่คุณปิดได้ตอนเร่งงาน แต่มัน build ไม่ได้เลย การปฏิเสธนั้นคือสิ่งที่คุณซื้อใน safe Rust: บั๊กแบบ use-after-free, double-free, การอ้างอิงที่ไม่ถูกต้อง และ data race ถูกผลักไปเป็นข้อผิดพลาดตอนคอมไพล์ แทนที่จะเป็นเหตุขัดข้องบน production ทางหนีของ Rust (unsafe) สามารถข้ามการรับประกันบางส่วนเหล่านั้นได้ นี่จึงไม่ใช่คำสัญญาที่เด็ดขาดสำหรับโค้ดเบส Rust ทุกตัว

Ownership หมายความว่าทุกค่ามีเจ้าของเพียงหนึ่งเดียวที่รับผิดชอบการคืนหน่วยความจำ Borrowing หมายความว่าคุณให้ยืมการอ้างอิงได้ แต่คอมไพเลอร์จะติดตาม lifetime ของมัน และไม่ยอมให้การอ้างอิงมีอายุยืนกว่าสิ่งที่มันชี้อยู่ หรือให้ mutable borrow อยู่ร่วมกับ borrow อื่นใด ใน safe Rust บั๊กแบบ use-after-free, double-free, การอ้างอิงที่ไม่ถูกต้อง และ data race จะถูกจับได้โดยระบบ ownership และระบบชนิดข้อมูลก่อนที่โปรแกรมจะรัน

ไม่มี garbage collector นี่คืออีกครึ่งหนึ่งของข้อตกลง เพราะ ownership บอกไว้แล้วว่าใครคืนอะไรเมื่อไร จึงไม่ต้องมีอะไรมาไล่ตรวจ heap ของคุณตอนรันไทม์ คุณส่งไบนารีที่ไม่มี collector อยู่ข้างใน และไม่มีช่วงหยุดชะงักที่ต้องคอยจูนหลบ

ราคาที่ต้องจ่ายปรากฏในที่เดียวกับการรับประกัน ทุกการตัดสินใจเรื่องหน่วยความจำที่ภาษาปัจจุบันของคุณทำแทนให้อย่างเงียบ ๆ Rust จะขอให้คุณเขียนออกมา: ใครเป็นเจ้าของสิ่งนี้ การอ้างอิงนั้นอยู่ได้นานแค่ไหน มีอย่างอื่นมองเห็นมันได้ไหม และมันข้ามขอบเขตเธรดหรือเปล่า คอมไพเลอร์ไม่ได้หาเรื่อง มันแค่ปฏิเสธที่จะเดา

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

Rust ยังเป็นของทดลองอยู่ไหม หรือกลายเป็นโครงสร้างพื้นฐานระดับ production แล้ว?

มันเลิกเป็นของทดลองในเดือนธันวาคม 2025 และคนที่ปิดการทดลองนั้นก็คือผู้ดูแล kernel เอง ในงาน Maintainers Summit ปี 2025 พวกเขาสรุปว่า Rust พิสูจน์คุณค่าของตัวเองใน kernel แล้วทั้งในเชิงเทคนิคและเชิงสังคม Jonathan Corbet จาก LWN รายงานฉันทามตินั้นเมื่อวันที่ 10 ธันวาคม 2025: Rust ใน kernel ไม่ใช่ของทดลองอีกต่อไป.

Rust เข้าสู่ Linux สายหลักที่ v6.1 ในปี 2022 เพื่อทำการทดลองนั้นโดยเฉพาะ แพตช์ของ Miguel Ojeda ที่ถอดป้ายนี้ออกตามมาหลัง Summit สามวัน และถูกรับเข้าใน merge window ของ Linux 7.0.

“แต่การทดลองจบแล้ว กล่าวคือ Rust จะอยู่ต่อไป”

Miguel Ojeda, “rust: conclude the Rust experiment”, LKML, 13 ธันวาคม 2025

อีกเรื่องหนึ่งที่แยกกันและเกิดก่อน: ไดรเวอร์ Binder ของ Android ที่ Google เขียนใหม่ด้วย Rust ซึ่งเป็นชั้น IPC ที่โปรเซสต่าง ๆ ของ Android ใช้สื่อสารกัน (ตลอดเวลา) ถูกรวมเข้าใน Linux 6.18, ซึ่งออกเมื่อวันที่ 30 พฤศจิกายน 2025 ให้แยกหมุดหมายนี้ออกจากฉันทามติของ Summit นี่คือครั้งที่บริษัทหนึ่งเดิมพันผลิตภัณฑ์ที่วางขายจริงไว้กับ Rust ใน kernel ไม่ใช่กลุ่มผู้ดูแลที่รับรองแนวคิด นับจากนั้น Rust ใน kernel ก็มี CVE แรกแล้ว: CVE-2025-68260, ซึ่งเป็น race condition ในไดรเวอร์ Binder ตัวเดียวกัน ที่ Greg Kroah-Hartman ประกาศเมื่อวันที่ 16 ธันวาคม 2025 โดยเกิดขึ้นใน 6.18 และแก้ไขใน 6.18.1 รายงานช่วงแรกเน้นไปที่การแครช แต่การให้คะแนนในภายหลังของทีม CVE ของ Linux kernel ให้ CVE-2025-68260 อยู่ที่ 7.8 (High) และอธิบายเส้นทางการยกระดับสิทธิ์ในเครื่องผ่านความเสียหายของหน่วยความจำ kernel ไดรเวอร์ตัวเดียวกัน (rust_binder) ก็มี CVE เพิ่มเติมสะสมมาตั้งแต่นั้น

Android คือที่ที่หลักฐานกลายเป็นตัวเลข บล็อกความปลอดภัยของ Google ระบุไว้เมื่อเดือนธันวาคม 2022 ว่ามี ช่องโหว่ด้านความปลอดภัยของหน่วยความจำที่ถูกค้นพบเป็นศูนย์ ในโค้ด Rust ของ Android เทียบกับโค้ด Rust ราว 1.5 ล้านบรรทัดใน AOSP และประมาณ 21% ของโค้ด native ใหม่ทั้งหมดใน Android 13 นั่นคือคำกล่าวปี 2022 ที่มีขอบเขตของปี 2022 โพสต์ต่อมาของ Google ให้แนวโน้มที่ยาวกว่า: ปัญหาความปลอดภัยของหน่วยความจำคิดเป็น 76% ของช่องโหว่ Android ในปี 2019 และ 24% ในปี 2024 โดยจำนวนดิบ ลดลงจากกว่า 220 เหลือประมาณการ 36. ตัวเลขเหล่านี้มีความหมายก็ต่อเมื่อเทียบกับฐานที่มันเข้ามาแทน ซึ่งก็คือ C และ C++ ที่เขียนโดยวิศวกรเก่งมาก ๆ พร้อมเครื่องมือที่ดีมาก ๆ

ยังมีสัญญาณเล็ก ๆ อีกสองอย่างที่ชี้ไปทางเดียวกัน ไดรเวอร์ GPU Apple AGX ใน Asahi Linux เขียนด้วย Rust โดยโปรเจกต์ Asahi Linux เป็นงาน reverse engineering ไม่ได้เขียนโดย Apple อัปเดต rust-coreutils ของ Canonical ระบุว่า Ubuntu 26.04 LTS ใช้ rust-coreutils 0.8.0 สำหรับยูทิลิตีส่วนใหญ่ มีสามตัวที่ยังใช้ GNU coreutils (cp, mv, rm) เพราะยังมีปัญหา TOCTOU ค้างอยู่แปดรายการ ณ วันที่ 22 เมษายน 2026 และ Canonical ตั้งเป้าเปลี่ยนยูทิลิตีที่เหลือใน 26.10

นี่คือด้านที่ผมให้คะแนนสูงสุด และเหตุผลอยู่ที่ลักษณะของพันธะที่เกี่ยวข้อง ผู้ดูแล kernel ไม่ย้อนผลสรุปการทดลอง Google ไม่ถอยการเขียนใหม่ขนาดนั้น และ Canonical ไม่ใส่ coreutils ที่เขียนใหม่ลงใน LTS เพียงเพื่อลองดู ไม่ว่าความนิยมของ Rust จะเป็นอย่างไร ก็ต้องมีคนดูแลโค้ดนั้นไปอีกหลายปี

Rust ตายแล้วหรือแค่ทรงตัว?

ไม่ Rust ทำอันดับเท่ากับสถิติสูงสุดตลอดกาลใน TIOBE ที่ #13 ในเดือนมกราคม 2026 สามเดือนต่อมาก็ร่วงกลับไปที่ #16 และ Paul Jansen ซีอีโอของ TIOBE เขียนไว้ในเดือนเมษายน 2026 ในความเห็นที่ Slashdot ยกมาอ้างในตอนนั้นว่า การเติบโตของความนิยมของ Rust “ดูเหมือนกำลังทรงตัว” และตำแหน่งท็อป 10 “ตอนนี้ดูไกลกว่าเดิม”

เขากำลังพูดถึงการที่ Rust ขึ้นไปถึง ตำแหน่งสูงสุดตลอดกาล บนดัชนีของเขาเอง ซึ่งเป็นตำแหน่งที่มันเคยได้ครั้งแรกในเดือนกรกฎาคม 2024 แล้วก็เสียตำแหน่งนั้นไป

ดัชนี TIOBE เดือนกันยายน 2026 จัดให้ Rust อยู่ที่ #10 ขึ้นมาจาก #18 เมื่อหนึ่งปีก่อน และแซง #13 ที่ TIOBE เรียกว่าตำแหน่งสูงสุดตลอดกาลเมื่อเดือนมกราคม

ความเห็นของผม: การทรงตัวนั้นเกิดขึ้นจริง แต่มันเป็นหลุมอากาศ ไม่ใช่เพดาน มุมมองนี้ดีกว่าของทั้งสองฝ่าย เพราะ “Rust หยุดโตแล้ว” ตอนนี้ผิด และ “Rust มีแต่ขึ้น” ก็ไม่เคยจริง

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

สัญญาณที่หนักแน่นกว่าในเรื่องความรู้สึกของนักพัฒนาคือแบบสำรวจ Stack Overflow ที่ Rust ได้เป็นภาษาที่ได้รับการชื่นชมมากที่สุดอีกครั้ง ในปี 2025 ด้วยสัดส่วน 72%: คือคนที่ใช้มันในปีที่ผ่านมาและอยากใช้ต่อ นั่นคือความตั้งใจที่จะใช้ต่อ ไม่ใช่อัตราการนำไปใช้ และเป็นสัญญาณที่มีประโยชน์กว่าความนิยมดิบ ๆ ถ้าคุณกำลังตัดสินว่าจะสนุกกับการอยู่กับภาษานี้ไปนาน ๆ ไหม

โมเมนตัมยังคลุมเครือ และผมให้น้ำหนักมันต่ำกว่าความยั่งยืนข้างต้น เพราะคุณไม่ได้ลงทุนในอันดับ

การเรียน Rust มีต้นทุนอะไรบ้าง

ต้นทุนมาถึงเร็วและมาทีเดียวทั้งหมด โค้ดที่ Python, Java หรือ C# ยินดีรันให้ จะถูกปฏิเสธซ้ำแล้วซ้ำเล่า ด้วยเหตุผลที่ดูไร้หลักการจนกว่าโมเดล ownership จะเข้าหัว และไม่มีทางเลื่อนมันออกไปได้ คุณส่งงานผ่าน borrow checker ไปดื้อ ๆ ไม่ได้ แบบที่คุณส่งงานไปได้ทั้งที่ยังไม่เข้าใจ ORM ของตัวเองเต็มที่

ส่วนที่ทำให้ผมประหลาดใจคือตรงนี้ และมันกลับด้านกับที่คุณคาดไว้ ในเธรด “Struggling to learn Rust” บน r/rust คำตอบที่ได้รับการตอบรับมากที่สุดมองปัญหาใหม่ว่าเป็นความไม่คุ้นเคย ไม่ใช่ความยาก และเธรดนั้นชี้ว่านักพัฒนาที่มีประสบการณ์ซึ่งย้ายมาจากภาษาที่มี garbage collector คือกลุ่มที่ลำบากกว่า u/Voxelman พูดไว้ตรง ๆ ว่า: “Rust ไม่ได้ยาก มันแค่แตกต่าง” ในเธรดเดียวกัน พวกเขาเล่าเส้นทางของตัวเองว่า เริ่มจาก C64 Basic แล้วผ่านภาษาแบบ imperative อีกหลายภาษา และการได้สัมผัส Rust ครั้งแรกนั้น “ไม่ได้ WOW เลย” เพราะต้องใช้เวลาสักพักกว่าจะทิ้งนิสัยเก่า

นั่นคือหน้าตาของบิล ถ้าคุณเขียน Python มาแปดปี คุณไม่ได้กำลังเรียนชุดกฎ แต่กำลังละทิ้งชุดสมมติฐานว่าใครจะเก็บกวาดตามหลังคุณ คนที่รู้น้อยกว่าก็มีสิ่งที่ต้องลืมน้อยกว่า

ยังมีอีกรูปแบบหนึ่งที่โผล่มาซ้ำ ๆ ในเธรดนั้น และมันเปลี่ยนความผิดพลาดเรื่องลำดับให้กลายเป็นปัญหาความมั่นใจ: ผู้คนติดขัดไม่ใช่ที่ Rust แต่ที่การเลือกเว็บเฟรมเวิร์ก โดยพยายามเรียนภาษาผ่าน Axum หรือ Actix ก่อนที่ ownership จะเข้าใจ อย่างที่ u/jmartin2683 บอกไว้ นั่น “เหมือนพยายามเรียน ruby ด้วยการเรียน rails”

ผมมองว่าคำเตือนส่วนใหญ่เรื่องต้นทุนชี้ผิดจุด จงเผื่อเวลาฝึกอย่างต่อเนื่อง ไม่ใช่แค่สุดสัปดาห์เดียว และอย่าตีความความหงุดหงิดช่วงแรกว่าเป็นคำตัดสินความสามารถของคุณ

Rust ต้องใช้เครื่องที่ใหญ่กว่าในการ build มากกว่าการรัน

นี่คือสิ่งที่ผมไม่คาดคิด: การ build โปรเจกต์ Rust นี้ใช้หน่วยความจำมากกว่าการรันหลายระดับขนาด ผม build เซอร์วิส Axum ขนาดเล็ก (Tokio แบบฟีเจอร์เซต full พร้อม serde, serde_json, tower, JSON route หนึ่งเส้น และราว 60 crates ใน dependency tree) ด้วย rustc และ cargo 1.98.1 โดยตั้งค่า strip = true ใน release profile จากนั้น build จากสถานะสะอาดสองครั้ง:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

เมื่อจำกัดไว้ที่ compile job เดียว (--jobs 1) หน่วยความจำสูงสุดรวมของ cargo, rustc และ linker อยู่ระหว่าง 464 MB ถึง 527 MB ขึ้นอยู่กับว่าคุณเลือกวิธีวัดแบบไหนจากสองแบบของผม (ผมวัดสองแบบเพราะตัวเลขแรกดูเรียบร้อยเกินไป) และใช้เวลา 113 วินาที เมื่อใช้ parallelism ค่าเริ่มต้นบนสี่ vCPU หน่วยความจำสูงสุดเพิ่มขึ้นราวสองเท่าเป็นประมาณ 1 GB และ build เสร็จในราว 35 วินาที ตัวแปรในที่นี้คือ parallelism ไม่ใช่ตัวโปรเจกต์ ยิ่งมี job มาก ก็ยิ่งมีโปรเซส rustc ค้างอยู่ในหน่วยความจำพร้อมกันมาก ซึ่งเป็นเหตุผลที่คอมไพเลอร์เป็นหนึ่งในเวิร์กโหลดไม่กี่ประเภทที่จะ ยินดีกินทุกคอร์ที่คุณให้ ต่อเนื่องกันเป็นนาที ๆ

โปรแกรมที่เสร็จแล้วมีขนาด 1.3 MB หลัง strip และตอน idle ใช้หน่วยความจำราว 3.3 ถึง 3.6 MB

ที่ parallelism ค่าเริ่มต้น การคอมไพล์ใช้หน่วยความจำมากกว่าการรันสองถึงสามร้อยเท่า และแม้จำกัดไว้ที่ job เดียวก็ยังเกินร้อยเท่าไปมาก ถ้าคุณกำหนดขนาดเซิร์ฟเวอร์ตามที่บริการ Rust ต้องใช้บน production คุณอาจได้เครื่องที่ build มันไม่ได้ และอาการล้มเหลวก็ไม่ใช่ error ที่ชัดเจน แต่เป็น out-of-memory killer ที่ฆ่า rustc กลางคันระหว่าง build หรือคอมไพเลอร์ที่ swap อย่างหนักอยู่ยี่สิบนาที มีสองทางที่ได้ผล ทางแรกคือ build ในที่ที่มีพื้นที่เหลือแล้วส่งไบนารีไป เป็นรูปแบบเดียวกับ การแยกเครื่องสำหรับ build ไว้ต่างหาก สำหรับงาน Docker หนัก ๆ ทางที่สองคือ build บนเครื่องนั้นแล้วให้พื้นที่มันพอ: สำหรับบริการรูปแบบนี้ RAM สักสองสาม GB กับสอง vCPU ก็สบาย ๆ ถ้ายังไม่พอ ทางหนีคือ --jobs 1 (ใช่ มันช้ากว่า นั่นคือสิ่งที่ต้องแลก)

ถ้าเครื่องที่คุณใช้ทำงานไม่มีพื้นที่เหลือขนาดนั้น Linux VPS แบบจัดการเอง ของเราให้สิทธิ์ root พร้อมการคิดค่าบริการรายชั่วโมงหรือรายเดือน และเป็นที่สำหรับวาง build แล้วคืนเมื่อเสร็จงาน แต่ก็ยังเป็นเซิร์ฟเวอร์ที่คุณต้องดูแลเอง ไม่ใช่เซิร์ฟเวอร์ที่ดูแลตัวเองได้

หนึ่งโปรเจกต์ หนึ่งรูปแบบ หนึ่งเครื่อง เครื่องที่ใช้เป็นคอนเทนเนอร์ sandbox แบบแชร์ ไม่ใช่เซิร์ฟเวอร์เฉพาะ มีหน่วยความจำใช้ได้ราว 2 GB ดังนั้นค่าสูงสุดแบบไม่จำกัดจึงวิ่งเข้าใกล้เพดานมากกว่าที่จะเป็นบนเครื่องที่ใหญ่กว่า ตัวเลขเหล่านี้ไม่ใช่ค่าคงที่สากล: ถ้า dependency tree ของคุณใหญ่กว่านี้สี่เท่า หรือ release profile เปิด link-time optimization ไว้ ให้คาดว่าจะได้ตัวเลขที่ต่างออกไป dependency tree ที่ใหญ่กว่า link-time optimization และโค้ดที่ใช้ generic หนัก ๆ สามารถดันหน่วยความจำตอน build ให้สูงขึ้นได้ อย่าถือว่าค่าที่ผมวัดได้เป็นเพดานสากล

ผมจัดเรื่องนี้ไว้ในหมวดวิธีทำงานของคุณ ไม่ใช่ว่าจะเรียนภาษานี้หรือไม่ รู้ไว้ก่อนที่จะเจอเข้ากับตัว

ใครควรเรียน Rust

มีสามสถานการณ์ที่ผมจะบอกให้คุณลงเวลาไป: ซอฟต์แวร์ที่ต้องอยู่นานซึ่งบั๊กหน่วยความจำมีราคาแพง งานที่อยู่ใกล้ระบบปฏิบัติการ และการอยากได้สิ่งที่การต่อสู้กับคอมไพเลอร์ทำกับวิธีคิดเรื่องหน่วยความจำของคุณ แต่ละอย่างมีเหตุผลที่เวลานั้นคุ้มค่า

คุณส่งงานด้วยภาษาอื่นอยู่แล้ว และกำลังสร้างสิ่งที่ต้องอยู่นานซึ่งบั๊กหน่วยความจำจะมีราคาแพง บริการที่ต้องออนไลน์ตลอด ไลบรารีที่ทีมอื่นพึ่งพา อะไรก็ตามที่ use-after-free หมายถึงการประชุมทบทวนเหตุขัดข้อง ไม่ใช่ stack trace ในเทอร์มินัลของคุณ นี่คือกรณีที่การรับประกันทั้งหมดถูกสร้างมาเพื่อมัน และสิ่งที่คุณจ่ายไปตอนต้นจะถูกเฉลี่ยตลอดอายุของสิ่งที่คุณสร้าง

คุณทำงานใกล้หรืออยู่ในซอฟต์แวร์ระดับระบบ ไดรเวอร์ งานด้านอุปกรณ์ ยูทิลิตีของระบบพื้นฐาน งาน embedded อะไรก็ตามที่อยู่ใต้ระบบปฏิบัติการแทนที่จะอยู่บนมัน อุตสาหกรรมทุ่มเทให้ส่วนนี้ในแบบที่ไม่ได้ทำที่อื่น และหลักฐานด้านความปลอดภัยของหน่วยความจำก็แข็งแรงที่สุดตรงนี้

คุณอยากได้ผลพลอยได้ ผู้แสดงความเห็นสองคนในเธรด r/rust นั้นเห็นต่างกันโดยสิ้นเชิงเรื่องคุณค่าต่ออาชีพของ Rust แต่มาลงเอยที่จุดเดียวกันตรงนี้ u/tyler_church, ซึ่งบอกว่ามันไม่มีผลต่ออาชีพเลย ยังยอมรับว่ามัน “อาจมีอิทธิพลแบบแนบเนียนต่อวิธีที่ผมเขียนโปรแกรมอื่นด้วยภาษาอื่น” u/SirKastic23, ซึ่งได้รับเงินจากการเขียน Rust มาสองปี บอกว่ามันขยายทักษะการเขียนโค้ดในแบบที่ไม่เคยคาดคิด แค่สองคน ไม่ใช่งานวิจัย แต่นี่คือผลตอบแทนที่ยังอยู่แม้คุณจะไม่เคยเขียน Rust เป็นอาชีพเลย: การเปลี่ยนวิธีคิด ไม่ใช่บรรทัดหนึ่งในเรซูเม่

ใครไม่ควรเรียน Rust

มีสามสถานการณ์ที่เวลานั้นควรใช้ไปกับอย่างอื่นดีกว่า: คุณมีเดดไลน์เดือนนี้ คุณกำลังเริ่มเรียนเขียนโปรแกรม หรือคุณเลือกภาษาจากจำนวนประกาศงานที่พูดถึงมัน ข้อที่สามคือข้อที่คนถามถึงมากที่สุด

คุณมีเดดไลน์เดือนนี้สำหรับแอป CRUD หรือต้นแบบ Rust มาในจังหวะที่ผิดที่สุดสำหรับงานที่ต้องเสร็จภายในวันศุกร์ Go คือตัวเลือกที่ชัดเจนแทน ถ้าคุณต้องการภาษาแบบคอมไพล์ที่ build เร็วและจัดการหน่วยความจำด้วย garbage collector และไม่ต้องการการรับประกันที่อิงกับ ownership ของ Rust

คุณกำลังเริ่มเรียนเขียนโปรแกรม เรื่องนี้แบ่งความเห็นของคนที่เขียน Rust หาเลี้ยงชีพจริง ๆ และข้อถกเถียงในเธรด r/rust ก็ไปทั้งสองทาง จุดยืนของผมจึงเป็นว่า การยื่นการโยนเหรียญให้มือใหม่เป็นคำแนะนำที่แย่ ไม่ว่าเหรียญจะออกหน้าไหน เรียนรู้ว่าเครื่องทำงานอย่างไรในที่ที่ให้อภัยมากกว่าก่อน แล้วค่อยกลับมาให้คอมไพเลอร์ช่วยขันให้แน่น

คุณเลือกภาษาจากจำนวนประกาศงานที่พูดถึงมัน ผมจะไม่ให้ตัวเลขตรงนี้ เพราะหาตัวเลขเงินเดือนหรือตำแหน่งงานของ Rust ที่สืบย้อนไปถึงแหล่งที่ผมกล้ายืนยันไม่ได้ สิ่งที่ u/crusoe อธิบายในเธรด r/rust นั้นคือตลาดที่มีตำแหน่งน้อยกว่าและเฉพาะทางกว่า นั่นเป็นความเห็นของคนคนเดียวในเธรดเดียว ไม่ใช่ข้อมูลตลาดแรงงาน ผมจึงจะไม่แปลงมันเป็นข้อกล่าวอ้างว่างาน Rust หายากโดยทั่วไป ถ้าปริมาณงานคือปัจจัยตัดสินของคุณ ให้ตรวจสอบประกาศงานปัจจุบันในตลาดเป้าหมายก่อนเลือกภาษา

คำถามที่พบบ่อย