-
ผู้เขียนเป็นตุ่นปากเป็ด
- การปัดคำวิจารณ์ทิ้งด้วยการมองว่าผู้เขียนไร้ความสามารถเป็นวิธีที่ขี้เกียจ
- นักพัฒนาระดับจูเนียร์สามารถมองปัญหาจากมุมใหม่ได้ และนี่คือเหตุผลสำคัญอย่างหนึ่งของการจ้างงาน
- ผู้เขียนไม่ใช่นักพัฒนาจูเนียร์ และมีความเข้าใจด้านการออกแบบภาษาจากประสบการณ์ที่หลากหลาย
-
แม่สูบบุหรี่ ดังนั้นมันก็น่าจะไม่เป็นไร
- การทำตามเทคโนโลยีที่บริษัทอื่นใช้แบบไม่ลืมหูลืมตาเป็นเรื่องไม่มีประสิทธิภาพ
- บล็อกเทคโนโลยีมีเป้าหมายเพื่อทำให้ภาพลักษณ์ของบริษัทดูดีขึ้น
- บล็อกของ Tailscale ค่อนข้างตรงไปตรงมา แต่ก็ยังต้องใช้ความพยายามอย่างมากในการแก้ปัญหาของ Go
-
ส่วนที่ดี
- Go มี asynchronous runtime และ garbage collector ที่ยอดเยี่ยม
- เครื่องมืออย่างการจัดการแพ็กเกจ การรีแฟกเตอร์ และการคอมไพล์ข้ามแพลตฟอร์มใช้งานง่าย
- อย่างไรก็ตาม ข้อเสียของ Go ไม่อาจมองข้ามได้ และปัญหาคือการออกแบบภาษาดูเหมือนเกิดขึ้นอย่างบังเอิญ
-
Go คือเกาะโดดเดี่ยว
- Go ขาดความสามารถในการทำงานร่วมกับภาษาอื่น
- toolchain ของ Go มีความเฉพาะตัวมาก และไม่สามารถใช้ภาษาแอสเซมบลีหรือดีบักเกอร์แบบเดิมได้
- วิธีที่ง่ายที่สุดในการผสานรวมกับ Go คือผ่านขอบเขตของเครือข่าย
-
ทั้งหมดหรือไม่ก็ไม่เอาเลย (และสุดท้ายก็ไม่ทำอะไรเลย)
- Go ปล่อยให้มีฟิลด์ของ struct ที่ไม่ได้ initialize ได้
- การคิดว่าค่า zero value มีความหมายเสมอเป็นความคิดที่ไร้เดียงสา และในหลายกรณีก่อให้เกิดปัญหา
- วัฒนธรรมของ Go มักเป็นแนว "ระวังเอาเอง" มากกว่าจะพยายามแก้ปัญหา
-
"Rust สมบูรณ์แบบ และพวกคุณทุกคนโง่กันหมด"
- Rust สามารถนำมาใช้แบบค่อยเป็นค่อยไปได้ และทำงานร่วมกับภาษาอื่นได้ดี
- ความสำเร็จของ Rust ส่วนหนึ่งมาจากการที่มันช่วยให้เปลี่ยนผ่านไปสู่ภาษาที่ปลอดภัยกว่าได้
- Rust เองก็มีปัญหาเช่นกัน แต่ปัญหาเหล่านั้นกำลังถูกแก้ไขอย่างค่อยเป็นค่อยไป
-
ใช้ Go เป็นภาษาสำหรับต้นแบบ/การเริ่มต้น
- Go มักถูกมองว่าเป็นภาษาที่เรียนรู้ง่าย แต่ในความเป็นจริงต้องอาศัยประสบการณ์มาก
- มันขาดฟีเจอร์ที่ช่วยบอกได้อย่างชัดเจนว่าโค้ดนั้นผิด
- ข้อเสียของ Go จะค่อยๆ ปรากฏเมื่อเวลาผ่านไป และมันไม่ใช่ภาษาที่ย้ายออกได้ง่าย
-
คำโกหกที่เราบอกตัวเองเกี่ยวกับเหตุผลที่ยังใช้ Golang ต่อไป
- คนอื่นใช้กัน ดังนั้นมันก็น่าจะดีสำหรับเราด้วย
- มองว่าข้อบกพร่องในการออกแบบภาษาเป็นเรื่องยอมรับได้ ไม่ว่าจะรายบุคคลหรือโดยรวม
- คิดว่าถ้าระมัดระวังพอ ก็จะเอาชนะปัญหาเหล่านี้ได้
- คิดว่าเขียนง่าย ก็แปลว่าการพัฒนาซอฟต์แวร์สำหรับใช้งานจริงย่อมง่ายด้วย
- คิดว่าภาษาง่าย ทุกอย่างก็ต้องง่ายไปหมด
- คิดว่าเดี๋ยวค่อยเขียนใหม่เมื่อไรก็ได้
2 ความคิดเห็น
ผมก็ไม่แน่ใจเหมือนกันว่าคนสมัครเล่นที่เพิ่งได้คลุกคลีกับภาษา Go แบบเข้มข้นมาเพียงช่วงเวลาสั้นแสนสั้นจะเขียนความเห็นได้ไหม... แต่ดูเหมือนว่าภาษา Go จะมีทั้งข้อดีและข้อเสียที่ชัดเจนมาก จนทั้งคนที่เลือกใช้และคนที่หลีกเลี่ยงต่างก็มีเหตุผลที่ชัดเจนของตัวเอง สำหรับผมคงไม่ค่อยเหมาะที่จะเอาไปเทียบกับ Rust และน่าจะเทียบกับ Kotlin(Java) มากกว่า
goroutine ของ Go นั้นยอดเยี่ยมจริง แต่ก็ไม่ใช่เวทมนตร์ โดยเฉพาะในงานแบ็กเอนด์ที่เป็นโปรเจ็กต์เล็กและใช้ MySQL แค่ตัวเดียว เรื่อง concurrency นี่จัดการยากมาก ปัญหาทรัพยากร MySQL หมดหรือการจัดการ pool ที่ใน JS/TS runtime แทบไม่ต้องกังวล กลับยากกว่าที่คิด สุดท้ายในสถานการณ์แบบนี้ DB จะกลายเป็นคอขวด ทำให้ข้อดีด้าน concurrency ของภาษา Go ลดทอนลงไปบางส่วน (async I/O หรือ event loop ของ JS/TS runtime อาจจะเหมาะกว่าด้วยซ้ำ) ลองยิงด้วยเครื่องมืออย่าง
heyแบบ-c 100ดูก็จะเข้าใจทันทีแล้วถึงจะมี GC ที่ยอดเยี่ยม ก็ไม่ได้หมายความว่าจะใช้วัตถุแบบส่งต่อแต่ pointer อย่างเดียวได้ตามใจ แล้วไม่สนใจการจัดการภายหลัง ทุกอย่างมี trade-off และสำหรับภาษา Go ถ้าเป็นวัตถุขนาดเล็กก็ควรส่งแบบคัดลอกค่าไปใช้ แล้วให้มันถูกจัดการทันทีเมื่อฟังก์ชันจบจะดีกว่า ผมอาจจะติดกรอบความคิดเก่าอยู่ก็ได้ แต่คงไม่ควรเข้าหา pointer แบบง่าย ๆ ด้วยมุมมองเรื่องประสิทธิภาพเหมือนในภาษา C/C++
การที่เวลารีเทิร์นจากฟังก์ชันต้องรีเทิร์น
errorแทบทุกครั้ง และต้องตรวจด้วยif err != nil {}ทุกครั้งนั้นน่ารำคาญมาก แต่สิ่งนี้ก็เป็นข้อดี เพราะมีต้นทุนต่ำกว่าtry catchและคีย์เวิร์ดdeferที่ทำหน้าที่คล้ายfinally {}ก็ยอดเยี่ยมมากเช่นกัน เพราะไม่ต้องกังวลว่าจะปล่อยทรัพยากรเมื่อไร นอกจากนี้การที่สามารถประกอบแบ็กเอนด์เซิร์ฟเวอร์ที่ดีได้ทันทีด้วย standard library เพียงอย่างเดียวก็ดีมากเช่นกัน (1.23 ขึ้นไป) และที่ดีที่สุดคือถ้าบิลด์ให้ตรงกับ target OS ก็ไม่จำเป็นต้องมี runtime อื่นหรือการติดตั้งล่วงหน้าเพิ่มเติมผมยังใช้ภาษา Go มาไม่นาน แต่เหมือนจะเขียนความเห็นส่วนตัวเสียยาวเกินไปแล้ว ขอยุติแค่นี้ครับ 555 ผมชอบทั้งภาษา Go และภาษาอื่น ๆ เหมือนกัน!
ความคิดเห็นบน Hacker News
มีการชี้ข้อด้อยของภาษา Go ไว้มากมาย แต่การจัดการข้อผิดพลาดแบบชัดเจนไม่ใช่หนึ่งในนั้น การจัดการด้วยข้อยกเว้นเพิ่มชั้นแบบ "เวทมนตร์" ที่ทำให้พลาดได้ง่ายเกินไป สำหรับโปรเจกต์ส่วนตัวชอบ Rust มากกว่า แต่ในโปรเจกต์ขนาดใหญ่ที่มีนักพัฒนาหลายระดับเข้าร่วม ปรัชญาของ Go เป็นแนวทางจัดการข้อผิดพลาดที่สมเหตุสมผลที่สุดในโลกยุคปัจจุบัน
Rust กับ Go แตกต่างกันมาก และจุดกึ่งกลางที่ผู้คนต้องการนั้นยังไม่มีอยู่ในตอนนี้
ชอบภาษาที่เรียบง่าย เทคโนโลยีมี trade-off เสมอ ดังนั้นการวิจารณ์อย่างสมดุลจึงสำคัญ
สงสัยว่าทำไมการวิจารณ์ภาษาถึงสำคัญนัก การวิจารณ์เหล่านั้นก็ไม่ได้เขียนในเชิงสร้างสรรค์
ทุกครั้งที่อ่านคำวิจารณ์ Go ก็ยังคงจะใช้ Go ต่อไป
ทุกครั้งที่ใช้ภาษาอื่น ก็อยากกลับมาใช้ Go
กำลังมองหา Python ที่ดีกว่าเดิม Go ดูเป็นตัวเลือกที่ชัดเจน แต่ไม่ชอบไวยากรณ์ของมัน
ไม่เข้าใจว่าทำไม Go กับ Rust ถึงถูกนำมาเปรียบเทียบบ่อยนัก การเอาไปเทียบกับ Java น่าจะเหมาะสมกว่า