- Artikel ini menjelaskan keterbatasan dan masalah bahasa Go yang dirasakan penulis setelah menggunakannya selama bertahun-tahun lalu beralih ke Java
- Artikel ini mengajukan sudut pandang bahwa karakteristik Go sebagai bahasa yang sederhana dan membosankan (
boring) bisa menjadi kelemahan, bukan kelebihan
- Filosofi Go: tim perancang Go di Google menekankan kesederhanaan dan pembatasan, tetapi hal ini memicu pekerjaan berulang yang harus diselesaikan sendiri oleh pengguna
1. Sifat Go yang "tidak menyenangkan" bisa menjadi kelemahan
- Pendapat Russ Cox:
- Ia menekankan bahwa sifat Go yang "membosankan (
boring)" adalah sebuah kelebihan
- Hanya ada satu loop, yaitu
for, dan fitur seperti filter, map, serta reduce tidak disediakan secara bawaan
- Tidak adanya berbagai fitur tingkat lanjut yang tersedia di banyak bahasa lain dianggap sebagai bagian dari kesederhanaan
- Pendapat pengguna Reddit:
- Batas antara "membosankan" dan "kuat" itu kabur
- Mereka berpendapat bahwa kekurangan fitur dasar Go kemungkinan besar pada akhirnya akan ditambahkan ke bahasa tersebut
- Ketergantungan pada paket pihak ketiga:
- Paket
samber/lo yang sering dipakai untuk menutupi kekurangan fitur:
- Mencakup fungsi penting seperti filter, map, dan pencarian
- Memiliki 18.1k bintang di GitHub dan digunakan di lebih dari 12.6k proyek
- Beberapa fungsi memang telah ditambahkan lewat paket
slices, tetapi tetap belum memadai secara fungsional
- Keluhan penulis:
- Dipaksa menulis loop yang berulang-ulang
- Sulit menangani pekerjaan seperti filter dan map secara ringkas
- Memang bisa diekstrak ke metode receiver terpisah, tetapi itu merusak kerapian kode
- Kesederhanaan Go sering kali merupakan kelebihan, tetapi minimnya fitur kenyamanan dasar juga bisa menjadi kekurangan yang menurunkan produktivitas dan keterbacaan kode
2. Menghambat prinsip Clean Code
- Masalah penanganan error:
- Sebagian besar fungsi menyertakan
error sebagai nilai balik:
- Pola
if err != nil harus digunakan berulang kali
- Saat kode dirapikan, justru muncul masalah bahwa kode menjadi lebih rumit
- Kode HTTP handler bahkan pada proyek sederhana bisa membengkak menjadi lebih dari 20 baris
- Padahal target awalnya hanya sekitar 4 baris
- Sampai membuat penulis frustrasi dan mempertimbangkan
panic() serta middleware pemulihan untuk penanganan error
- Anjuran nama pendek:
- Disarankan memakai nama pendek untuk variabel, metode, dan fungsi:
- Nama seperti
c, a tidak jelas artinya
- Misalnya
c itu berarti Command, Controller, Argument, atau Amendment?
- Nama yang lebih panjang bisa membuatnya lebih jelas, tetapi filosofi Go lebih menyukai nama pendek
- Akibatnya, ini memicu perdebatan tanpa akhir saat code review tim, termasuk tentang nama metode pengujian
- Filosofi Go menekankan keringkasan dan kesederhanaan kode, tetapi hasilnya justru bisa menimbulkan kompleksitas dan inefisiensi yang bertentangan dengan prinsip clean code
3. Filosofi bahasa yang sengaja dibuat kecil dan budaya DIY
- Kurangnya fitur bawaan:
- Membuat HTTP handler sederhana memang mudah, tetapi jika memerlukan middleware dasar (misalnya exponential backoff, pengaturan lintas situs, dan sebagainya), kita harus mencari berbagai paket
- Sulit yakin apakah paket-paket itu (1) masih dipelihara dan (2) benar-benar bekerja seperti yang diharapkan
- Peningkatan pekerjaan berulang:
- Filosofi desain Go yang ingin menjaga kesederhanaan justru berujung pada tuntutan agar pengembang "menciptakan ulang roda"
- Contohnya, bahkan fitur filter sederhana pun harus diimplementasikan sendiri
- Ekosistem paket yang belum matang:
- Banyak proyek di GitHub ditelantarkan atau hanya merilis sedikit versi
- Memang agak tidak adil membandingkannya dengan .NET/Java karena Go relatif lebih muda, tetapi secara realistis stabilitas dan kematangan paket Go masih kurang
- Keterbatasan ORM:
- Paket ORM utama Go, Gorm, tertinggal dari Hibernate atau Entity Framework dari sisi fitur
- Ada masalah perilaku aneh dan dokumentasi yang kurang
- Respons komunitas Go: "Go tidak memerlukan ORM, Do It Yourself!"
- Kesederhanaan Go bisa menjadi kelebihan tergantung proyek dan tim, tetapi kekurangan fitur yang tidak tersedia secara bawaan juga dapat berdampak negatif pada produktivitas dan pengalaman pengembangan
4. Di Go, tidak hanya ada satu cara
- Salah paham tentang konsistensi dan keseragaman:
- Table test
- Menggunakan test suite seperti
stretchr/testify (dipakai di 557k proyek)
- Menulis subtest kustom di dalam table test
- Hal ini menunjukkan adanya jarak antara filosofi Go tentang "cara yang seragam" dan kenyataan di lapangan
- Memicu konflik dalam tim:
- Diskusi tentang gaya pengujian dan cara implementasi antartim justru makin sering terjadi
- Filosofi Go dan tim perancangnya sendiri juga kurang konsisten:
- Contoh: ketidaksesuaian soal penamaan metode getter
- Penolakan fitur dan ketergantungan pada paket:
- Tim Go menolak menambahkan fitur assertion dan dikritik karena menyalahkan kekurangan programmer
- Akibatnya, untuk memakai fitur yang dibutuhkan kita harus memasang paket lain lagi dengan
go get
- Go mengarah pada kesederhanaan dan keseragaman, tetapi pada praktiknya ada beragam cara implementasi dan perdebatan yang menyertainya, sementara ambiguitas filosofi desain bahasa memperparah masalah
5. Debugging di Go tidak menyenangkan
- Tidak bisa mengevaluasi ekspresi saat debugging:
- Dalam sesi debugging, kita tidak bisa mengevaluasi ekspresi atau melihat representasi string kustom dari objek
- Akibatnya, sulit memahami keadaan objek secara jelas saat runtime
- Stack trace dan log yang tidak intuitif:
- Saat pengujian skala besar gagal (misalnya ribuan test berjalan di CI), yang muncul adalah stack trace dan log yang membingungkan
- Pada akhirnya debugging menjadi sulit dan produktivitas menurun
- Pengalaman debugging ala C:
- Rangkaian alat debugging Go bekerja dengan pendekatan berbasis C:
- Memberikan pengalaman debugging primitif yang mirip C
- Kurang ramah bagi pengembang
- Perbandingan dengan Rust:
- Rust memperbaiki keterbatasan Go:
- Menyediakan informasi error yang jelas dan berguna
- Pesan error menyertakan saran perbaikan yang tepat
- Pengalaman debugging Go didasarkan pada filosofi desain yang berfokus pada penyediaan binary yang optimal, tetapi ini berujung pada pengorbanan pengalaman pengembang. Dalam lingkungan yang mengutamakan efisiensi debugging, mempertimbangkan bahasa alternatif bisa menjadi pilihan yang lebih baik
Ringkasan: Kecocokan dan keterbatasan Go
- Kelebihan tool bawaan Go:
- Menyediakan toolchain dasar untuk manajemen paket, testing, dan pemantauan performa
- Dapat digunakan tanpa konfigurasi terpisah sehingga menyederhanakan penyiapan lingkungan pengembangan awal
- Keterbatasan:
- "Kode yang membosankan" dan pekerjaan berulang:
- Toolchain Go memang fungsional, tetapi saat menulis kode ia memaksa pekerjaan berulang (
Plumbing Code)
- Contoh: sintaks yang monoton dan fitur yang terbatas membuat pekerjaan terasa kurang menarik
- "import cycle not allowed":
- Dependensi siklik (
import cycle) tidak diizinkan dalam test
- Dalam pekerjaan domain-driven design (DDD), batasan struktural ini meningkatkan kompleksitas
- Ketergantungan pada teknik embedding
struct:
- Mekanisme embedding
struct yang aneh dan terbatas menimbulkan kesulitan dalam penggunaan
- Area penggunaan yang cocok:
- Cocok untuk pengembangan infrastruktur:
- Tool tingkat sistem seperti Docker, Drone, dan Hugo ditulis dengan Go
- Berguna untuk pengembangan server ringan dan aplikasi CLI
- Area penggunaan yang kurang cocok:
- Pengembangan aplikasi enterprise yang kompleks (misalnya sistem ERP):
- Filosofi bahasa dan tool yang terbatas membuat pengelolaan logika bisnis skala besar menjadi tidak efisien
- Go memberikan efisiensi yang sangat baik untuk pekerjaan tertentu, khususnya yang terkait infrastruktur, tetapi bukan alat yang cocok untuk aplikasi domain bisnis yang kompleks. Bahkan jika CTO condong pada tech stack Google, pemilihan teknologi tetap perlu dilakukan dengan hati-hati
5 komentar
Kalau saja ada
?seperti di Rust, bukankah itu akan jauh lebih baik daripada sekarang...Saat menggunakan Go, saya jadi berpikir selama ini seberapa banyak penanganan error yang saya lakukan secara implisit.
Tentu saja, menangani error di satu titik bisa terlihat lebih rapi secara struktural, tetapi menurut saya dengan secara eksplisit menunjukkan bahwa suatu operasi dapat menghasilkan respons error, kita jadi menulis kode dengan cara yang lebih aman.
if err != nil {}ini sejujurnya memang agak merepotkan. Saya juga setuju dengan kekurangan-kekurangan yang disorot. Meski begitu, kalau kita memahami dengan jelas arah yang ingin dituju bahasa ini dan memikirkan aspek mana yang bisa lebih dimanfaatkan, rasanya kita tetap bisa memakainya dengan lebih baik terlepas dari kekurangan-kekurangan tersebut. Mirip C, tapi punya GC, mendukung generic meski terbatas, dan bahkan bisa cross-compile! Kalau dilihat seperti ini, bukankah ini bahasa yang cukup murah hati?Saat beralih dari Java ke Go, awalnya saya merasa kesannya agak mirip.
Sekarang saya sangat menikmati Go sampai-sampai merasa waktu yang saya habiskan untuk Java itu sayang. Anggapan bahwa Go tidak cocok untuk aplikasi bisnis yang kompleks justru membuat saya berpikir bahwa aplikasi tersebut belum cukup dipikirkan untuk menyederhanakan sistemnya.
Opini Hacker News
Masalah muncul ketika pengembang Java memaksakan gaya Java ke Go
Banyak pengembang mencoba melakukan abstraksi terlalu dini
Pustaka standar Go besar, tetapi tidak cukup besar untuk melakukan segalanya
Ada tantangan yang lebih besar daripada memilih bahasa pemrograman
Sulit memahami alasan orang menyukai Go
Tim inti Go yang membatalkan keputusan yang salah menimbulkan frustrasi
Go memiliki masalah yang mirip dengan UNIX