23 poin oleh GN⁺ 2026-03-04 | 3 komentar | Bagikan ke WhatsApp
  • Kesederhanaan bahasa Go dan sifat terkompilasinya meningkatkan stabilitas kode yang dihasilkan agen AI serta efisiensi eksekusinya
  • Berkat pengetikan statis dan kecepatan kompilasi yang tinggi, agen dapat memverifikasi kesalahan kode dengan cepat dan menjalankan iterasi secara efisien
  • Alat yang terstandarisasi di tingkat bahasa (gofmt, testing, build) mendorong agen menghasilkan kode yang konsisten
  • Build biner lintas platform didukung secara bawaan, sehingga agen latar belakang dapat memverifikasi dan menjalankan kode yang sama secara terdistribusi di berbagai OS
  • Berkat karakteristik ini, Go dinilai sebagai bahasa yang menyeimbangkan produktivitas, kesederhanaan, dan performa, serta muncul sebagai pilihan kuat untuk pengembangan berbasis agen AI

Keunggulan Go sebagai bahasa terkompilasi

  • Agen menghasilkan kode dalam jumlah besar, dan sebagian besar kode ini hanya berada pada tingkat "terlihat masuk akal", sehingga tantangan utamanya adalah memverifikasi apakah kode benar-benar berjalan
  • Dengan menggunakan bahasa terkompilasi, sistem strong typing dan static typing dapat menyingkirkan kategori bug tertentu seperti tipe atau argumen yang salah pada saat kompilasi
  • Jika kompilasi berhasil, ada jaminan bahwa kode tersebut benar secara sintaksis dalam cakupan standar bahasa
  • Dibandingkan dengan Rust, alasan Go lebih cocok untuk agen:
    • Sintaks dan konsep Go lebih sederhana daripada Rust
    • Sistem tipe Go tidak serumit Rust, sehingga kode yang dihasilkan lebih dekat ke gaya penulisan idiomatis dan lebih mudah dipahami manusia
    • Kecepatan kompilasi Go lebih tinggi daripada Rust, sehingga loop umpan balik agen menjadi lebih singkat
    • Lebih banyak kode Go terdapat dalam data pelatihan dibanding Rust, sehingga model menghasilkan kode Go yang lebih baik

Kesederhanaan Go

  • Jika terbiasa dengan bahasa pemrograman apa pun, Anda dapat membaca kode Go dan segera memahami perilakunya karena bahasanya sendiri sederhana
  • Meski agen menghasilkan banyak kode Go, pengembang tidak akan terlalu kesulitan mengikuti kodenya
  • Ketika agen sesekali membuat keputusan desain yang aneh lalu terus melaju ke arah itu, kesederhanaan bahasa memudahkan kita memahami ke mana agen sedang menuju
  • Dalam 12 bulan ke depan, kemungkinan kebutuhan membaca kode secara langsung akan berkurang sehingga pentingnya keterbacaan dan kesederhanaan bisa menurun, tetapi opsi untuk tetap bisa memeriksa kode secara langsung tetap bernilai

Cara Go yang terstandarisasi

  • Go adalah bahasa yang opinionated dengan panduan dan alat yang jelas, sehingga ada cara standar untuk menjalankan tes, memformat kode, dan membangun biner
  • Cara penanganan error juga memicu pro dan kontra, tetapi tetap menyediakan satu pola yang mapan yang mendorong penulisan kode idiomatis dan memudahkan banyak orang maupun agen bekerja bersama
  • Dibandingkan dengan JavaScript: tiap proyek JS memakai alat berbeda, dan pendapat soal formatting kode, distribusi paket, serta cara impor library terpecah-pecah, sehingga tidak efisien untuk agen
  • Berkat standardisasi Go, model dapat secara konsisten menghasilkan kode Go idiomatis berdasarkan data pelatihan
    • Jika agen diminta memformat kode JS, ia cenderung mencoba memasang dan mengonfigurasi alat baru, sedangkan di Go cukup menjalankan gofmt
    • Penulisan unit test maupun build biner juga terstandarisasi dengan cara yang sama

Build biner lintas platform

  • Di Go, dukungan lintas platform adalah first-class citizen, dan sangat menguntungkan terutama untuk software seperti alat CLI yang lingkungan eksekusinya tidak bisa dikendalikan sepenuhnya
  • Unit test dan integration test dapat dijalankan dengan perintah yang sama di berbagai lingkungan untuk memverifikasi apakah fungsi yang sudah ada tidak rusak
  • Keunggulan ini makin besar saat memanfaatkan agen latar belakang:
    • Ada tren makin terpisah dari kontrol langsung atas lingkungan build dan eksekusi kode, seperti memicu Cursor lewat pesan Slack atau memindahkan sesi lokal ke remote
    • Kode Go menghasilkan biner yang sama di Linux, Windows, dan macOS, dan seluruh proses kerja terstandarisasi lintas lingkungan, sehingga tidak perlu khawatir apakah penyedia sandbox mendukung dependensi pengembangan tertentu

Kualitas hasil generasi kode Go oleh agen

  • Pada awal 2026, tingkat agen yang menghasilkan kode Go valid dalam sekali jalan sekitar 95% (berdasarkan pengalaman pribadi, bukan data resmi)
  • Secara subjektif, penggunaan agen di Go terasa lebih mudah dibanding Python
  • Model telah cukup mempelajari library, pola, dan best practice Go, sehingga jika arahnya sudah ditentukan, implementasi fitur terasa hampir tanpa hambatan
  • Total data pelatihan Go mungkin lebih sedikit daripada Python, tetapi di Python ada 20 cara berbeda untuk melakukan tugas yang sama, sehingga jika dilihat per library tertentu, kepadatan data pelatihan Go justru terasa lebih tinggi
  • Seiring peningkatan performa model dan meluasnya data pelatihan, keunggulan ini bisa saja hilang seiring waktu

Latar belakang pemilihan Go untuk proyek Bruin

  • Bruin adalah alat ETL open source, terutama berupa alat CLI yang ditulis dalam Go
  • Meski Python dominan dalam ekosistem data, kendala utama yang membuat Go dipilih adalah:
    • Sebagai alat orkestrasi data, penanganan konkurensi adalah hal yang krusial
    • Perlu ekosistem yang memadai karena harus berinteraksi dengan berbagai sistem seperti runtime bahasa atau API eksternal platform data
    • Sebagai alat CLI, dibutuhkan performa yang memadai agar bisa dimanfaatkan untuk ekstensi VS Code maupun backend UI lokal
    • Diperlukan penanganan error yang dapat diprediksi untuk integrasi dengan berbagai sistem
    • Karena dijalankan di mesin pengguna, diperlukan kemudahan dukungan untuk berbagai OS dan arsitektur
  • Sebagai faktor subjektif, bahasa ini juga harus menjadi bahasa yang menyenangkan untuk digunakan oleh kontributor utama, dan dalam tim kecil, kesenangan serta energi adalah sumber daya yang paling langka
  • Meski ada kekurangan berupa minimnya library data tertentu dibanding Python, diputuskan berdasarkan intuisi bahwa keunggulan Go dalam kecepatan dan developer experience (DX) akan memberi nilai lebih besar dalam jangka panjang

Kesimpulan: Go di era agen

  • Bahasa pemrograman sedang bergerak menuju era di mana manusia tidak lagi menulis kode secara langsung
  • Kini dibutuhkan sistem yang mendukung agen agar dapat menulis kode secara efektif
  • Go menyediakan lingkungan ideal bagi agen AI untuk menulis dan menjalankan kode berkat keseimbangan antara kemudahan penggunaan, performa, dan universalitas
  • Agen dapat secara otomatis menghasilkan software berperforma tinggi yang bisa dikompilasi, diuji, diformat, dan dideploy ke berbagai mesin dengan Go
  • Apakah Go akan menjadi bahasa pamungkas untuk agen, atau akan muncul bahasa yang lebih cocok, masih belum pasti, tetapi saat ini tim tersebut sudah memperoleh hasil yang memadai dalam produktivitas dan kualitas software

3 komentar

 
mammal 2026-03-05

Yang saya suka, proses build-nya cepat.

 
tsboard 2026-03-05

Bahasa Go benar-benar punya konsep yang sangat jelas, jadi tampaknya ini menjadi pilihan yang bagus bagi orang-orang yang cocok dengan konsep yang tegas itu. Saya juga sempat membangun backend dengan runtime JS lalu beralih ke Go, dan saya rasa saya bisa dengan percaya diri mengatakan bahwa dari sisi performa maupun produktivitas pengembangan, hasilnya cukup memuaskan.

 
GN⁺ 2026-03-04
Pendapat Hacker News
  • Selama lebih dari 9 bulan bekerja di konsultasi, saya terus melihat bahwa Go sangat cocok untuk pembuatan kode dengan LLM
    Go menyediakan sistem build yang konsisten, formatter, static typing, dan konkurensi berbasis CSP tanpa bagian berbahaya seperti di C++
    Selama lebih dari 10 tahun, tidak ada versi yang memutus kompatibilitas, dan perubahan framework juga hampir tidak ada
    Saat saya menyarankan tim-tim di Sancho Studio untuk mengadopsi agentic coding workflow, Go memberikan hasil yang sangat stabil di Claude maupun Codex
    Sebaliknya, Python dan TypeScript memiliki terlalu banyak variasi framework dan pendekatan typing sehingga LLM sulit menghasilkan output yang konsisten
    Alasan saya dulu tidak menyukai Go — keterbatasan abstraksinya — justru menjadi kelebihan bagi LLM
    go fix baru di Go 1.26 mendukung refaktorisasi otomatis di level AST untuk menjaga codebase tetap mutakhir
    Dulu saya membangun PKI dengan Go di proyek Zoom E2E Whitepaper, dan sekarang LLM menangani boilerplate yang repetitif sehingga kesederhanaan Go benar-benar terasa nilainya

    • Saya rasa sebagian besar alasan ini juga berlaku untuk Java
      Java punya lebih banyak data pelatihan dan sistem tipe yang lebih kuat, sehingga lebih unggul untuk memverifikasi output LLM
    • Sangat setuju. Saya sudah lebih dari 20 tahun memakai C++, tetapi saya rasa Golang adalah bahasa terbaik untuk sebagian besar workflow yang bukan kontrol real-time atau embedded
    • Saya sangat setuju dengan pernyataan “keterbatasan abstraksi Go justru menjadi kelebihan bagi LLM”
      Saya lebih suka lingkungan low-level, dan saya menyukai stack abstraksi Go yang dangkal serta strukturnya yang mudah diprediksi
      Pada akhirnya, kesederhanaan dan konsistensi sangat cocok, baik untuk LLM maupun untuk developer seperti saya
    • Melihat kualitas kode LLM belakangan ini, variabel yang lebih besar adalah kompleksitas definisi masalah, bukan bahasanya
      Bahasa yang terstandarisasi seperti Go memang membuat hasil lebih mudah dipahami, tetapi Ruby dan C++ juga cukup bagus
      Lisp dan Bash punya terlalu banyak kebebasan sehingga hasilnya naik turun
    • Mungkin kamu memang bias ke Go, tetapi saya punya lebih banyak pengalaman di TypeScript, jadi pandangan saya berbeda
      Mengelompokkan Python dan TypeScript dalam kategori yang sama itu kurang tepat
      Python membingungkan LLM karena putus versi dan adopsi typing yang lambat, sedangkan TypeScript jauh lebih konsisten
      Kalau ada kesempatan, saya ingin melihat duel coding langsung Go vs TypeScript
  • Dalam pengembangan agen, saya rasa sebaiknya sebanyak mungkin validasi dipindahkan ke compile time
    Go lumayan, tetapi sistem tipenya tidak sekuat beberapa bahasa lain
    Rust sangat berguna karena kalau sudah lolos error compiler, hampir tidak ada error runtime
    Haskell mungkin malah lebih baik

    • Salah satu alasan Rust bagus adalah karena kode test berada di file yang sama
      Saat agen memodifikasi source, test juga ikut diperbarui
      Di bahasa lain, test lebih mudah terlupakan
    • Haskell juga hebat, tetapi LLM cenderung menumpuk terlalu banyak abstraksi
      Saya sedang membuat bahasa mainan berbasis dependent type di atas Haskell, dan berkat sintaksnya yang sederhana, LLM lebih mudah menanganinya
      Secara internal, ia bekerja seperti Rust aman/tidak aman
    • Saya pilih Rust. Saya rasa strategi menanggung kompleksitas di awal dan mengurangi biaya operasional itu tepat
      Karena bukan kita yang menulisnya langsung, sedikit tidak nyaman pun tidak masalah
    • Saya juga senang memakai Rust, dan interoperabilitas antarbahasanya sangat bagus
      Bisa dikombinasikan dengan TypeScript untuk membuat SPA, atau dengan Tauri untuk aplikasi multiplatform, lalu ditambah sidecar Python
      Saya juga sedang bereksperimen membuat game dengan Bevy, dan saya suka struktur ECS-nya
      Saya bisa menggabungkan keunggulan beberapa bahasa sambil menghindari kekurangannya
    • Saya penasaran apakah ada yang sudah bereksperimen dengan bahasa tingkat tinggi seperti Haskell atau Prolog bersama LLM tahun 2025
  • Selama beberapa hari saya meminta Gemini, Claude Code, dan Codex untuk “coba desain bahasa yang kalian inginkan”
    Hasilnya adalah bahasa bergaya Forth dengan sistem tipe kuat, kontrak, test native, fuzz testing, dan pemecah kendala berbasis Z3
    Saya mengimplementasikan interpreter-nya dalam Elixir dan merilisnya sebagai proyek Cairn
    Bahasa yang dibuat dalam sekitar 150 commit itu berjalan tanpa error runtime
    Eksperimen ini menunjukkan pentingnya analisis compile time dan alat pengujian

    • Proyek yang menarik, tetapi saya rasa mengasumsikan LLM bisa merancang bahasa yang menguntungkan dirinya sendiri adalah premis yang keliru
      Informasi seperti itu tidak akan diketahuinya jika tidak ada dalam data pelatihan
    • Saya kaget karena ini hampir persis sama dengan bahasa ideal saya
      Mengembangkan tooling untuk bahasa seperti ini pasti sangat menyenangkan
    • Saya penasaran apakah kamu pernah memintanya untuk langsung mengompilasi ke bytecode BEAM
    • Mengesankan. Dari sudut pandang pemula, saya juga penasaran apakah ini lebih mudah dipelajari dibanding bahasa keluarga Forth lainnya
  • Saya masih menganggap OCaml sebagai pilihan terbaik
    Banyak kelebihannya: sistem tipe yang kuat (termasuk GADT), berfokus pada fungsi murni, build cepat, serta dukungan target WASM/JS
    Kode dievaluasi sesuai urutan di dalam file sehingga dependensi siklik harus ditangani secara eksplisit, dan itu membuatnya stabil
    Yang terpenting, bahasa ini juga menyenangkan dipakai manusia

    • Saya penasaran bagaimana kondisi multicore dan pemrosesan asinkron sekarang
      Dulu F# lebih unggul di bagian itu
    • Compiler OCaml sangat unggul dalam mendeteksi bug
      Bahkan jika agen tidak sengaja memasukkan bug, sebagian besar akan tertangkap
    • Saya merekomendasikan OCaml ketimbang Go. Berkat sistem tipe yang ekspresif, Anda bisa membuat abstraksi yang tidak mungkin dilakukan di Go
    • Kalau begitu, bukankah lebih baik pakai F# saja?
  • Di antara PHP, Go, JavaScript, dan Python, Go memang lebih baik, tetapi itu bukan alasan yang kuat untuk menyebutnya “bahasa terbaik”

    • Saya lebih suka Rust. Loop umpan balik compiler-nya sangat bagus, tetapi sintaksnya verbose
      Kesederhanaan Go dan sistem tipenya yang cukup memadai juga menarik
    • Penting juga bahwa satu-satunya bahasa terkompilasi di antara yang kamu sebut adalah Go
  • Ada baiknya melihat diskusi sebelumnya, "Why Elixir is the best language for AI"
    Fitur runtime introspection di BEAM adalah poin yang menarik dalam lingkungan agen

  • Go memiliki alat govulncheck untuk menganalisis kerentanan statis pada kode dan biner
    Seperti di tutorial resmi, alat ini terintegrasi sangat dalam ke ekosistem Go dan tingkat integrasinya lebih tinggi daripada di bahasa lain

    • Saya kurang tahu apa bedanya dengan cargo-audit milik Rust
      Saya ragu govulncheck benar-benar menganalisis kerentanan pada kode aktual
    • govulncheck tidak mencari kerentanan dalam kode itu sendiri, melainkan menganalisis apakah library dependensi yang rentan benar-benar digunakan
      Melacak jalur pemanggilan adalah kelebihannya, tetapi ini tetap berbeda dari alat analisis statis sungguhan seperti Coverity
      Di Go, paket alat komunitas seperti golangci-lint terasa lebih dekat ke sana
    • Meski begitu, tingkat integrasi dan kemudahan penggunaan govulncheck tetap lebih unggul dibanding bahasa lain, dan sangat membantu dalam pemeliharaan proyek berskala besar
  • Saya sudah menulis ulang proyek dalam beberapa bahasa, dan Python paling cocok untuk Claude
    Kodenya kecil dan mudah dipahami sehingga kecepatan kerja jauh lebih tinggi
    Saya juga mencoba Go, Kotlin, dan JavaScript, tetapi akhirnya menetap di Python

    • Saya penasaran apakah di kode Python itu penanganan exception atau pernyataan pass ditangani dengan benar
  • Go bukan pilihan yang buruk. Data pelatihannya melimpah dan API-nya stabil sehingga mudah ditangani LLM
    Tetapi saya rasa Rust lebih baik berkat sistem tipenya
    Hanya saja Rust berubah cepat sehingga LLM sulit mengikuti API terbaru
    Haskell justru paling menguntungkan bagi LLM berkat laju perubahannya yang lambat dan kodenya yang aman

    • Kode yang dihasilkan dalam Haskell tampaknya akan lebih pendek dan lebih mudah dibaca dibanding Go
      Script Python juga sama-sama mudah dibaca
  • Dari sudut pandang orang yang bekerja setiap hari dengan agen coding AI, “bahasa terbaik” bergantung pada tujuan agen
    Kesederhanaan dan sifat Go yang mudah diprediksi bagus untuk tugas umum, tetapi TypeScript unggul untuk integrasi dengan lingkungan web
    Python tetap tak tertandingi di ranah data/ML
    Intinya bukan memilih bahasa yang paling mudah ditangani LLM, melainkan bahasa yang sesuai dengan domain agen