- Berbagai keputusan desain bahasa Go dibuat secara tidak perlu atau dengan mengabaikan pengalaman yang sudah ada
- Masalah pengelolaan cakupan variabel error membuat keterbacaan kode dan pelacakan bug menjadi lebih sulit
- Dalam berbagai aspek seperti dualisme nil, penggunaan memori, dan portabilitas kode, muncul desain yang tidak intuitif dan tidak sesuai dengan kenyataan
- Keterbatasan sintaks defer serta cara penanganan pengecualian di pustaka standar membuat jaminan exception safety sulit dicapai
- Masalah yang terakumulasi seperti pengelolaan memori dan penanganan UTF-8 yang buruk dalam jangka panjang berdampak negatif pada kualitas codebase Go
Kritik jangka panjang terhadap bahasa Go
- Seperti yang telah diungkapkan dalam posting sebelumnya (Why Go is not my favourite language, Go programs are not portable), saya telah menunjukkan berbagai masalah bahasa Go selama lebih dari 10 tahun
- Secara khusus, keputusan desain yang tidak perlu yang mengabaikan praktik baik yang sudah dikenal terasa makin disayangkan
Ketidakintuitifan cakupan variabel error
- Sintaks Go memperluas cakupan variabel error (
err) secara tidak perlu sehingga meningkatkan kemungkinan kesalahan
- Dalam contoh kode, variabel
err tetap hidup di seluruh fungsi dan digunakan kembali, sehingga keterbacaan dan maintainability kode menurun
- Bahkan developer berpengalaman mengalami salah paham dan membuang waktu saat melacak bug karena masalah cakupan seperti ini
- Cara untuk membatasi variabel secara lokal dengan tepat tidak diizinkan oleh sintaks
Dua bentuk nil
- Di Go ada kebingungan karena
nil berperilaku berbeda pada tipe interface dan tipe pointer
- Seperti pada contoh di bawah, meskipun
nil diberikan ke s (pointer) dan i (interface), s==i dievaluasi berbeda, menunjukkan perilaku yang tidak konsisten
- Ini adalah jenis masalah yang umumnya ingin dihindari dalam penanganan null, dan menunjukkan jejak desain yang dibuat tanpa pertimbangan memadai
Batasan portabilitas kode
- Penggunaan komentar untuk conditional compilation sangat tidak efisien dari sisi maintainability dan portabilitas
- Jika pernah benar-benar membuat perangkat lunak portabel, mudah dipahami bahwa cara seperti ini merepotkan dan rawan kesalahan
- Pengalaman historis yang telah terkumpul (portabilitas kode, contoh praktis di lapangan) diabaikan
- Untuk detail lebih lanjut, lihat Go programs are not portable
Ketidakjelasan kepemilikan append
- Hubungan kepemilikan antara fungsi
append dan slice tidak jelas, sehingga perilaku kode sulit diprediksi
- Melalui contoh, sulit mengetahui sebelumnya dampak sebenarnya pada data asli ketika sebuah slice di-append di fungsi
foo
- Semakin banyak ‘quirk’ bahasa yang harus dihafal, sehingga memicu kesalahan
Desain sintaks defer yang kurang matang
- Tidak mendukung pelepasan resource secara jelas seperti prinsip RAII (Resource Acquisition Is Initialization)
- Dibandingkan dengan sintaks manajemen resource terstruktur di Java dan Python, Go tidak memperjelas resource mana yang harus dilepas dengan
defer
- Seperti dalam contoh pekerjaan file, bahkan masalah double-close harus ditangani sendiri, dan urutan serta cara pelepasan yang benar tidak jelas
Penanganan pengecualian di pustaka standar
- Go adalah struktur yang tidak mendukung exception secara eksplisit, tetapi situasi pengecualian seperti
panic tetap bisa terjadi
- Ada juga kasus ketika
panic dalam situasi tertentu tidak sepenuhnya menghentikan program dan malah terserap diam-diam
- Ada pola di pustaka standar (
fmt.Print, server HTTP, dll.) yang mengabaikan pengecualian, sehingga jaminan exception safety yang sesungguhnya tidak mungkin dicapai
- Pada akhirnya, menulis kode yang aman terhadap exception tetap wajib, tetapi exception tidak bisa digunakan secara langsung
Penanganan UTF-8 dan string
- Meskipun tipe
string diisi data biner arbitrer, Go tetap berjalan tanpa validasi khusus
- Nama file yang dibuat sebelum encoding UTF-8, misalnya, bisa diam-diam terlewat
- Data penting dapat hilang dalam proses seperti backup, dan ini merupakan pendekatan sederhana yang tidak mencerminkan kondisi dunia nyata
Batasan pengelolaan memori
- Sulit mengendalikan penggunaan RAM secara langsung, dan keandalan GC (garbage collection) juga memiliki batasan
- Penggunaan memori Go meningkat dan dalam jangka panjang terhubung ke masalah biaya serta performa
- Dalam lingkungan multi-instance dan container, masalah biaya serta skalabilitas benar-benar terjadi
Kesimpulan: ada jalan yang lebih baik
- Walaupun desain bahasa yang telah terbukti efektif sebenarnya sudah ada, Go justru mengabaikannya di banyak bagian
- Berbeda dari masalah pada rancangan awal Java, ketika Go dirilis sebenarnya sudah ada pendekatan yang lebih baik
Referensi
Belum ada komentar.