3 คะแนน โดย GN⁺ 2024-11-27 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้เขียนเป็นตุ่นปากเป็ด

    • การปัดคำวิจารณ์ทิ้งด้วยการมองว่าผู้เขียนไร้ความสามารถเป็นวิธีที่ขี้เกียจ
    • นักพัฒนาระดับจูเนียร์สามารถมองปัญหาจากมุมใหม่ได้ และนี่คือเหตุผลสำคัญอย่างหนึ่งของการจ้างงาน
    • ผู้เขียนไม่ใช่นักพัฒนาจูเนียร์ และมีความเข้าใจด้านการออกแบบภาษาจากประสบการณ์ที่หลากหลาย
  • แม่สูบบุหรี่ ดังนั้นมันก็น่าจะไม่เป็นไร

    • การทำตามเทคโนโลยีที่บริษัทอื่นใช้แบบไม่ลืมหูลืมตาเป็นเรื่องไม่มีประสิทธิภาพ
    • บล็อกเทคโนโลยีมีเป้าหมายเพื่อทำให้ภาพลักษณ์ของบริษัทดูดีขึ้น
    • บล็อกของ 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 ความคิดเห็น

 
tsboard 2024-11-28

ผมก็ไม่แน่ใจเหมือนกันว่าคนสมัครเล่นที่เพิ่งได้คลุกคลีกับภาษา 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 และภาษาอื่น ๆ เหมือนกัน!

 
GN⁺ 2024-11-27
ความคิดเห็นบน Hacker News
  • มีการชี้ข้อด้อยของภาษา Go ไว้มากมาย แต่การจัดการข้อผิดพลาดแบบชัดเจนไม่ใช่หนึ่งในนั้น การจัดการด้วยข้อยกเว้นเพิ่มชั้นแบบ "เวทมนตร์" ที่ทำให้พลาดได้ง่ายเกินไป สำหรับโปรเจกต์ส่วนตัวชอบ Rust มากกว่า แต่ในโปรเจกต์ขนาดใหญ่ที่มีนักพัฒนาหลายระดับเข้าร่วม ปรัชญาของ Go เป็นแนวทางจัดการข้อผิดพลาดที่สมเหตุสมผลที่สุดในโลกยุคปัจจุบัน

    • Go ถูกนำไปใช้มากกว่าภาษา "ใหม่" อื่น ๆ เพราะความเรียบง่ายของมัน แม้จะไม่ใช่ภาษาที่ดีที่สุด แต่ด้วยแนวคิดที่ฝังมาในภาษาหลายอย่าง จึงมักเป็นตัวเลือกที่ดีที่สุดสำหรับภาษาวัตถุประสงค์ทั่วไป
  • Rust กับ Go แตกต่างกันมาก และจุดกึ่งกลางที่ผู้คนต้องการนั้นยังไม่มีอยู่ในตอนนี้

    • มีความต้องการภาษาที่ค่อนข้างเรียบง่าย แต่มี type system คล้ายกับของ Rust
    • Gleam กับ Kotlin คล้ายอยู่บ้างแต่ก็ไม่ใช่เสียทีเดียว Rust ซับซ้อนเกินไปจนยากสำหรับคนที่ไม่ได้เรียนสายนี้หรือไม่ใช่มืออาชีพ
    • ไม่มีภาษาที่สมบูรณ์แบบ แต่ Go กับ Rust ต่างก็นำสิ่งน่าทึ่งมาให้ หวังว่าจะมีภาษาโปรแกรมที่เรียบง่าย ใช้งานแพร่หลาย และได้รับแรงบันดาลใจจากทั้งสองภาษา
  • ชอบภาษาที่เรียบง่าย เทคโนโลยีมี trade-off เสมอ ดังนั้นการวิจารณ์อย่างสมดุลจึงสำคัญ

    • ได้แชร์ลิงก์บล็อกเกี่ยวกับเหตุผลที่เลือก Go
  • สงสัยว่าทำไมการวิจารณ์ภาษาถึงสำคัญนัก การวิจารณ์เหล่านั้นก็ไม่ได้เขียนในเชิงสร้างสรรค์

    • ทุกภาษาถูกวิจารณ์ได้ Go ก็ยังทำงานได้ยอดเยี่ยมในโปรเจกต์ แม้จะต่างจากภาษาที่ "ซับซ้อนกว่า"
    • ให้ฟีดแบ็กกับทีม Go และเฝ้าดูการพัฒนาที่ค่อยเป็นค่อยไปของภาษา พร้อมทั้งให้บริการกับชุมชนต่อไป
  • ทุกครั้งที่อ่านคำวิจารณ์ Go ก็ยังคงจะใช้ Go ต่อไป

    • ในทางทฤษฎีมันมีปัญหาหลายอย่าง แต่ในทางปฏิบัติก็ยังเป็นภาษาโปรแกรมที่ดี
    • ชอบการจัดการข้อผิดพลาดแบบชัดเจน และก็ไม่ได้ใส่ใจกับข้อด้อยของภาษาอื่นมากนัก
    • คนที่ไวต่อข้อเสียของ Go ก็คงจะบ่นต่อไป เลือกภาษาที่เหมาะกับตัวเองก็พอ
  • ทุกครั้งที่ใช้ภาษาอื่น ก็อยากกลับมาใช้ Go

    • Go แค่ติดตั้ง ดาวน์โหลดโค้ด แล้วก็เขียนได้เลย ไม่ต้องกังวลเรื่องเวอร์ชัน รันไทม์ การตั้งค่า build tool หรือ package manager
    • Rust ก็อาจให้ประสบการณ์คล้ายกันได้ เวลาใช้ Python, Typescript, Java กลับรู้สึกกลัวการเขียนโปรแกรมเพราะปัญหาที่เกี่ยวกับการตั้งค่า
  • กำลังมองหา Python ที่ดีกว่าเดิม Go ดูเป็นตัวเลือกที่ชัดเจน แต่ไม่ชอบไวยากรณ์ของมัน

    • Rust ใช้อักขระพิเศษเยอะเกินไป ส่วน Lisp ก็ไม่ชอบเพราะวงเล็บกับสัญกรณ์โปแลนด์แบบกลับหลัง
    • คอมไพล์โค้ด Python ด้วย Nuitka เพื่อแจกจ่ายเป็นไบนารี และสนใจ AOT compilation ของ C#
    • ชอบ Nim กับ Crystal แต่ชุมชนที่เล็กเป็นอุปสรรค แม้ชุมชนจะเล็ก Nim ก็ยังเป็นภาษาที่ยอดเยี่ยม
  • ไม่เข้าใจว่าทำไม Go กับ Rust ถึงถูกนำมาเปรียบเทียบบ่อยนัก การเอาไปเทียบกับ Java น่าจะเหมาะสมกว่า