ชุมชนโปรแกรมเมอร์กำลังมีส่วนร่วมในการอภิปรายอย่างเข้มข้นเกี่ยวกับแนวคิดพื้นฐานในการพัฒนาซอฟต์แวร์ ซึ่งถูกจุดประกายโดยการใช้งาน async I/O ที่กำลังจะมาของ Zig การถกเถียงมีจุดศูนย์กลางอยู่ที่วิธีที่เรานิยามและแยกแยะระหว่าง asynchrony, concurrency และ parallelism - คำศัพท์ที่นักพัฒนาหลายคนใช้แทนกันได้ แต่อาจจะเป็นแนวคิดที่แตกต่างกันจริงๆ
ความขัดแย้งหลักเรื่องคำนิยาม
การอภิปรายเผยให้เห็นความแตกแยกอย่างมีนัยสำคัญในวิธีที่นักพัฒนาเข้าใจแนวคิดหลักเหล่านี้ สมาชิกชุมชนบางส่วนโต้แย้งว่าคำนิยามที่เสนอมานั้นมีประโยชน์เพื่อความชัดเจน ในขณะที่คนอื่นๆ เชื่อว่ามันสร้างความสับสนโดยไม่จำเป็น ความขัดแย้งเกิดจากการตีความที่แตกต่างกันว่าคำศัพท์เหล่านี้ควรหมายถึงอะไรในทางปฏิบัติ
ฝ่ายหนึ่งสนับสนุนการแยกแยะที่ชัดเจนยิ่งขึ้นระหว่าง asynchrony (งานที่สามารถทำงานไม่เป็นลำดับแต่ยังคงถูกต้อง), concurrency (ความสามารถของระบบในการดำเนินงานหลายๆ งานพร้อมกัน) และ parallelism (การทำงานพร้อมกันจริงๆ ในระดับฮาร์ดแวร์) อย่างไรก็ตาม นักวิจารณ์โต้แย้งว่าคำนิยามเหล่านี้ไม่สอดคล้องกับวรรณกรรมทางวิชาการที่ได้รับการยอมรับหรือการใช้งานจริงในภาษาโปรแกรมมิ่งที่มีอยู่
คำจำกัดความของศัพท์สำคัญ (ตามที่เสนอ)
- Asynchrony: ความเป็นไปได้ที่งานต่างๆ จะทำงานไม่เป็นไปตามลำดับแต่ยังคงให้ผลลัพธ์ที่ถูกต้อง
- Concurrency: ความสามารถของระบบในการดำเนินงานหลายๆ งานในเวลาเดียวกัน ผ่านการประมวลผลแบบขนาน หรือการสลับงาน
- Parallelism: ความสามารถในการประมวลผลงานมากกว่าหนึ่งงานพร้อมกันในระดับฮาร์ดแวร์
ความท้าทายในการนำไปใช้ในโลกจริง
การถกเถียงขยายไปเกินกว่าคำนิยามทางทฤษฎีไปสู่ข้อกังวลในการเขียนโปรแกรมจริง นักพัฒนาหลายคนชี้ให้เห็นว่าระบบนิเวศ async ปัจจุบันบังคับให้ผู้เขียนไลบรารีต้องทำโค้ดซ้ำ โดยสร้างเวอร์ชัน synchronous และ asynchronous แยกกันของฟังก์ชันเดียวกัน การทำซ้ำนี้นำไปสู่ระบบนิเวศที่แยกส่วน ซึ่งการเลือกใช้โค้ด async อาจทำให้นักพัฒนาไม่สามารถใช้ทางเลือก synchronous ได้
สมาชิกชุมชนเน้นจุดเจ็บปวดเฉพาะที่พวกเขาเคยพบ บางคนสังเกตว่าการเขียนโปรแกรม async มักจะแนะนำความซับซ้อนเหมือนกับการเขียนโปรแกรม concurrent ซึ่งต้องการการจัดการ shared state และ race condition ที่อาจเกิดขึ้นอย่างระมัดระวัง คนอื่นๆ โต้แย้งว่าโค้ด async ให้รูปแบบการทำงานที่กำหนดได้ ซึ่งทำให้การ debug ง่ายกว่าเมื่อเปรียบเทียบกับระบบ parallel
ปัญหาปัจจุบันของการเขียนโปรแกรมแบบ Async
- ผู้เขียน Library ต้องทำโค้ดซ้ำซ้อน (เช่น
async.readAllกับreadAll) - การพึ่งพา async เพียงตัวเดียวทำให้ codebase ทั้งหมดต้องกลายเป็น async
- ช่องทางหลบหนีอาจทำให้เกิด deadlock และพฤติกรรมที่ไม่เหมาะสม
- ระบบนิเวศที่แยกส่วนกันด้วย API แบบ sync/async ที่เข้ากันไม่ได้
แนวทางที่เสนอของ Zig ได้รับปฏิกิริยาที่หลากหลาย
แนวทางของ Zig มีเป้าหมายที่จะแก้ไขปัญหาเหล่านี้โดยการแยก asynchrony จาก concurrency ในระดับภาษา แนวคิดคือโค้ดที่ถูกทำเครื่องหมายว่า async ไม่จำเป็นต้องใช้การทำงาน concurrent โดยอัตโนมัติ - มันสามารถทำงานในโหมด single-threaded blocking เมื่อเหมาะสม การเลือกออกแบบนี้ได้สร้างทั้งความตื่นเต้นและความสงสัย
ผู้สนับสนุนมองว่านี่เป็นโซลูชันที่สง่างามซึ่งสามารถขจัด API ที่ซ้ำซ้อนและอนุญาตให้ใช้โค้ดซ้ำได้ดีขึ้น พวกเขาชื่นชมศักยภาพในการเขียนโค้ดครั้งเดียวและให้มันทำงานได้ทั้งในบริบท synchronous และ asynchronous โดยไม่ต้องแก้ไข
อย่างไรก็ตาม ผู้ที่สงสัยตั้งคำถามว่าแนวทางนี้จะทำงานได้จริงหรือไม่ โดยเฉพาะสำหรับผู้เขียนไลบรารีที่ไม่รู้บริบทการทำงานของโค้ดของพวกเขา บางคนกังวลเกี่ยวกับความซับซ้อนของการสนับสนุนการใช้งาน I/O หลายแบบและความยากลำบากในการทดสอบการรวมกันที่เป็นไปได้ทั้งหมด
มันค่อนข้างกล้าหาญที่เรียกแนวทางนี้ว่า 'ไม่มีการประนีประนอมใดๆ' ในขณะที่มันยังไม่ได้ถูกลองใช้ในป่าเถื่อน - คุณอาจจะอ้างสิ่งนี้ได้หลังจากการใช้งาน 1-2 ปีในระบบนิเวศที่กว้างขึ้น
ผลกระทบที่กว้างขึ้นต่อการออกแบบภาษาโปรแกรมมิ่ง
การอภิปรายนี้สะท้อนคำถามที่ใหญ่กว่าเกี่ยวกับวิธีที่ภาษาโปรแกรมมิ่งควรจัดการกับการดำเนินการ asynchronous ภาษาต่างๆ ได้ใช้แนวทางที่หลากหลาย ตั้งแต่ event loop ของ JavaScript ไปจนถึง goroutines ของ Go และโมเดล futures ของ Rust แต่ละแนวทางเกี่ยวข้องกับการแลกเปลี่ยนระหว่างประสิทธิภาพ ความง่ายในการใช้งาน และความชัดเจนของแนวคิด
การถกเถียงในชุมชนแสดงให้เห็นว่าไม่มีข้อตกลงสากลเกี่ยวกับแนวทางที่ดีที่สุด นักพัฒนาบางคนชอบ syntax async/await ที่ชัดเจนซึ่งทำเครื่องหมายขอบเขต asynchronous อย่างชัดเจน ในขณะที่คนอื่นๆ ชอบระบบที่ implicit มากกว่าซึ่งซ่อนความซับซ้อนจากโปรแกรมเมอร์
การอภิปรายยังเผยให้เห็นว่าคำศัพท์สามารถกลายเป็นอุปสรรคต่อการสื่อสารได้อย่างไร สมาชิกชุมชนหลายคนสังเกตว่าพวกเขาหยุดใช้คำศัพท์บางคำทั้งหมดเพราะทุกคนดูเหมือนจะมีคำนิยามที่แตกต่างกัน ทำให้การอภิปรายทางเทคนิคที่มีประสิทธิผลเป็นเรื่องยาก
บทสรุป
ในขณะที่ชุมชนโปรแกรมมิ่งยังคงถกเถียงแนวคิดพื้นฐานเหล่านี้ การอภิปรายนั้นเองเน้นย้ำถึงวิวัฒนาการที่กำลังดำเนินอยู่ของวิธีที่เราคิดเกี่ยวกับการเขียนโปรแกรม concurrent และ asynchronous แนวทางการทดลองของ Zig อาจให้ข้อมูลเชิงลึกที่มีค่า โดยไม่คำนึงว่าในที่สุดมันจะประสบความสำเร็จหรือไม่ การถกเถียงแสดงให้เห็นว่าแม้แต่นักพัฒนาที่มีประสบการณ์ก็ไม่เห็นด้วยกับคำศัพท์พื้นฐานเสมอไป ซึ่งแสดงให้เห็นว่าคำนิยามที่ชัดเจนกว่าและทรัพยากรการศึกษาที่ดีกว่าอาจเป็นประโยชน์ต่อชุมชนโปรแกรมมิ่งทั้งหมด
ผลลัพธ์ของการใช้งาน async I/O ของ Zig น่าจะมีอิทธิพลต่อวิธีที่ภาษาอื่นๆ เข้าหาความท้าทายที่คล้ายกันในอนาคต ทำให้เรื่องนี้เป็นมากกว่าแค่การอภิปรายทางวิชาการเกี่ยวกับคำนิยาม
อ้างอิง: Asynchrony is not Concurrency