Go คือภาษาที่ดีที่สุดสำหรับ AI เอเจนต์

• ความเรียบง่ายของภาษา Go และคุณสมบัติการคอมไพล์ ช่วยเพิ่มความเสถียรของโค้ดที่ AI เอเจนต์สร้างขึ้น และเพิ่มประสิทธิภาพในการรัน
• ด้วย static typing และความเร็วในการคอมไพล์ที่สูง เอเจนต์จึงตรวจสอบข้อผิดพลาดของโค้ดได้รวดเร็วและทำงานแบบวนซ้ำได้อย่างมีประสิทธิภาพ
• เครื่องมือที่เป็นมาตรฐานในระดับภาษา (gofmt, การทดสอบ, การบิลด์) ช่วยให้เอเจนต์สร้างโค้ดได้อย่างสม่ำเสมอ
• รองรับการบิลด์ cross-platform binary มาเป็นค่าเริ่มต้น ทำให้แบ็กกราวด์เอเจนต์สามารถตรวจสอบและรันโค้ดเดียวกันแบบกระจายบน OS ที่หลากหลายได้
• ด้วยคุณสมบัติเหล่านี้ Go จึงถูกมองว่าเป็น ภาษาที่สร้างสมดุลระหว่างประสิทธิภาพการทำงาน ความเรียบง่าย และสมรรถนะ และกำลังกลายเป็นตัวเลือกเด่นสำหรับการพัฒนาแบบอาศัย AI เอเจนต์

---

ข้อดีของการที่ Go เป็นภาษาคอมไพล์

• เอเจนต์สร้างโค้ดจำนวนมาก และโค้ดเหล่านั้นส่วนใหญ่มีลักษณะเพียงแค่ "ดูเหมือนใช้ได้" ดังนั้นโจทย์สำคัญคือการตรวจสอบว่าใช้งานได้จริงหรือไม่
• หากใช้ภาษาคอมไพล์ ระบบ strong typing และ static typing จะช่วยตัดบั๊กบางประเภท เช่น การใช้ type หรือ argument ผิด ออกไปได้ตั้งแต่ขั้นคอมไพล์
• หากคอมไพล์ผ่าน ก็จะได้หลักประกันว่าอย่างน้อยเป็น โค้ดที่ถูกต้องตามไวยากรณ์ ภายใต้มาตรฐานของภาษา
• เมื่อเทียบกับ Rust เหตุผลที่ Go เหมาะกับเอเจนต์มากกว่า:
  • ไวยากรณ์และแนวคิดของ Go เรียบง่ายกว่า Rust
  • ระบบ type ของ Go ซับซ้อนน้อยกว่า Rust ทำให้โค้ดที่สร้างออกมา ใกล้เคียงกับรูปแบบการเขียนที่เป็นสำนวนปฏิบัติทั่วไปมากกว่า และมนุษย์เข้าใจได้ง่ายกว่า
  • Go คอมไพล์ได้เร็วกว่า Rust จึงช่วยย่นวงจร feedback ของเอเจนต์
  • Go มีอยู่ในข้อมูลฝึกมากกว่า Rust ทำให้โมเดลสร้างโค้ด Go ได้ดีกว่า

ความเรียบง่ายของ Go

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

ความเป็นมาตรฐานของ Go

• Go เป็นภาษาที่มีความเห็นชัดเจน (opinionated) พร้อม แนวทางและเครื่องมือที่ชัดเจน โดยมีวิธีมาตรฐานสำหรับการรันทดสอบ การจัดรูปแบบโค้ด และการบิลด์ไบนารี
• แม้รูปแบบการจัดการ error จะเป็นเรื่องที่คนชอบไม่เหมือนกัน แต่ก็ให้ แพตเทิร์นที่เป็นที่ยอมรับร่วมกันหนึ่งแบบ ซึ่งช่วยผลักดันให้เกิดการเขียนโค้ดเชิงสำนวนที่หลายคนและหลายเอเจนต์ทำงานร่วมกันได้ง่าย
• เมื่อเทียบกับ JavaScript: แต่ละโปรเจ็กต์ JS ใช้เครื่องมือต่างกัน และมีความเห็นกระจัดกระจายเกี่ยวกับการจัดรูปแบบโค้ด การแจกจ่ายแพ็กเกจ และวิธี import ไลบรารี ทำให้ไม่มีประสิทธิภาพสำหรับเอเจนต์
• ด้วยความเป็นมาตรฐานของ Go โมเดลจึงสร้าง โค้ด Go เชิงสำนวนได้อย่างสม่ำเสมอ จากข้อมูลฝึก
  • ถ้าขอให้เอเจนต์จัดรูปแบบโค้ด JS มักจะพยายามติดตั้งและตั้งค่าเครื่องมือใหม่ แต่ใน Go แค่รัน gofmt ก็จบ
  • การเขียน unit test หรือการบิลด์ไบนารีก็เป็นมาตรฐานในลักษณะเดียวกัน

การบิลด์ไบนารีข้ามแพลตฟอร์ม

• ใน Go การรองรับ cross-platform เป็นความสามารถระดับ first-class citizen ซึ่งมีประโยชน์มากโดยเฉพาะกับซอฟต์แวร์อย่างเครื่องมือ CLI ที่ไม่สามารถควบคุมสภาพแวดล้อมการรันได้
• สามารถรัน unit test และ integration test ด้วยคำสั่งเดียวกันในหลายสภาพแวดล้อม เพื่อตรวจสอบว่าฟังก์ชันเดิมยังไม่พัง
• จุดเด่นนี้ยิ่งชัดเจนเมื่อใช้ แบ็กกราวด์เอเจนต์:
  • แนวโน้มกำลังไปสู่การแยกออกจากการควบคุมสภาพแวดล้อม build/run โดยตรงมากขึ้น เช่น สั่งงาน Cursor ผ่านข้อความ Slack หรือส่งต่อ local session ไปยังระยะไกล
  • โค้ด Go สามารถสร้างไบนารีแบบเดียวกันได้บน Linux, Windows และ macOS และกระบวนการทำงานทั้งหมดก็ เป็นมาตรฐานเดียวกัน ข้ามสภาพแวดล้อม จึงไม่ต้องกังวลว่าผู้ให้บริการ sandbox จะรองรับ dependency สำหรับการพัฒนาหรือไม่

คุณภาพของโค้ด Go ที่เอเจนต์สร้าง

• ณ ต้นปี 2026 อัตราที่เอเจนต์สามารถ สร้างโค้ด Go ที่ใช้ได้จริงตั้งแต่ครั้งแรกอยู่ที่ราว 95% (เป็นตัวเลขจากประสบการณ์ส่วนตัว ไม่ใช่ข้อมูลทางการ)
• เมื่อใช้เอเจนต์กับ Go ให้ความรู้สึกว่ามีอุปสรรคน้อยกว่า Python
• โมเดลเรียนรู้ไลบรารี แพตเทิร์น และแนวปฏิบัติที่ดีของ Go ได้มากพอ จนถ้ากำหนดทิศทางให้แล้ว การลงมือทำฟีเจอร์แทบจะเป็นเรื่องง่ายมาก
• ปริมาณข้อมูลฝึกของ Go โดยรวมอาจน้อยกว่า Python แต่ Python มี 20 วิธีที่แตกต่างกัน สำหรับงานเดียวกัน ดังนั้นถ้ามองในระดับไลบรารีเฉพาะ ผลลัพธ์คือ Go มีความหนาแน่นของข้อมูลฝึกสูงกว่า
• เมื่อประสิทธิภาพของโมเดลดีขึ้นและข้อมูลฝึกเพิ่มขึ้น ข้อได้เปรียบนี้ก็อาจหายไปตามเวลา

เหตุผลที่โปรเจ็กต์ Bruin เลือก Go

• Bruin เป็น เครื่องมือ ETL แบบโอเพนซอร์ส และเป็นเครื่องมือ CLI ที่เขียนด้วย Go เป็นหลัก
• แม้ Python จะเป็นกระแสหลักใน ecosystem ด้านข้อมูล แต่ข้อจำกัดสำคัญที่ทำให้เลือก Go คือ:
  • ในฐานะเครื่องมือ orchestration ข้อมูล การจัดการ concurrency เป็นหัวใจสำคัญ
  • ต้องโต้ตอบกับระบบหลากหลายประเภท เช่น language runtime หรือ API ภายนอกของแพลตฟอร์มข้อมูล จึงต้องมี ecosystem ที่เพียงพอ
  • ในฐานะเครื่องมือ CLI จำเป็นต้องมี สมรรถนะที่เพียงพอ เพื่อใช้เป็นส่วนขยาย VS Code หรือแบ็กเอนด์ของ local UI
  • ต้องการ การจัดการ error ที่คาดเดาได้ เพื่อผสานรวมกับระบบหลากหลายแบบ
  • เนื่องจากทำงานบนเครื่องของผู้ใช้ จึงต้องรองรับ OS และสถาปัตยกรรมที่หลากหลายได้ง่าย
• ในเชิงอัตวิสัย ยังต้องเป็นภาษาที่ผู้ร่วมพัฒนาหลัก ทำงานได้อย่างสนุก เพราะสำหรับทีมเล็ก ความสนุกและพลังงานคือทรัพยากรที่หายากที่สุด
• แม้จะมีข้อเสียเรื่องขาดไลบรารีข้อมูลบางอย่างเมื่อเทียบกับ Python แต่ก็ตัดสินใจจากสัญชาตญาณว่า ข้อดีด้าน ความเร็วและประสบการณ์นักพัฒนา (DX) ของ Go จะสร้างคุณค่าระยะยาวได้มากกว่า

บทสรุป: Go ในยุคของเอเจนต์

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

[mammal]

อย่างแรกเลยคือมันคอมไพล์เร็ว เลยชอบครับ

[tsboard]

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

[GN⁺]

ความคิดเห็นใน Hacker News

• ผมทำงานคอนซัลต์มานานกว่า 9 เดือน และยิ่งมั่นใจว่า Go เหมาะมากกับการสร้างโค้ดด้วย LLM
  Go มีระบบบิลด์ที่สม่ำเสมอ, formatter, static typing และ concurrency แบบ CSP โดยไม่มีส่วนอันตรายแบบ C++
  ตลอดกว่า 10 ปี แทบไม่มีเวอร์ชันที่ทำลายความเข้ากันได้ และการเปลี่ยนแปลงของเฟรมเวิร์กก็มีน้อยมาก
  เวลาที่ผมแนะนำทีมต่าง ๆ ที่ Sancho Studio ให้นำ agentic coding workflow มาใช้ Go ให้ผลลัพธ์ที่เสถียรมากใน Claude และ Codex
  ตรงกันข้าม Python หรือ TypeScript มีความหลากหลายทั้งเรื่องเฟรมเวิร์กและแนวทางด้าน type มากเกินไป ทำให้ LLM สร้างผลลัพธ์ที่สม่ำเสมอได้ยาก
  จริง ๆ แล้วเหตุผลที่ผมเคยไม่ชอบ Go — ข้อจำกัดด้าน abstraction — กลับกลายเป็นข้อดีสำหรับ LLM
  go fix ตัวใหม่ใน Go 1.26 รองรับการรีแฟกเตอร์อัตโนมัติในระดับ AST ทำให้คงโค้ดเบสให้ทันสมัยได้
  ก่อนหน้านี้ผมเคยสร้าง PKI ด้วย Go ในโปรเจกต์ Zoom E2E Whitepaper และตอนนี้ LLM มาช่วยจัดการ boilerplate ที่ซ้ำ ๆ ได้ ทำให้ความเรียบง่ายของ Go ฉายแสงจริง ๆ

  • ผมคิดว่าเหตุผลส่วนใหญ่พวกนี้ใช้กับ Java ได้เหมือนกัน
    Java มีข้อมูลสำหรับการเรียนรู้มากกว่าและมี type system ที่แข็งแรงกว่า จึงได้เปรียบในการตรวจสอบผลลัพธ์จาก LLM ด้วย
  • เห็นด้วยอย่างยิ่ง ผมใช้ C++ มานานกว่า 20 ปี แต่คิดว่า Golang คือภาษาที่ดีที่สุดสำหรับเวิร์กโฟลว์ส่วนใหญ่ที่ไม่ใช่งานควบคุมแบบเรียลไทม์หรือระบบฝังตัว
  • ผมเห็นด้วยมากกับประโยคที่ว่า “ข้อจำกัดด้าน abstraction ของ Go กลับเป็นข้อดีสำหรับ LLM”
    ผมชอบสภาพแวดล้อมระดับล่าง และชอบ abstraction stack ที่ตื้นกับโครงสร้างที่คาดเดาได้ของ Go
    สุดท้ายแล้ว ความเรียบง่ายและความสม่ำเสมอ เข้ากันได้ดีกับทั้ง LLM และนักพัฒนาอย่างผม
  • เมื่อดูคุณภาพโค้ดของ LLM ช่วงหลัง ๆ ตัวแปรที่สำคัญกว่าภาษาคือ ความซับซ้อนของการนิยามปัญหา
    ภาษาที่มีมาตรฐานชัดเจนอย่าง Go ทำให้เข้าใจผลลัพธ์ได้ง่าย แต่ Ruby หรือ C++ ก็ทำได้ดีพอสมควรเหมือนกัน
    ส่วน Lisp หรือ Bash มีอิสระมากเกินไป ทำให้ผลลัพธ์ไม่นิ่ง
  • คุณอาจมีอคติเข้าข้าง Go ก็ได้ แต่ผมมีประสบการณ์กับ TypeScript มากกว่าเลยมองต่างออกไป
    การจับ Python กับ TypeScript ไว้ในกลุ่มเดียวกันนั้นไม่แม่นนัก
    Python ทำให้ LLM สับสนเพราะมีความไม่ต่อเนื่องระหว่างเวอร์ชันและนำระบบ type มาใช้ช้า แต่ TypeScript มีความสม่ำเสมอกว่ามาก
    ถ้ามีโอกาส ผมอยากลองทำ ศึกเขียนโค้ดสด Go vs TypeScript ดู

• สำหรับการพัฒนาเอเจนต์ ผมคิดว่าควรย้ายการตรวจสอบให้มากที่สุดไปไว้ที่ คอมไพล์ไทม์
  Go ก็โอเค แต่ type system ของมันยังไม่แข็งแรงเท่าภาษาอื่นบางตัว
  Rust มีประโยชน์มากตรงที่ถ้าผ่าน compiler error ไปได้แล้ว แทบจะไม่มี runtime error
  Haskell น่าจะดีกว่าอีกด้วยซ้ำ

  • เหตุผลหนึ่งที่ Rust ดีคือ โค้ดทดสอบอยู่ในไฟล์เดียวกัน
    เวลาเอเจนต์แก้ซอร์สก็จะอัปเดตเทสต์ไปพร้อมกัน
    ในภาษาอื่นมักลืมเทสต์ได้ง่าย
  • Haskell ก็ยอดเยี่ยม แต่ LLM มักมีแนวโน้มจะซ้อน abstraction มากเกินไป
    ผมกำลังสร้าง ภาษาเล่น ๆ ที่อิง dependent types บน Haskell และด้วยไวยากรณ์ที่เรียบง่ายทำให้ LLM จัดการได้ง่าย
    ภายในมันทำงานคล้าย Rust แบบ safe/unsafe
  • ขอเชียร์ Rust อีกเสียง ผมคิดว่ากลยุทธ์แบบ ยอมแบกรับความซับซ้อนตั้งแต่ต้นเพื่อลดต้นทุนตอนปฏิบัติการ นั้นถูกต้อง
    ยังไงเราไม่ได้เป็นคนเขียนเองทั้งหมด ความไม่สะดวกเล็กน้อยเลยรับได้
  • ผมก็ชอบใช้ Rust เหมือนกัน เพราะมัน ทำงานร่วมกับภาษาอื่นได้ดีมาก
    จะใช้คู่กับ TypeScript เพื่อทำ SPA, ใช้ Tauri ทำแอปหลายแพลตฟอร์ม หรือพ่วง Python sidecar ก็ได้
    ตอนนี้กำลังลองทำเกมด้วย Bevy และชอบโครงสร้าง ECS ของมันมาก
    ผมสามารถรวมข้อดีของหลายภาษาเข้าด้วยกันพร้อมหลีกเลี่ยงข้อเสียได้
  • สงสัยว่ามีใครเคยลองภาษา ระดับสูง อย่าง Haskell หรือ Prolog กับ LLM ในปี 2025 บ้างไหม

• หลายวันก่อนผมลองสั่ง Gemini, Claude Code และ Codex ว่า “ลองออกแบบภาษาที่พวกคุณอยากใช้เองสิ”
  ผลที่ได้คือ ภาษาสไตล์ Forth ที่มี type system แข็งแรง, contracts, การทดสอบแบบ native, fuzz testing และตัวแก้ constraint ที่ใช้ Z3
  ผมเขียน interpreter ด้วย Elixir และเปิดซอร์สไว้เป็น โปรเจกต์ Cairn
  ภาษานี้สร้างขึ้นด้วยประมาณ 150 commits และทำงานได้โดยไม่มี runtime error
  การทดลองนี้แสดงให้เห็นถึง ความสำคัญของการวิเคราะห์ตอนคอมไพล์และเครื่องมือทดสอบ

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

• ผมยังคิดว่า OCaml คือทางเลือกที่ดีที่สุดอยู่ดี
  มันมีข้อดีมากมาย เช่น type system ที่ทรงพลัง (รวม GADT), เน้น pure function, บิลด์เร็ว และรองรับ target อย่าง WASM/JS
  โค้ดถูกประมวลผลตามลำดับภายในไฟล์ จึงต้องจัดการ dependency แบบวนลูป อย่างชัดเจน ซึ่งช่วยเพิ่มความเสถียร
  ที่สำคัญคือมันเป็นภาษาที่มนุษย์เองก็เขียนอย่างมีความสุข

  • ช่วงนี้เรื่อง multicore และ asynchronous processing เป็นอย่างไรบ้าง
    เมื่อก่อน F# นำหน้าอยู่ในด้านนั้น
  • คอมไพเลอร์ของ OCaml มี ความสามารถในการตรวจจับบั๊ก ที่ยอดเยี่ยม
    ถึงเอเจนต์จะเผลอใส่บั๊กเข้ามา ส่วนใหญ่ก็มักจะจับได้
  • ผมแนะนำ OCaml มากกว่า Go เพราะมี type system ที่แสดงความหมายได้ดีกว่า ทำให้สร้าง abstraction ที่ Go ทำไม่ได้
  • ถ้าเป็นแบบนั้น ใช้ F# ไปเลยจะไม่ดีกว่าหรือ

• ถ้าเลือกจาก PHP, Go, JavaScript และ Python งั้น Go ก็ดีกว่า แต่ก็ยังเป็นเหตุผลที่อ่อนเกินไปจะบอกว่าเป็น “ภาษาที่ดีที่สุด”

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

• ลองดูประเด็นที่คุยกันก่อนหน้านี้ใน "Why Elixir is the best language for AI" ได้
  ความสามารถด้าน runtime introspection ของ BEAM เป็นจุดที่น่าสนใจในบริบทของเอเจนต์

  • ในทำนองเดียวกันก็มีบทความ "Why Clojure is the best language for AI"
    บทความนี้วิจารณ์ Go ค่อนข้างชัด
  • และเพื่ออ้างอิงเพิ่มเติม งานวิจัย "AutoCodeBench" ระบุว่าในด้านการสร้างโค้ดด้วย LLM นั้น Go ตามหลังภาษาอื่น ๆ

• Go มีเครื่องมือ govulncheck สำหรับวิเคราะห์ช่องโหว่แบบสถิตทั้งในโค้ดและไบนารี
  มันฝังรวมอยู่ใน ecosystem ของ Go อย่างลึกซึ้งเหมือนในบทช่วยสอนทางการ และมีระดับการบูรณาการที่สูงกว่าภาษาอื่น

  • ผมยังไม่ค่อยเข้าใจว่ามันต่างจาก cargo-audit ของ Rust อย่างไร
    ก็ยังสงสัยว่า govulncheck วิเคราะห์ช่องโหว่ในโค้ดจริง ๆ ได้ไหม
  • govulncheck ไม่ได้หาช่องโหว่ในตัวโค้ดเอง แต่ใช้วิเคราะห์ว่า มีการใช้งานไลบรารีที่มีช่องโหว่อยู่หรือไม่
    จุดเด่นคือมันตามเส้นทางการเรียกใช้ได้ แต่ก็ยังไม่ใช่เครื่องมือ static analysis แท้ ๆ แบบ Coverity
    สำหรับ Go ผมมองว่าชุดเครื่องมือชุมชนอย่าง golangci-lint จะใกล้เคียงกว่า
  • ถึงอย่างนั้น ระดับการบูรณาการและการใช้งานที่สะดวก ของ govulncheck ก็ยังเหนือกว่าภาษาอื่น และช่วยมากกับการดูแลโปรเจกต์ขนาดใหญ่

• ผมเคยลองเขียนโปรเจกต์เดิมใหม่ด้วยหลายภาษา และพบว่า Python เข้ากับ Claude มากที่สุด
  โค้ดมีขนาดเล็กและเข้าใจง่าย ทำให้งานเดินเร็วขึ้นมาก
  ผมลอง Go, Kotlin และ JavaScript ด้วย แต่สุดท้ายก็มาจบที่ Python

  • อยากรู้ว่าในโค้ด Python นั้นมันจัดการ exception handling หรือคำสั่ง pass ได้ดีแค่ไหน

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

  • โค้ดที่สร้างด้วย Haskell น่าจะสั้นกว่า Go และ อ่านง่ายกว่า
    สคริปต์ Python ก็อ่านง่ายในลักษณะคล้ายกัน

• ในฐานะคนที่ทำงานกับ AI coding agent ทุกวัน ผมคิดว่า “ภาษาที่ดีที่สุด” ขึ้นอยู่กับ เป้าหมายของเอเจนต์
  ความเรียบง่ายและความคาดเดาได้ของ Go เหมาะกับงานทั่วไป แต่ TypeScript โดดเด่นมากเมื่อเชื่อมกับสภาพแวดล้อมเว็บ
  Python ก็ยังไร้คู่แข่งในสาย data/ML
  ประเด็นสำคัญไม่ใช่เลือกภาษาที่ LLM ถนัดที่สุด แต่คือการเลือก ภาษาให้เหมาะกับโดเมนของเอเจนต์