ชุมชนโปรแกรมเมอร์กำลังถกเถียงกันอย่างดุเดือดเกี่ยวกับ async/await ฟีเจอร์ที่กลายเป็นส่วนสำคัญในภาษาโปรแกรมมิ่งสมัยใหม่ แม้ว่าในตอนแรกจะได้รับการยกย่องว่าเป็นทางออกของปัญหา callback hell แต่ฟีเจอร์นี้ก็ได้สร้างความขัดแย้งในหมู่นักพัฒนาที่เถียงว่ามันสร้างปัญหามากกว่าแก้ปัญหา
ปัญหาการระบุประเภทฟังก์ชัน
หนึ่งในข้อวิจารณ์ที่สำคัญที่สุดของ async/await คือปัญหาที่เรียกว่า function coloring ซึ่งเมื่อฟังก์ชันใช้ await มันจำเป็นต้องถูกกำกับด้วย async และข้อกำหนดนี้จะส่งผลไปตลอดทั้ง call stack การแพร่กระจายของเครื่องหมาย async นี้ได้กลายเป็นจุดปวดหัวสำหรับนักพัฒนา นำไปสู่ความยุ่งยากและความซับซ้อนของโค้ด
แนวทางทางเลือก
แนวทางการทำงานแบบขนานของ Go ได้รับความสนใจในฐานะทางเลือก แทนที่จะใช้ async/await, Go ใช้ goroutines และ channels โดยใช้หลักการที่เรียกว่า Communicating Sequential Processes (CSP) แนวทางนี้ช่วยให้นักพัฒนาสามารถเขียนโค้ดที่ดูเหมือนทำงานแบบซิงโครนัส ในขณะที่ runtime จัดการความซับซ้อนของการทำงานแบบขนาน
แนวทางหลักในการจัดการการทำงานแบบพร้อมกัน:
- Async/Await: การทำงานแบบ coroutine ที่ไม่ใช้ stack โดยมีการระบุเครื่องหมาย async อย่างชัดเจน
- แนวทางของ Go: การทำงานแบบ coroutine ที่ใช้ stack โดยมีการจัดการการทำงานพร้อมกันแบบแฝง
- CSP: การสื่อสารระหว่างกระบวนการที่ทำงานตามลำดับ
- Virtual Threads: แนวทางของ JVM ในการจัดการ thread แบบเบา
กรณีของ Stackful Coroutines
นักพัฒนาจำนวนมากเห็นว่า stackful coroutines ที่ใช้ใน Go ให้การทำงานที่ดีกว่า stackless coroutines ที่ใช้ในการทำงานแบบ async/await ส่วนใหญ่ ความแตกต่างสำคัญอยู่ที่วิธีที่ runtime จัดการบริบทการทำงาน แนวทางของ Go ช่วยให้นักพัฒนาสามารถเขียนโค้ดที่ตรงไปตรงมามากขึ้นโดยไม่ต้องระบุขอบเขต async อย่างชัดเจน ในขณะที่ยังคงรักษาประสิทธิภาพการทำงานแบบขนาน
ความท้าทายในการเขียนโปรแกรม UI
จุดสนับสนุนที่สำคัญสำหรับ async/await มาจากการเขียนโปรแกรม UI ในแอพพลิเคชัน GUI การบล็อก main thread จะทำให้อินเตอร์เฟซไม่ตอบสนอง async/await ให้วิธีที่สะอาดในการจัดการกับการทำงานเบื้องหลังในขณะที่รักษาการตอบสนองของ UI ทำให้มันมีคุณค่าอย่างยิ่งในการพัฒนา frontend และแอพพลิเคชันเดสก์ท็อป
คำถามเรื่องประสิทธิภาพ
การพัฒนาล่าสุด เช่น virtual threads ของ Java ได้ท้าทายข้อโต้แย้งด้านประสิทธิภาพที่มักใช้สนับสนุน async/await นักพัฒนาบางคนเถียงว่าความซับซ้อนที่เกิดจาก async/await ไม่คุ้มค่ากับประโยชน์ด้านประสิทธิภาพ โดยเฉพาะในแอพพลิเคชันธุรกิจทั่วไปที่การสลับบริบทแทบจะไม่ใช่คอขวด
บทสรุป
แม้ว่า async/await จะกลายเป็นฟีเจอร์มาตรฐานในภาษาโปรแกรมมิ่งสมัยใหม่หลายภาษา แต่การถกเถียงเกี่ยวกับข้อดีของมันยังคงดำเนินต่อไป การอภิปรายนี้ชี้ให้เห็นถึงความตึงเครียดที่กว้างขึ้นในการพัฒนาซอฟต์แวร์ระหว่างการทำให้เป็นนามธรรมกับความซับซ้อน และระหว่างแนวทางต่างๆ ในการจัดการกับการทำงานแบบขนาน เมื่อวงการนี้พัฒนาต่อไป เราอาจเห็นกระบวนทัศน์ใหม่ๆ ที่สร้างสมดุลระหว่างความต้องการที่แข่งขันกันเหล่านี้ได้ดีขึ้น