ในโลกของภาษาโปรแกรมมิ่ง Rust ได้รับการยกย่องในเรื่องประสิทธิภาพและคุณสมบัติด้านความปลอดภัย อย่างไรก็ตาม การอภิปรายที่เพิ่มขึ้นภายในชุมชนได้เน้นย้ำถึงแนวโน้มทางวัฒนธรรมที่มุ่งไปสู่การสร้างนามธรรมที่ซับซ้อน ซึ่งนักพัฒนาบางส่วนพบว่ามันท้าทายเกินไป การสนทนานี้触及到คำถามพื้นฐานเกี่ยวกับการออกแบบไลบรารี ความสามารถในการอ่านโค้ด และสิ่งที่ทำให้การเขียนโปรแกรมมีประสิทธิผล
ประสบการณ์การทำงานกับนามธรรมในทางปฏิบัติ
นักพัฒนา Rust หลายคนรายงานประสบการณ์ที่คล้ายกันเมื่อทำงานกับ crates ที่เป็นที่นิยม การเดินทางมักเริ่มต้นอย่างง่ายดาย – คุณต้องการทำงานเฉพาะอย่างหนึ่ง คุณจึงหยิบใช้ไลบรารีที่มีชื่อเสียงมา จากนั้นคุณก็กดคำสั่ง Go to Definition ในโปรแกรมแก้ไขของคุณ โดยคาดหวังว่าจะพบรายละเอียดการทำงานที่ตรงไปตรงมา แต่แทนที่จะเป็นอย่างนั้น คุณกลับพบว่าตัวเองกำลังสำรวจผ่านหลายชั้นของ traits, generics และการขยาย macros สิ่งที่ควรจะเป็นความเข้าใจอย่างรวดเร็วว่าฟังก์ชันทำงานอย่างไร กลับกลายเป็นการสำรวจเชิงสถาปัตยกรรม
รูปแบบนี้ไม่จำเป็นต้องเป็นเอกลักษณ์ของ Rust แต่ระบบชนิดข้อมูลและความสามารถในการสร้างนามธรรมอันทรงพลังของภาษาดูเหมือนจะส่งเสริมการออกแบบที่ซับซ้อนเป็นพิเศษ กฎ orphan rule ซึ่งป้องกันการนำ traits ภายนอกไปใช้กับ types ภายนอก บางครั้งก็บังคับให้นักพัฒนาสร้าง wrapper types ที่เพิ่มชั้นของการอ้างอิงทางอ้อม (indirection) เข้าไปอีก แม้นามธรรมเหล่านี้จะให้ประโยชน์ในด้านความยืดหยุ่นและประสิทธิภาพ แต่พวกมันก็สร้างภาระทางปัญญา (cognitive overhead) ที่สำคัญสำหรับนักพัฒนาที่พยายามจะทำความเข้าใจและแก้ไขจุดบกพร่องใน dependencies ของพวกเขาด้วย
ฉันใช้เวลามากขึ้นในการเรียนรู้และด่าทอนามธรรมของคนอื่น แทนที่จะคิดว่าคอมพิวเตอร์กำลังทำอะไรอยู่
การเปรียบเทียบชุมชนและอิทธิพลทางวัฒนธรรม
แนวทางการสร้างนามธรรมของชุมชน Rust ดึงดูดการเปรียบเทียบกับระบบนิเวศการเขียนโปรแกรมอื่นๆ ผู้แสดงความคิดเห็นหลายคนระบุถึงความคล้ายคลึงกับระบบนิเวศแพ็กเกจของ Haskell ซึ่งแนวคิดทางวิชาการที่ซับซ้อนบางครั้งส่งผลให้ไลบรารีรู้สึกเหมือนเป็นโครงการวิจัยมากกว่าที่จะเป็นเครื่องมือที่พร้อมใช้งานจริง (production-ready) คนอื่นๆ กล่าวถึงแนวโน้มในอดีตของ Scala ที่มุ่งไปสู่โครงสร้างการเขียนโปรแกรมเชิงฟังก์ชันที่ซับซ้อน ซึ่งให้ความสำคัญกับความบริสุทธิ์ (purity) มากกว่าการปฏิบัติจริง
ผู้สังเกตการณ์บางคนแนะนำว่า Rust ได้ดึงดูดนักพัฒนาจากชุมชนเหล่านี้ ซึ่งนำพาวัฒนธรรมที่ให้คุณค่ากับความสง่างามทางทฤษฎีและพลังแห่งการสร้างนามธรรมมาด้วย สิ่งนี้ไม่จำเป็นต้องเป็นด้านลบ – อิทธิพลเหล่านี้มีส่วนช่วยให้ระบบชนิดข้อมูลและการรับประกันความปลอดภัยของ Rust มีความซับซ้อน อย่างไรก็ตาม มันก็สร้างความตึงเครียดระหว่างปรัชญาการพัฒนาที่แตกต่างกันภายในระบบนิเวศเดียวกัน
การอภิปรายเปิดเผยว่านี่ไม่ใช่แค่เกี่ยวกับความสามารถทางเทคนิคของ Rust เท่านั้น แต่ยังเกี่ยวกับวัฒนธรรมการเขียนโปรแกรมในวงกว้างอีกด้วย การพัฒนาโอเพ่นซอร์สมักให้รางวัลกับโซลูชันที่ฉลาดและสร้างสรรค์ และคุณสมบัติอันทรงพลังของ Rust ก็ให้โอกาสอย่างมากสำหรับการแสดงออกอย่างสร้างสรรค์ คำถามจึงกลายเป็นว่าความสร้างสรรค์นี้ตอบสนองความต้องการในทางปฏิบัติหรือกลายเป็นจุดหมายในตัวของมันเอง
ผลกระทบในทางปฏิบัติต่อเวิร์กโฟลว์การพัฒนา
แนวทางที่เน้นนามธรรมอย่างหนักมีผลกระทบที่จับต้องได้ต่องานพัฒนาประจำวัน เวลาในการคอมไพล์อาจได้รับผลกระทบเมื่อทำงานกับโค้ดที่ใช้ generics อย่างหนัก เนื่องจากคอมไพเลอร์มีงานต้องทำมากขึ้นในการวิเคราะห์ trait bounds และสร้าง monomorphizing generics ขนาดของไฟล์ไบนารีอาจเพิ่มขึ้นเนื่องจาก template expansions และชั้นของนามธรรมทั้งหมด ที่สำคัญกว่า คือ เส้นโค้งการเรียนรู้ (learning curve) สำหรับนักพัฒนาใหม่จะสูงชันขึ้นเมื่อพวกเขาต้องเข้าใจไม่เพียงแต่โค้ดของตัวเองเท่านั้น แต่ยังต้องเข้าใจการทำงานภายในของไลบรารีที่ซับซ้อนอีกด้วย
ผู้แสดงความคิดเห็นบางคนชี้ไปที่ตัวอย่างเฉพาะ เช่น ไลบรารีการแยกวิเคราะห์คำสั่ง clap ซึ่งให้ความยืดหยุ่นอย่างมาก แต่แลกมาด้วยค่าใช้จ่ายด้านเวลาในการคอมไพล์ที่สำคัญ คนอื่นๆ กล่าวถึงความแตกแยก (fragmentation) ในระบบนิเวศ async ซึ่งไลบรารีต่างๆ กำหนดเวอร์ชันของตัวเองสำหรับอินเทอร์เฟซพื้นฐาน เช่น AsyncRead และ AsyncWrite ซึ่งต้องการ glue code เพื่อให้พวกมันทำงานร่วมกันได้
ระบบนิเวศของเครื่องมือเริ่มตอบสนองต่อความท้าทายเหล่านี้แล้ว cargo expand ช่วยให้นักพัฒนาเห็นโค้ดที่ขยายมาจาก macros และ rust-analyzer ให้การนำทางที่ดีขึ้นผ่านลำดับชั้นของ traits ที่ซับซ้อน อย่างไรก็ตาม เครื่องมือเหล่านี้แก้ไขอาการมากกว่าแนวทางการออกแบบพื้นฐานที่สร้างความซับซ้อนในตอนแรก
เครื่องมือชุมชนสำหรับจัดการความซับซ้อน:
cargo expand: ขยายมาโครเพื่อแสดงโค้ดพื้นฐาน- Rust-analyzer: การผสานรวม IDE เพื่อการนำทางโค้ดที่ดีขึ้น
cargo doc: สร้างเอกสารที่แสดงการใช้งาน trait
การทรงสมดุลระหว่างพลังและความปฏิบัติได้จริง
ท่ามกลางการวิจารณ์เรื่องการสร้างนามธรรมที่มากเกินไป นักพัฒนาหลายคนยอมรับถึงประโยชน์ที่ชอบด้วยกฎหมายของแนวทางของ Rust ความปลอดภัยของชนิดข้อมูล (type safety) ลักษณะประสิทธิภาพ และความสามารถในการแสดงออกที่มาพร้อมกับนามธรรมเหล่านี้ได้แก้ไขปัญหาจริงๆ ความท้าทายอยู่ที่การหาสมดุลที่เหมาะสมระหว่างนามธรรมอันทรงพลังและโค้ดที่ตรงไปตรงมาและบำรุงรักษาได้
crates บางตัวแสดงให้เห็นว่ามีทางเลือกอื่นอยู่ ไลบรารีคณิตศาสตร์ glam ได้รับการยกย่องซ้ำๆ สำหรับ API ที่ตรงไปตรงมา ซึ่งมุ่งเน้นการทำสิ่งเดียวให้ดีโดยไม่มี generics มากเกินไป ในทำนองเดียวกัน นักพัฒนาบางส่วนสนับสนุนแนวทางที่มุ่งเน้นรันไทม์ (runtime-oriented) ในกรณีที่การสร้างนามธรรมในเวลาคอมไพล์ให้ผลตอบแทนที่ลดลง
การอภิปรายของชุมชนชี้ให้เห็นว่าวิธีแก้ปัญหาไม่ใช่การละทิ้งนามธรรมทั้งหมด แต่เป็นการนำมันไปใช้อย่างรอบคอบมากขึ้น ผู้แสดงความคิดเห็นหลายคนเน้นย้ำถึงความสำคัญของการเขียนโค้ดที่ตอบสนองกรณีการใช้งานจริง มากกว่าความต้องการในอนาคตที่ยังเป็นเพียงสมมติฐาน หลักการ you aren't gonna need it (YAGNI) นั้นใช้ได้ดีเป็นพิเศษในสภาพแวดล้อมที่อุดมไปด้วยนามธรรมของ Rust
ในขณะที่ระบบนิเวศของ Rust เจริญเติบโต แบบแผน (patterns) อาจปรากฏขึ้นซึ่งสร้างสมดุลระหว่างพลังแห่งนามธรรมและความสามารถในการใช้งานจริงได้ดีขึ้น สำหรับตอนนี้ การสนทนาสะท้อนให้เห็นถึงชุมชนที่กำลังต่อสู้กับวิธีใช้ประโยชน์จากภาษาที่ทรงพลัง โดยไม่ปล่อยให้พลังนั้นทำให้งานง่ายๆ อย่างการทำงานให้เสร็จลุล่วงกลายเป็นเรื่องซับซ้อน ความหลากหลายของมุมมองชี้ให้เห็นว่านี่จะยังคงเป็นการอภิปรายที่ดำเนินต่อไปในขณะที่ Rust ยังคงวิวัฒนาการและหาตำแหน่งของมันในภูมิทัศน์การเขียนโปรแกรมที่กว้างขึ้น
อ้างอิง: Everybody's so Creative!