ชุมชนภาษาโปรแกรมมิ่ง Go กำลังถกเถียงกันอย่างดุเดือดเกี่ยวกับข้อเสนอใหม่ในการลดความซับซ้อนของการจัดการข้อผิดพลาดโดยใช้เครื่องหมาย '?' ซึ่งสะท้อนให้เห็นถึงความแตกแยกที่เพิ่มขึ้นระหว่างนักพัฒนาที่มีประสบการณ์และผู้เริ่มต้นใช้ภาษานี้
การจัดการข้อผิดพลาดแบบดั้งเดิมเทียบกับแบบสมัยใหม่
การอภิปรายเผยให้เห็นถึงความแตกแยกที่สำคัญในชุมชน Go เกี่ยวกับวิธีการจัดการข้อผิดพลาด นักพัฒนา Go ที่ใช้งานมานานคุ้นเคยและชื่นชอบรูปแบบ if err != nil ที่ชัดเจน ในขณะที่นักพัฒนาที่มาจากภาษาอื่นมักจะรู้สึกว่ามันยุ่งยากและซ้ำซาก ดังที่สมาชิกชุมชนคนหนึ่งกล่าวว่า:
หากคุณคุ้นเคยกับ exceptions และภาษาที่มีเครื่องหมาย '?' การพิมพ์
if err != nilตลอดเวลาอาจเป็นเรื่องที่ทรมาน แต่เมื่อคุณใช้ภาษานี้ไปสักพัก คุณจะเริ่มไม่ชอบระบบที่ซับซ้อนที่ภาษาอื่นๆ ใช้ในการปกปิดข้อผิดพลาด
ผลกระทบของข้อเสนอและความกังวลของชุมชน
การเปลี่ยนแปลงที่เสนอจะส่งผลกระทบต่อประมาณ 1.98% ของคำสั่งทั้งหมดใน standard library ของ Go ซึ่งถือเป็นการเปลี่ยนแปลงที่สำคัญในวิธีการเขียนและอ่านโค้ด Go สมาชิกชุมชนได้แสดงความกังวลหลายประการเกี่ยวกับข้อเสนอนี้ รวมถึงความสับสนที่อาจเกิดขึ้นกับผู้เริ่มต้น ความเสี่ยงที่จะพลาดการจัดการข้อผิดพลาดเนื่องจากสัญลักษณ์ '?' ที่มองเห็นได้ยาก และคำถามว่าการเปลี่ยนแปลงพื้นฐานเช่นนี้มีความจำเป็นหรือไม่เมื่อพิจารณาถึงเครื่องมือพัฒนาสมัยใหม่
สถิติสำคัญจากข้อเสนอ:
- มีการวิเคราะห์คำสั่งทั้งหมด 723,292 คำสั่งในไลบรารีมาตรฐาน
- สามารถแปลงเป็นไวยากรณ์ใหม่ได้ 14,304 คำสั่ง
- 1.98% ของคำสั่งทั้งหมดจะได้รับการเปลี่ยนแปลง
- 2,825 คำสั่ง (0.39%) จะใช้เครื่องหมาย ? โดยไม่มีบล็อกตัวเลือก
บริบทการพัฒนาสมัยใหม่
น่าสนใจที่นักพัฒนาบางคนชี้ให้เห็นว่า ด้วยการมาถึงของเครื่องมือพัฒนาที่ขับเคลื่อนด้วย AI และ copilots ภาระในการเขียนโค้ดที่เป็นแบบแผนได้ลดลงอย่างมาก ความก้าวหน้าทางเทคโนโลยีนี้ทำให้หลายคนตั้งคำถามว่าการเปลี่ยนแปลงไวยากรณ์เพื่อลดโค้ดที่ซ้ำซากยังมีความสำคัญเท่ากับเมื่อไม่กี่ปีที่ผ่านมาหรือไม่
ความน่าเชื่อถือทางเทคนิค
ข้อเสนอนี้มีน้ำหนักมากในชุมชน เนื่องจากมาจาก Ian Lance Taylor ซึ่งเป็นบุคคลสำคัญในการพัฒนา Go และมีบทบาทสำคัญในการนำ generics มาสู่ภาษานี้ พื้นฐานนี้ทำให้นักพัฒนาหลายคนพิจารณาข้อเสนอนี้อย่างจริงจัง แม้จะมีข้อสงสัยในตอนแรก
การถกเถียงยังคงดำเนินต่อไป โดยชุมชนกำลังชั่งน้ำหนักระหว่างประโยชน์ของการลดโค้ดที่ซ้ำซากกับหลักการของ Go ในเรื่องความเรียบง่ายและความชัดเจนในการจัดการข้อผิดพลาด
อ้างอิง: discussion: spec: reduce error handling boilerplate using ? #71460