การวิจารณ์อย่างละเอียดเกี่ยวกับภาษา Go programming language ได้จุดประกายการถกเถียงอย่างรุนแรงในชุมชนนักพัฒนา โดยเน้นย้ำถึงปัญหาที่ยังคงมีอยู่และรบกวนภาษานี้มานานกว่าทศวรรษ การอภิปรายครั้งนี้มุ่งเน้นไปที่การตัดสินใจในการออกแบบพื้นฐานที่นักวิจารณ์โต้แย้งว่าสามารถหลีกเลี่ยงได้และเกิดจากบทเรียนที่ชุมชนการเขียนโปรแกรมได้เรียนรู้มาแล้ว
ปัญหาการจัดการข้อผิดพลาดและขอบเขตตัวแปร
หนึ่งในประเด็นที่ถกเถียงกันมากที่สุดเกี่ยวข้องกับกลไกการจัดการข้อผิดพลาดของ Go และกฎขอบเขตตัวแปร ภาษานี้บังคับให้นักพัฒนาตกอยู่ในสถานการณ์ที่อึดอัดใจ โดยตัวแปรข้อผิดพลาดยังคงอยู่ในขอบเขตนานกว่าที่จำเป็น ทำให้เกิดความสับสนและข้อบกพร่องที่อาจเกิดขึ้นได้ ไม่เหมือนกับภาษาอื่นๆ ที่อนุญาตให้ควบคุมอายุการใช้งานของตัวแปรได้อย่างแม่นยำมากกว่า ข้อจำกัดทางไวยากรณ์ของ Go ป้องกันไม่ให้นักพัฒนาลดขอบเขตตัวแปรในรูปแบบทั่วไปบางอย่าง การเลือกออกแบบนี้ทำให้โค้ดอ่านยากขึ้นและมีแนวโน้มที่จะเกิดข้อผิดพลาดที่ละเอียดอ่อนมากขึ้น โดยเฉพาะเมื่อนักพัฒนาใช้ตัวแปรข้อผิดพลาดซ้ำโดยไม่ตั้งใจหรืออ้างอิงตัวแปรเหล่านั้นนอกบริบทที่ตั้งใจไว้
ข้อวิจารณ์หลักต่อภาษา Go :
- การจัดการข้อผิดพลาด: ปัญหาการบังคับขอบเขตตัวแปรในรูปแบบการจัดการข้อผิดพลาด
- ประเภท Nil: มี nil สองประเภทที่แตกต่างกัน (แบบมีประเภทกับแบบไม่มีประเภท) ทำให้เกิดความไม่สอดคล้องในการเปรียบเทียบ
- การจัดการหน่วยความจำ: ปัญหาความไม่แน่นอนของ garbage collector และการแตกเป็นส่วนย่อยของหน่วยความจำ
- ความสามารถในการพกพา: ระบบ build tag ที่ใช้คอมเมนต์ในไฟล์สร้างปัญหาในการบำรุงรักษา
- กลไก Defer: การทำความสะอาดทรัพยากรที่มีขอบเขตระดับฟังก์ชันแทนที่จะเป็นขอบเขตเชิงคำศัพท์
- การจัดการสตริง: การตรวจสอบ UTF-8 ที่ไม่สอดคล้องกันนำไปสู่การสูญเสียข้อมูลที่อาจเกิดขึ้น
ปัญหา Nil สองประเภท
การจัดการค่า nil ของ Go นำเสนอความท้าทายที่สำคัญอีกประการหนึ่ง ภาษานี้มี nil สองประเภทที่แตกต่างกัน - แบบมีชนิดและแบบไม่มีชนิด - ซึ่งทำงานแตกต่างกันในการเปรียบเทียบและอาจนำไปสู่การหยุดทำงานแบบไม่คาดคิดขณะรันไทม์ ปัญหานี้เกิดขึ้นเมื่อตัวแปร interface มี nil pointer ทำให้เกิดสถานการณ์ที่ตัวแปรอาจไม่เท่ากับ nil ในการเปรียบเทียบ แต่ยังคงทำให้เกิด null pointer dereference เมื่อมีการเรียกใช้เมธอด สมาชิกชุมชนรายงานว่าพบปัญหานี้ในโค้ดที่ใช้งานจริง ซึ่งอาจยากต่อการตรวจพบระหว่างการตรวจสอบโค้ด
ข้อกังวลเรื่องการจัดการหน่วยความจำและความสามารถในการพกพา
พฤติกรรมของ garbage collector ของภาษานี้ได้รับคำวิจารณ์จากนักพัฒนาที่ทำงานกับแอปพลิเคชันที่มีข้อจำกัดด้านหน่วยความจำ สมาชิกชุมชนบางคนรายงานว่าต้องต่อสู้กับภาษาเมื่อพยายามลดการใช้หน่วยความจำให้น้อยที่สุด โดยเฉพาะในสถานการณ์ที่ต้องการการควบคุมหน่วยความจำอย่างแม่นยำ พฤติกรรมที่คาดเดาไม่ได้ของ garbage collector อาจนำไปสู่การกระจายตัวของหน่วยความจำและการล้างข้อมูลที่ล่าช้า บังคับให้นักพัฒนาต้องใช้วิธีแก้ปัญหาเฉพาะหน้าเช่น buffer ที่จัดสรรล่วงหน้าและกลยุทธ์การจัดการหน่วยความจำแบบกำหนดเอง
ปัญหาความสามารถในการพกพายังรบกวนการออกแบบของ Go โดยเฉพาะเรื่องการคอมไพล์แบบมีเงื่อนไขโดยใช้ build tag นักวิจารณ์โต้แย้งว่าแนวทางนี้ซึ่งอาศัยความคิดเห็นพิเศษที่ด้านบนของไฟล์ สร้างฝันร้ายในการบำรุงรักษาสำหรับโค้ดข้ามแพลตฟอร์มเมื่อเปรียบเทียบกับแนวทางที่ทันสมัยกว่าที่ใช้โดยภาษาอื่นๆ
การตอบสนองของชุมชนและมุมมองทางเลือก
ชุมชนนักพัฒนายังคงแบ่งแยกเกี่ยวกับคำวิจารณ์เหล่านี้ ผู้สนับสนุนโต้แย้งว่าความเรียบง่ายและประโยชน์ด้านประสิทธิภาพของ Go มีน้ำหนักมากกว่าข้อบกพร่องในการออกแบบ โดยเฉพาะสำหรับการพัฒนาฝั่งเซิร์ฟเวอร์และบริการ API นักพัฒนาหลายคนชื่นชมเวลาคอมไพล์ที่รวดเร็วของ Go ไลบรารีมาตรฐานที่แข็งแกร่ง และเครื่องมือจัดรูปแบบที่สม่ำเสมอซึ่งขจัดข้อพิพาททั่วไปในทีมหลายๆ อย่าง
Go เป็นภาษาที่มีประสิทธิภาพพอสมควรที่ทำให้การเขียนบริการที่เชื่อถือได้และรองรับการทำงานพร้อมกันสูงเป็นเรื่องตรงไปตรงมาโดยไม่ต้องพึ่งพา multithreading ที่หนักหน่วง - ทั้งหมดนี้ต้องขอบคุณโมเดล goroutine
อย่างไรก็ตาม นักวิจารณ์โต้แย้งว่าประโยชน์เหล่านี้มาพร้อมกับต้นทุนของการใช้งานสำหรับนักพัฒนาและความปลอดภัยของชนิดข้อมูล บางคนแนะนำว่าภาษาเช่น Rust, Java ที่มี virtual thread หรือแม้แต่ทางเลือกใหม่ๆ อาจให้โซลูชันที่ดีกว่าสำหรับความต้องการการพัฒนาสมัยใหม่
ภาษาทางเลือกที่ได้รับการกล่าวถึง:
- Rust: ความปลอดภัยของประเภทข้อมูลและการจัดการหน่วยความจำที่ดีกว่า
- Java: ได้รับการปรับปรุงด้วย virtual threads และ modern GC
- Elixir: โมเดลการทำงานพร้อมกันที่เหนือกว่าสำหรับกรณีการใช้งานบางประเภท
- C: ความสมดุลที่ดีระหว่างฟีเจอร์และการสนับสนุนในระดับองค์กร
- Zig: ทางเลือกระดับต่ำกว่าที่มีการแยกแยะที่ดีกว่า
- Carbon: ภาษาที่อยู่ระหว่างการพัฒนาสำหรับความสามารถในการทำงานร่วมกับ C++
บริบทที่กว้างขึ้น
การถกเถียงสะท้อนความตึงเครียดที่ใหญ่กว่าในการออกแบบภาษาโปรแกรมระหว่างความเรียบง่ายและการแสดงออก ในขณะที่ผู้สร้าง Go เลือกความเรียบง่ายมากกว่าความหลากหลายของฟีเจอร์อย่างมีเจตนา นักวิจารณ์โต้แย้งว่าปรัชญานี้บางครั้งส่งผลให้ความซับซ้อนถูกผลักไปยังนักพัฒนาแทนที่จะขจัดมัน ความมุ่งมั่นของภาษาต่อความเข้ากันได้ย้อนหลังยังหมายความว่าปัญหาพื้นฐานหลายๆ อย่างเหล่านี้ไม่สามารถแก้ไขได้โดยไม่ทำลายโค้ดที่มีอยู่
ขณะที่ภูมิทัศน์การเขียนโปรแกรมยังคงพัฒนาต่อไป ชุมชน Go เผชิญกับคำถามอย่างต่อเนื่องเกี่ยวกับการแลกเปลี่ยนของภาษายังคงเหมาะสมสำหรับความท้าทายในการพัฒนาซอฟต์แวร์สมัยใหม่หรือไม่ ในขณะที่ Go ยังคงได้รับการยอมรับอย่างกว้างขวาง โดยเฉพาะในโครงสร้างพื้นฐานคลาวด์และไมโครเซอร์วิส คำวิจารณ์ที่ยังคงมีอยู่เหล่านี้ชี้ให้เห็นว่านักพัฒนาคาดหวังฟีเจอร์ภาษาที่ซับซ้อนมากขึ้นและการใช้งานที่ดีขึ้นจากเครื่องมือของพวกเขามากขึ้น
อ้างอิง: Go is still not good