Kebohongan yang Kita Katakan pada Diri Sendiri agar Tetap Menggunakan Golang (2022)

• Penulisnya platipus

  • Mengabaikan kritik dengan menganggap penulisnya tidak kompeten adalah cara yang malas.
  • Pengembang junior dapat melihat masalah dari sudut pandang baru, dan itu adalah alasan penting untuk mempekerjakan mereka.
  • Penulis bukan pengembang junior, dan memiliki pemahaman tentang desain bahasa melalui beragam pengalaman.

• Ibu juga merokok, jadi pasti tidak apa-apa

  • Mengikuti teknologi yang digunakan perusahaan lain tanpa berpikir adalah hal yang tidak efisien.
  • Blog teknologi punya tujuan untuk membuat citra perusahaan terlihat baik.
  • Blog Tailscale jujur, tetapi perlu banyak upaya untuk mengatasi masalah Go.

• Bagian yang bagus

  • Go memiliki runtime asinkron dan garbage collector yang sangat baik.
  • Alat untuk manajemen paket, refactoring, cross-compiling, dan sebagainya mudah digunakan.
  • Namun, kekurangan Go tidak bisa diabaikan, dan masalahnya adalah desain bahasanya terbentuk secara kebetulan.

• Go adalah pulau

  • Go kurang memiliki interoperabilitas dengan bahasa lain.
  • Toolchain Go itu unik, dan bahasa assembly atau debugger yang sudah ada tidak bisa digunakan.
  • Mengintegrasikan Go melalui batas jaringan adalah cara yang paling mudah.

• Semua atau tidak sama sekali (jadi tidak melakukan apa pun)

  • Go dapat membiarkan field struct tidak diinisialisasi.
  • Gagasan bahwa zero value selalu bermakna adalah pemikiran yang naif, dan dalam banyak kasus menjadi masalah.
  • Budaya Go cenderung berkata untuk berhati-hati alih-alih menyelesaikan masalah.

• "Rust itu sempurna dan kalian semua bodoh"

  • Rust dapat diadopsi secara bertahap dan terintegrasi dengan baik dengan bahasa lain.
  • Keberhasilan Rust sebagian berasal dari fakta bahwa transisi ke bahasa yang aman itu dimungkinkan.
  • Rust juga memiliki masalah, tetapi itu sedang diselesaikan secara bertahap.

• Menggunakan Go sebagai bahasa prototipe/starter

  • Go dianggap sebagai bahasa yang mudah dipelajari, tetapi pada kenyataannya membutuhkan banyak pengalaman.
  • Go kurang memiliki fitur yang secara jelas memberi tahu bahwa kode itu salah.
  • Kekurangan Go muncul seiring waktu, dan ini bukan bahasa yang mudah ditinggalkan.

• Kebohongan yang kita katakan pada diri sendiri tentang alasan kita terus menggunakan Golang

  • Karena orang lain memakainya, maka itu pasti baik juga untuk kita
  • Menganggap cacat desain bahasa sebagai sesuatu yang bisa diterima, baik secara individu maupun kolektif
  • Berpikir bahwa masalah bisa diatasi jika kita cukup berhati-hati
  • Berpikir bahwa karena mudah ditulis, maka pengembangan software produksi juga mudah
  • Berpikir bahwa karena bahasanya sederhana, maka semuanya sederhana
  • Berpikir bahwa nanti kita selalu bisa menulis ulang kapan saja

[tsboard]

Saya sempat ragu apakah pantas menulis, mengingat saya ini cuma amatir yang baru berkutat cukup intens dengan bahasa Go dalam waktu yang sangat singkat... Go memang punya kelebihan dan kekurangan yang sangat jelas, jadi baik yang memilih maupun yang menghindarinya tampaknya punya alasan yang tegas. Secara pribadi, rasanya kurang tepat membandingkannya dengan Rust, dan lebih masuk akal jika dibandingkan dengan Kotlin(Java).

Goroutine di Go memang luar biasa, tetapi bukan sihir. Terutama pada proyek kecil di backend yang hanya memakai satu MySQL, concurrency ini justru sangat merepotkan untuk dikelola. Masalah kehabisan resource MySQL atau pengelolaan pool, yang di runtime JS/TS tidak terlalu perlu dipikirkan, ternyata lebih sulit dari yang dibayangkan. Pada akhirnya, dalam situasi seperti ini DB menjadi bottleneck, sehingga keunggulan Go dalam concurrency agak memudar. (Asynchronous I/O atau event loop pada runtime JS/TS justru bisa jadi lebih cocok) Coba saja langsung hajar dengan alat seperti hey pakai -c 100, nanti akan terasa.

Lalu, meski GC-nya sangat bagus, bukan berarti kita bisa sembarangan hanya melempar pointer ke objek lalu masa bodoh dengan beres-beresnya. Semua ada trade-off, tetapi di Go juga, kalau memungkinkan, objek kecil sebaiknya cukup diteruskan dengan copy by value agar bisa langsung ditangani saat fungsi selesai. Mungkin saya terjebak dalam pola pikir lama, tetapi saya merasa pointer tidak boleh diperlakukan terlalu enteng dari sudut pandang efisiensi seperti di bahasa C/C++.

Harus mengembalikan error hampir setiap kali fungsi return, lalu setiap kali juga harus mengeceknya dengan if err != nil {} memang sangat merepotkan, tetapi ini justru kelebihan. Biayanya lebih murah daripada try catch. Dan keyword defer yang berperan seperti finally {} juga sangat bagus. Menyenangkan karena kita tidak perlu terlalu memikirkan kapan resource harus dilepas. Saya juga suka karena hanya dengan standard library saja kita sudah bisa langsung menyusun server backend yang sangat baik (1.23 ke atas). Yang paling bagus dari semuanya, jika dibuild sesuai target OS, kita tidak memerlukan runtime lain atau instalasi awal tambahan.

Saya belum lama memakai Go, jadi rasanya tulisan ini jadi terlalu panjang untuk opini yang sangat pribadi, maka saya sudahi di sini. Hehe, saya suka bahasa Go, dan saya juga suka bahasa-bahasa lain!

[GN⁺]

Pendapat Hacker News

• Ada banyak kritik terhadap kekurangan bahasa Go, tetapi penanganan error eksplisit bukan salah satunya. Penanganan exception menambahkan lapisan seperti "sihir" yang membuat orang terlalu mudah melakukan kesalahan. Untuk proyek pribadi, saya lebih memilih Rust, tetapi dalam proyek besar yang melibatkan pengembang dengan tingkat kemampuan beragam, filosofi Go adalah pendekatan penanganan error paling masuk akal di dunia modern.

  • Berkat kesederhanaannya, Go diadopsi lebih luas daripada bahasa-bahasa "baru" lainnya. Ini memang bukan bahasa terbaik, tetapi karena banyak opini yang sudah tertanam di dalamnya, sering kali justru menjadi pilihan terbaik sebagai bahasa serbaguna.

• Rust dan Go sangat berbeda, dan titik tengah yang diinginkan orang saat ini belum ada.

  • Dibutuhkan bahasa yang relatif sederhana dengan sistem tipe yang mirip Rust.
  • Gleam dan Kotlin agak mirip, tetapi tidak sepenuhnya demikian. Rust terlalu kompleks sehingga sulit bagi orang nonteknis atau nonspesialis.
  • Tidak ada bahasa yang sempurna, tetapi Go dan Rust membawa hal-hal yang luar biasa. Semoga lahir bahasa pemrograman sederhana yang tersedia luas dan terinspirasi dari keduanya.

• Saya menyukai bahasa yang sederhana. Karena teknologi selalu punya trade-off, kritik yang seimbang itu penting.

  • Membagikan tautan blog tentang alasan memilih Go.

• Saya penasaran kenapa mengkritik bahasa itu dianggap begitu penting. Kritiknya juga tidak ditulis dengan gaya yang konstruktif.

  • Semua bahasa bisa dikritik. Go tetap bekerja dengan sangat baik dalam proyek meskipun berbeda dari bahasa yang "lebih canggih".
  • Tetap memberi masukan kepada tim Go, mengamati perkembangan bahasa yang lambat, dan terus berkontribusi pada komunitas.

• Setiap kali membaca kritik terhadap Go, saya tetap akan terus menggunakannya.

  • Secara teori ada banyak masalah, tetapi dalam praktiknya ini tetap bahasa pemrograman yang bagus.
  • Saya suka penanganan error eksplisit. Saya juga tidak terlalu mempermasalahkan kekurangan bahasa lain.
  • Orang yang sensitif terhadap kekurangan Go akan terus mengeluh. Pilih saja bahasa yang paling cocok untuk diri sendiri.

• Setiap kali memakai bahasa lain, saya jadi ingin kembali ke Go.

  • Di Go, tinggal instal, unduh kodenya, lalu mulai menulis. Tidak perlu pusing memikirkan versi, runtime, konfigurasi, build tool, package manager, dan sebagainya.
  • Rust juga bisa memberikan pengalaman yang mirip. Saat memakai Python, Typescript, atau Java, saya takut memrogram karena masalah terkait konfigurasi.

• Saya sedang mencari Python yang lebih baik. Go adalah pilihan yang jelas, tetapi saya tidak suka sintaksnya.

  • Rust memakai terlalu banyak karakter khusus, dan saya tidak suka Lisp karena kurung dan notasi Polandia terbalik.
  • Saya mengompilasi kode Python dengan Nuitka untuk menyediakan biner. Saya juga tertarik pada kompilasi AOT di C#.
  • Saya suka Nim dan Crystal, tetapi komunitas yang kecil menjadi hambatan. Nim adalah bahasa yang hebat meski komunitasnya kecil.

• Saya tidak paham kenapa Go dan Rust sering dibandingkan. Dibandingkan dengan Java akan lebih tepat.