ระบบนิเวศของ Rust ได้ต้อนรับเฟรมเวิร์กใหม่ชื่อ Shelgon ซึ่งออกแบบมาสำหรับการสร้างแอปพลิเคชัน REPL (Read-Eval-Print Loop) แบบโต้ตอบและเชลล์แบบกำหนดเอง แม้ว่าเฟรมเวิร์กนี้จะนำเสนอฟีเจอร์ที่น่าสนใจ เช่น การประมวลผลคำสั่งแบบ type-safe และความสามารถด้าน UI ขั้นสูงบนเทอร์มินัล แต่การสนทนาในชุมชนได้มุ่งเน้นไปที่ทางเลือกด้านสถาปัตยกรรม โดยเฉพาะเรื่องการใช้งาน async runtime และวิธีการจัดการข้อผิดพลาด
คุณสมบัติหลักของ Shelgon Framework
- การประมวลผลคำสั่งที่ปลอดภัยด้านประเภทข้อมูล (Type-safe)
- การรวมระบบ Async Runtime (ปัจจุบันใช้ Tokio เป็นฐาน)
- ความสามารถด้าน TUI ขับเคลื่อนโดย ratatui
- การจัดการอินพุตที่หลากหลาย รวมถึง:
- ประวัติคำสั่ง
- การเคลื่อนที่ของเคอร์เซอร์
- การเติมคำอัตโนมัติด้วยแท็บ
- การจัดการ Ctrl+C/Ctrl+D
- รองรับบริบทที่กำหนดเอง
- สนับสนุน STDIN สำหรับอินพุตหลายบรรทัด
การพึ่งพา Async Runtime จุดประเด็นถกเถียง
การตัดสินใจของเฟรมเวิร์กที่ผูกติดกับ Tokio เป็น async runtime ได้สร้างการถกเถียงอย่างมากในกลุ่มผู้ใช้ที่มีศักยภาพ นักพัฒนาหลายคนตั้งคำถามว่าทำไมฟังก์ชัน async จึงเป็นข้อกำหนดหลักแทนที่จะเป็นฟีเจอร์ทางเลือก ความเห็นหนึ่งที่น่าสนใจได้เน้นย้ำถึงความกังวลเกี่ยวกับการบังคับให้ผู้ใช้ต้องใช้ runtime เฉพาะ:
ทำไมผมต้องเพิ่ม tokio เป็นการพึ่งพาด้วยถ้าผมไม่ได้ใช้มัน?
ความรู้สึกนี้สะท้อนถึงความชอบในวงกว้างของชุมชน Rust ที่ต้องการให้ไลบรารีไม่ยึดติดกับ runtime ใดๆ หรือมีทางเลือกแบบซิงโครนัส ผู้สร้างเฟรมเวิร์กที่รู้จักในชื่อ cat-whisperer ได้รับทราบข้อกังวลเหล่านี้ โดยอธิบายว่าการใช้งานปัจจุบันช่วยให้ผู้ใช้สามารถบล็อกหรือจัดการการทำงานโดยการส่งผ่าน runtime ซึ่งให้นักพัฒนาควบคุมการทำงานพร้อมกันได้ พวกเขายังกล่าวถึงการพิจารณาทำให้การสนับสนุน async เป็นฟีเจอร์ที่เลือกใช้ได้ในเวอร์ชันอนาคต
วิธีการจัดการข้อผิดพลาดถูกตั้งคำถาม
ประเด็นขัดแย้งอีกจุดหนึ่งคือการที่ Shelgon ใช้เครต anyhow สำหรับการจัดการข้อผิดพลาดใน API สาธารณะ นักพัฒนาหลายคนแนะนำว่าไลบรารีควรกำหนดประเภทข้อผิดพลาดของตัวเองหรือใช้ thiserror แทนที่จะพึ่งพา anyhow ซึ่งโดยทั่วไปถือว่าเหมาะสมกับโค้ดแอปพลิเคชันมากกว่าไลบรารี ผู้สร้างตอบว่าแม้พวกเขาวางแผนที่จะใช้ thiserror และ error-stack ในการอัปเดตในอนาคต แต่พวกเขาเลือก anyhow ในตอนแรกเพราะมันให้อินเทอร์เฟซที่ง่ายกว่าซึ่งช่วยให้ผู้ใช้สามารถมุ่งเน้นไปที่ตรรกะของโดเมนมากกว่าการจัดการข้อผิดพลาด
การร้องขอการสาธิตด้วยภาพ
แม้ว่า Shelgon จะโฆษณาความสามารถ TUI ที่สวยงามซึ่งขับเคลื่อนโดยเครต ratatui แต่ผู้แสดงความคิดเห็นหลายคนสังเกตเห็นว่าไม่มีภาพหน้าจอหรือวิดีโอที่แสดงคุณสมบัติเหล่านี้ ผู้ใช้หลายคนขอตัวอย่างภาพ พร้อมคำแนะนำให้ใช้เครื่องมือเช่น asciinema เพื่อแสดงความสามารถของอินเทอร์เฟซของเฟรมเวิร์ก ข้อเสนอแนะนี้เน้นย้ำถึงความสำคัญของการสาธิตด้วยภาพเมื่อส่งเสริมไลบรารีที่เน้นด้าน UI
ความกังวลของชุมชน
- Async Runtime: มีคำถามเกี่ยวกับการบังคับใช้ Tokio dependency
- Error Handling: การใช้ anyhow แทนที่จะเป็น error types เฉพาะของไลบรารี
- เอกสารประกอบ: ขาดตัวอย่างที่เป็นภาพประกอบแม้ว่าจะเน้นที่ UI
- การตั้งชื่อ: มีความกังวลบางประการเกี่ยวกับการใช้ชื่อโปเกมอน ( Shelgon )
การเปรียบเทียบกับโซลูชันที่มีอยู่
การสนทนายังกล่าวถึงว่า Shelgon เปรียบเทียบกับทางเลือกที่มีอยู่แล้วในระบบนิเวศของ Rust อย่างไร เช่น rustyline และ reedline ผู้สร้างยอมรับว่า rustyline มีการสนับสนุนอย่างกว้างขวางสำหรับการโต้ตอบกับผู้ใช้ แต่อธิบายว่า Shelgon มุ่งที่จะให้การลดทอนที่มีข้อจำกัดมากขึ้นแต่มีพลังมากขึ้นผ่านวิธีการที่ใช้ trait ซึ่งช่วยให้มีการควบคุมที่แม่นยำเกี่ยวกับแง่มุมของเชลล์ในขณะที่ยังคงรักษาความสามารถในการแบ่งปันสถานะ
ขณะที่ Shelgon ยังคงพัฒนาต่อไป ผู้สร้างดูเหมือนจะเปิดรับข้อเสนอแนะจากชุมชน แสดงถึงการเปิดกว้างต่อการมีส่วนร่วมและบ่งชี้ว่าเฟรมเวิร์กยังคงอยู่ในการพัฒนาอย่างต่อเนื่อง สำหรับนักพัฒนาที่สนใจในการสร้างสภาพแวดล้อม REPL แบบกำหนดเองใน Rust นั้น Shelgon เป็นตัวเลือกใหม่ที่น่าสนใจ แม้ว่าทางเลือกด้านสถาปัตยกรรมอาจมีอิทธิพลต่อการนำไปใช้ขึ้นอยู่กับว่าสอดคล้องกับความต้องการของโปรเจกต์ต่างๆ อย่างไร
อ้างอิง: Shelgon: A Rust Framework for Building Interactive REPL Applications