ทีมพัฒนาภาษาโปรแกรมมิ่ง Roc ได้ประกาศแผนการเขียนคอมไพเลอร์ใหม่จาก Rust เป็น Zig ซึ่งก่อให้เกิดการถกเถียงอย่างกว้างขวางในชุมชนนักพัฒนาเกี่ยวกับการเลือกภาษาสำหรับการเขียนโปรแกรมระดับระบบ การตัดสินใจนี้เกิดขึ้นในช่วงที่ทีมกำลังเตรียมปล่อย Roc เวอร์ชันแรกคือ 0.1.0
ความกังวลเรื่องเวลาในการคอมไพล์นำไปสู่การเปลี่ยนแปลง
หัวใจสำคัญของการเปลี่ยนแปลงครั้งนี้มาจากจุดที่เป็นปัญหาสำคัญที่ส่งผลกระทบต่อชุมชนนักพัฒนา นั่นคือความเร็วในการคอมไพล์ การตอบสนองของชุมชนชี้ให้เห็นว่าการคอมไพล์ที่ช้าส่งผลกระทบอย่างมีนัยสำคัญต่อประสิทธิภาพและความพึงพอใจของนักพัฒนา ดังที่นักพัฒนาคนหนึ่งได้แสดงความเห็นว่า:
ผมใช้ Rust บ่อยมาก แต่ Roc พูดถูก: เวลาที่ใช้ในการคอมไพล์นั้นไม่ได้สัดส่วนกับความปลอดภัยที่ได้รับ อย่างน้อยก็ในโปรเจกต์ของผม
นอกเหนือจากความเร็ว: ข้อพิจารณาทางเทคนิค
การอภิปรายในชุมชนเผยให้เห็นว่านอกจากเวลาในการคอมไพล์แล้ว การตัดสินใจนี้ยังครอบคลุมถึงข้อพิจารณาทางเทคนิคที่กว้างขึ้น นักพัฒนาชี้ให้เห็นว่า Zig มีข้อได้เปรียบหลายประการสำหรับการพัฒนาคอมไพเลอร์ รวมถึงการจัดการ static linking ที่ดีกว่า การดำเนินการระดับบิตที่เข้าใจง่ายขึ้น และการจัดการหน่วยความจำที่ง่ายขึ้นผ่านการส่งผ่าน allocator อย่างชัดเจน ชุมชนเน้นย้ำถึงแนวทางที่เป็นประโยชน์ของ Zig ในการเขียนโปรแกรมระดับระบบ โดยวางตำแหน่งให้อยู่ระหว่างความเรียบง่ายของ C และความซับซ้อนของ Rust
เหตุผลหลักในการย้ายไปใช้ Zig:
- การคอมไพล์ที่เร็วขึ้น
- รองรับการลิงค์แบบสแตติกได้ดีขึ้น
- การจัดการข้อมูลในระดับบิตที่เข้าใจง่ายกว่า
- รูปแบบการจัดการหน่วยความจำที่เรียบง่ายกว่า
- สามารถสร้าง LLVM bitcode ได้โดยตรง
- รองรับ MultiArrayList สำหรับการเขียนโปรแกรมแบบ struct-of-arrays
บริบทของวิวัฒนาการภาษา
มุมมองที่น่าสนใจที่เกิดขึ้นจากการอภิปรายในชุมชนคือการเปลี่ยนแปลงของภูมิทัศน์ภาษาโปรแกรมมิ่งระดับระบบ ในขณะที่ Rust เป็นตัวเลือกที่เป็นธรรมชาติเมื่อคอมไพเลอร์ Roc ถูกเขียนขึ้นครั้งแรกในปี 2019 แต่ Zig ได้พัฒนาขึ้นอย่างมากนับตั้งแต่นั้น นักพัฒนาสังเกตว่านี่สะท้อนให้เห็นแนวโน้มที่กว้างขึ้นในอุตสาหกรรม ที่โครงการใหม่ๆ กำลังพิจารณาเลือก Zig สำหรับงานเขียนโปรแกรมระดับระบบมากขึ้น ซึ่งเมื่อไม่กี่ปีก่อนมักจะเลือก Rust โดยอัตโนมัติ
การเปลี่ยนแปลงที่วางแผนไว้สำหรับคอมไพเลอร์:
- การเขียนตัววิเคราะห์ไวยากรณ์ใหม่แบบ recursive descent
- ตัวจัดรูปแบบใหม่พร้อมการควบคุมความกว้างของบรรทัด
- ระบบการแก้ไขชื่อที่ได้รับการปรับปรุง
- การสร้างเอกสารประกอบที่เพิ่มประสิทธิภาพ
- การปรับปรุงการแปลงรูปแบบโดยไม่ใช้ Morphic
- การสร้างโค้ดใหม่บนพื้นฐานของ LLVM bitcode
- การเปลี่ยนแปลงแบ็กเอนด์สำหรับการพัฒนาไปเป็นตัวแปลความหมาย
การถกเถียงเรื่องการพัฒนา Parser
ประเด็นทางเทคนิคที่มีการโต้แย้งในชุมชนคือการตัดสินใจของทีมที่จะเปลี่ยนจาก parser combinators ไปเป็น recursive descent parsing ในขณะที่นักพัฒนาบางคนโต้แย้งว่า parser combinators นั้นก็คือ recursive descent ที่มีฟีเจอร์เพิ่มเติม คนอื่นๆ สนับสนุนการเปลี่ยนแปลงนี้ โดยอ้างถึงความสามารถในการจัดการข้อผิดพลาดที่ดีกว่าในพาร์เซอร์ที่เขียนด้วยมือ
การเขียนใหม่นี้แสดงให้เห็นถึงการเปลี่ยนแปลงที่สำคัญในภูมิทัศน์การเขียนโปรแกรมระดับระบบ ที่การพิจารณาในทางปฏิบัติเช่นความเร็วในการคอมไพล์และความสะดวกในการพัฒนากำลังท้าทายความสำคัญของความปลอดภัยในการจัดการหน่วยความจำในฐานะปัจจัยหลักในการเลือกภาษา
หมายเหตุทางเทคนิค:
- Parser combinators: เทคนิคการเขียนโปรแกรมเชิงฟังก์ชันสำหรับสร้างพาร์เซอร์โดยการรวมฟังก์ชันการแยกวิเคราะห์ขนาดเล็ก
- Recursive descent: เทคนิคการแยกวิเคราะห์แบบบนลงล่างที่แต่ละ non-terminal ในไวยากรณ์มีฟังก์ชันการแยกวิเคราะห์ของตัวเอง
- Static linking: กระบวนการที่ไลบรารีถูกรวมเข้าไปในไฟล์ปลายทางที่รันได้ ทำให้สามารถพกพาไปใช้งานบนระบบต่างๆ ได้ดีขึ้น