ภาษาโปรแกรม Zig กำลังปรับปรุงระบบ I/O ครั้งใหญ่ โดยเปิดตัวอินเทอร์เฟซ Writer ใหม่ที่จุดประกายการถกเถียงอย่างเข้มข้นในหมู่นักพัฒนา การออกแบบใหม่นี้แตกต่างอย่างมากจากแนวทางแบบดั้งเดิม โดยสร้าง buffering เข้าไปในอินเทอร์เฟซ Writer โดยตรง แทนที่จะถือว่าเป็นชั้นแยกต่างหากของการประกอบ
ปรัชญาการออกแบบหลักแบ่งแยกชุมชน
อินเทอร์เฟซ std.lo.Writer ใหม่กำหนดให้การใช้งานต้องมีฟังก์ชัน drain ที่จัดการกับอาร์เรย์ของ byte slices และรวมความสามารถ buffering ในตัว แนวทางนี้มีเป้าหมายเพื่อปรับปรุงประสิทธิภาพโดยเปิดใช้งาน vectored I/O operations และขจัดความจำเป็นในการใช้ buffered wrapper types แยกต่างหาก อย่างไรก็ตาม การเลือกออกแบบนี้ได้สร้างการแบ่งแยกพื้นฐานในชุมชนนักพัฒนาเกี่ยวกับว่าการรวมดังกล่าวเป็นประโยชน์หรือเป็นปัญหา
นักวิจารณ์โต้แย้งว่าการรวม buffered และ unbuffered operations เข้าไว้ในอินเทอร์เฟซเดียวกันสร้างความสับสนและปัญหาความถูกต้องที่อาจเกิดขึ้น ความกังวลมุ่งเน้นไปที่ข้อเท็จจริงที่ว่า buffered และ unbuffered writers มีพฤติกรรมที่แตกต่างกันโดยพื้นฐานในสถานการณ์จริง โดยเฉพาะเกี่ยวกับการรับประกันเวลาและการมองเห็นข้อมูล
ข้อกำหนดสำหรับ Writer Interface ใหม่:
- การ implement ต้องมีฟังก์ชัน
drainที่มี signature:fn drain(w: *Writer, data: []const []const u8, splat: usize) Error!usize - รองรับการ buffering แบบ built-in ผ่านพารามิเตอร์ buffer:
var writer = my_file.writer(&buffer) - สามารถทำงานแบบ unbuffered ได้โดยใช้ buffer เปล่า:
var writer = my_file.writer(&.{}) - เข้าถึง interface ผ่าน convention ของฟิลด์
.interface
ความกังวลเรื่องความถูกต้องกับอินเทอร์เฟซแบบรวม
ส่วนสำคัญของการถกเถียงในชุมชนมุ่งเน้นไปที่ความถูกต้องของอัลกอริทึมเมื่อพฤติกรรม buffering ถูกซ่อนไว้ นักพัฒนาได้แบ่งปันประสบการณ์ที่อัลกอริทึมที่ทำงานได้อย่างถูกต้องกับ unbuffered writers สามารถล้มเหลวอย่างเงียบๆ กับ buffered ones โดยเฉพาะในสถานการณ์ที่เกี่ยวข้องกับการสื่อสารเครือข่าย ระบบ logging และแอปพลิเคชันแบบ multi-threaded
จากประสบการณ์ส่วนตัวของฉัน buffered และ unbuffered writers แตกต่างกันมากพอที่ฉันคิดว่าการทำให้พวกมันแยกแยะไม่ได้ในระบบ type นั้นเป็นความผิดพลาดเล็กน้อย
ผลกระทบด้านเวลามีความกังวลเป็นพิเศษสำหรับระบบเรียลไทม์และแอปพลิเคชันเซิร์ฟเวอร์ที่ response latency มีความสำคัญ เมื่อ buffering ถูกซ่อนไว้หลัง abstraction นักพัฒนาอาจแนะนำ performance bottlenecks หรือ correctness bugs โดยไม่ตั้งใจ ซึ่งจะปรากฏเฉพาะภายใต้เงื่อนไขเฉพาะเจาะจง
ความซับซ้อนของการใช้งานและการแลกเปลี่ยนประสิทธิภาพ
การออกแบบใหม่กำหนดให้ทุก Writer implementation ต้องจัดการกับ vectored I/O operations, buffering logic และฟีเจอร์การปรับปรุงเช่น splat operations สำหรับสถานการณ์การบีบอัด สิ่งนี้เพิ่มความซับซ้อนอย่างมากให้กับสิ่งที่เคยเป็นอินเทอร์เฟซที่เรียบง่าย ในขณะที่ทีม Zig โต้แย้งว่าสิ่งนี้เปิดโอกาสการปรับปรุงที่ดีกว่า นักพัฒนาบางคนตั้งคำถามว่า overhead ที่เพิ่มขึ้นนั้นคุ้มค่าหรือไม่
เส้นทางการย้ายข้อมูลยังนำเสนอความท้าทาย เนื่องจากโค้ดที่มีอยู่ต้องปรับตัวให้เข้ากับอินเทอร์เฟซใหม่ผ่านวิธีการความเข้ากันได้เช่น adaptToNewApi() สิ่งนี้สร้างภาระชั่วคราวแต่สำคัญสำหรับผู้ดูแลไลบรารีและนักพัฒนาแอปพลิเคชัน
ความท้าทายในการย้ายระบบ:
- ฟังก์ชันเดิมอย่าง
std.fmt.formatintBufถูกลบออก และถูกแทนที่ด้วยเมธอด Writer - ต้องใช้ฟังก์ชัน
Writer.fixed([]u8)ใหม่สำหรับการดำเนินการที่ใช้บัฟเฟอร์ - Writer ที่มีอยู่เดิมต้องใช้เมธอด
adaptToNewApi()เพื่อความเข้ากันได้ - การใช้งาน File Writer ขยายเป็นประมาณ 150 บรรทัด พร้อมการปรับแต่งเฉพาะแพลตฟอร์ม
แนวทางทางเลือกและผลกระทบในอนาคต
หลายคนในชุมชนสนับสนุนโซลูชันแบบ composition-based ที่คล้ายกับที่ใช้ในภาษาโปรแกรมอื่นๆ ที่ buffering ถูกนำไปใช้ผ่าน wrapper types แทนที่จะสร้างเข้าไปในอินเทอร์เฟซหลัก แนวทางนี้จะรักษาการแยกที่ชัดเจนระหว่างพฤติกรรม I/O ที่แตกต่างกัน ในขณะที่ยังคงอนุญาตให้มีการปรับปรุงในกรณีเฉพาะ
การถกเถียงสะท้อนคำถามที่กว้างขึ้นเกี่ยวกับปรัชญาการออกแบบของ Zig และว่าภาษานี้ควรให้ความสำคัญกับการปรับปรุงประสิทธิภาพมากกว่าความเรียบง่ายของอินเทอร์เฟซหรือไม่ เมื่อการปรับปรุง I/O ดำเนินต่อไปและฟังก์ชัน async ถูกนำกลับมาใช้ใหม่ การตัดสินใจออกแบบเหล่านี้น่าจะมีอิทธิพลต่อวิธีที่ Zig จัดการกับ system-level abstractions อื่นๆ
ชุมชนยังคงแบ่งแยกเกี่ยวกับว่าสิ่งนี้แสดงถึงการเขียนโปรแกรมระบบที่นวัตกรรมหรือโซลูชันที่ซับซ้อนเกินไปสำหรับปัญหาที่แก้ไขได้ดีกว่าผ่านรูปแบบ composition แบบดั้งเดิม ความสำเร็จสูงสุดของแนวทางนี้น่าจะขึ้นอยู่กับผลกำไรด้านประสิทธิภาพในโลกจริงและรูปแบบการยอมรับของนักพัฒนาเมื่ออินเทอร์เฟซใหม่เติบโตขึ้น
อ้างอิง: Zig's new Writer