Bahasa Go: Apa yang Kami Lakukan dengan Benar dan Salah

 (commandcenter.blogspot.com)
3 poin oleh GN⁺ 2024-01-05 | 1 komentar | Bagikan ke WhatsApp
  • Selama 14 tahun sejak dirilis sebagai open source pada 10 November 2009, Go berkembang dengan tujuan bukan sekadar menjadi bahasa baru, melainkan cara untuk memudahkan pembuatan software produksi
  • Spesifikasi formal, beberapa implementasi compiler, cross compile yang mudah, jaminan kompatibilitas setelah Go 1.0, standard library, dan gofmt mendukung adopsinya
  • Concurrency untuk menyusun software server menjadi kekuatan Go, tetapi pada awalnya perbedaan dengan parallelism dan kasus penggunaan yang tepat tidak dijelaskan dengan cukup, sehingga menimbulkan kebingungan
  • Interface menjadi fondasi library, testing, manajemen dependensi, dan desain berbasis composition, sementara ketiadaan generics membuat desain polimorfik sulit selama lebih dari 10 tahun berikutnya
  • Dalam manajemen package, dokumentasi, dan kolaborasi komunitas ada banyak trial and error, tetapi Go menargetkan lingkungan tempat kode tetap terlihat serupa dan terus bisa dibangun meski penulis dan waktunya berbeda

Tujuan Go: cara mengembangkan software, bukan sekadar bahasa

  • 10 November 2023 menandai ulang tahun ke-14 sejak Go dirilis sebagai proyek open source
  • Saat dirilis pada 2009, Ken Thompson, Robert Griesemer, Russ Cox, Ian Taylor, Adam Langley, Jini Kim, dan lainnya menyaksikan pembukaan proyek ini
  • Tujuan awal Go bukanlah bahasa pemrograman baru itu sendiri, melainkan menulis software berkualitas tinggi dengan cara yang lebih baik
  • Hambatan saat itu lebih terletak pada kompleksitas proses pembuatan software server modern di Google daripada pada fitur bahasa itu sendiri
    • Pengendalian dependensi
    • Tim besar dan struktur personel yang berubah
    • Kemudahan pemeliharaan
    • Testing yang efisien
    • Pemanfaatan CPU multicore dan networking
  • Hingga kini, Go didefinisikan sebagai proyek untuk membuat pembangunan software produksi lebih mudah dan produktif

Identitas komunitas yang dibentuk oleh maskot Gopher

  • Go gopher adalah salah satu faktor awal keberhasilan Go
  • Gopher yang dibuat oleh Renee French menjadi simbol bersama para programmer Go dan berperan sebagai panji komunitas
  • Seperti konferensi bernama GopherCon, gopher membentuk suasana proyek yang memadukan keunggulan teknis dan kesenangan
  • Keputusan merilisnya dengan lisensi Creative Commons Attribution memiliki kelebihan dan kekurangan
    • Mendorong remix dan variasi, sehingga menumbuhkan semangat komunitas
    • Syarat attribution juga memicu perdebatan atau membuat kredit keliru ditempelkan pada karya yang tidak dibuat oleh Renee French
  • Mengelola agar maskot tetap mempertahankan semangat aslinya masih menjadi tantangan yang sulit

Pilihan teknis yang dilakukan Go dengan benar

  • Menulis spesifikasi formal terlebih dahulu untuk menetapkan perilaku implementasi compiler dan memungkinkan beberapa implementasi menyepakati perilaku yang sama
    • Ada penilaian bahwa satu compiler saja tidak bisa menjadi spesifikasi
    • Draf spesifikasi pertama ditulis di lantai 18 sebuah gedung di Sydney Darling Harbour
  • Beberapa implementasi compiler membantu menyempurnakan bahasa dan spesifikasinya
    • Pada 7 Juni 2008, Ian Taylor mengirim email bahwa ia telah membaca draf spesifikasi Go dan membuat gcc front end
    • Setelah itu, berbagai implementasi kompatibel lain juga muncul
  • Dengan membuat cross compile mudah, developer bisa bekerja di platform yang diinginkan dan mendistribusikan ke platform yang diperlukan
  • Keputusan memperkenalkan jaminan kompatibilitas setelah merapikan bahasa pada Go 1.0 sangat memengaruhi adopsi Go
    • Mempertahankan kompatibilitas yang kuat memang ada biayanya, tetapi mengurangi kekhawatiran bahwa rilis Go baru akan merusak proyek
  • Standard library menyediakan sebagian besar fungsi yang dibutuhkan untuk menulis kode server abad ke-21, dan membuat komunitas bekerja di atas toolbox yang sama
    • Pada awalnya, library juga membesar karena belum ada tempat lain untuk memasang kode Go
    • Ini membantu mengurangi menjamurnya library varian dan menyatukan komunitas

Pengalaman development yang dibentuk oleh tool dan gofmt

  • Go dirancang sebagai bahasa yang mudah di-parse, sehingga pembuatan tool menjadi mudah
  • Awalnya IDE dianggap diperlukan, tetapi seiring tooling menjadi mudah, IDE mulai mendukung Go dan gopls juga muncul
  • Bersama compiler, tersedia tool pendukung seperti automated testing, coverage, dan code vetting
  • Perintah go menyatukan seluruh proses build, dan banyak proyek bisa menyelesaikan sebagian besar kebutuhan build dan pemeliharaan kode Go dengan perintah ini
  • gofmt menjadi tool yang berpengaruh bukan hanya pada Go, tetapi juga pada komunitas pemrograman secara keseluruhan
    • Robert Griesemer sejak awal bersikeras agar gofmt dibuat
    • Sebelum gofmt, kualitas auto formatter tidak tinggi sehingga hampir tidak digunakan
    • Waktu yang dihabiskan untuk berdebat soal spasi dan line break berkurang
    • Karena bagian dalam gofmt menjadi library, AST bisa di-parse, dimodifikasi, lalu dibuat kembali menjadi output yang bisa dibaca manusia
    • Tool lain seperti simplifier, analyzer, dan code coverage tool juga menjadi mungkin

Concurrency: fitur yang kuat, tetapi terlambat dijelaskan

  • Pada 2002, software Google hampir menghindari thread, dan ada suasana yang menghalangi penggunaannya dengan mengutip pandangan John Ousterhout bahwa “threads were bad”
  • Go berangkat dari pengalaman bahwa concurrency bisa digunakan dengan cara yang lebih baik daripada package level rendah seperti pthread
  • Go berperan penting dalam membuat dunia pemrograman menerima concurrency sebagai tool yang kuat
    • Dampaknya sangat besar terutama di lingkungan multicore dan jaringan
    • Saat ini sebagian besar bahasa arus utama memiliki dukungan concurrency
  • Go tidak memakai nama seperti coroutine, task, atau thread, tetapi menciptakan istilah baru, goroutine
  • async/await adalah perbaikan besar dibanding pthread, tetapi jika dibandingkan dengan goroutine, channel, dan select, meski lebih mudah dan kecil bagi implementer, ia bisa mengembalikan sebagian kompleksitas kepada programmer
    • Masalah Bob Nystrom “What Color is Your Function?” digunakan sebagai contoh
    • Model CSP Go cocok dengan bahasa prosedural, tetapi memerlukan kompleksitas runtime agar diimplementasikan dengan benar
    • Jika ada beberapa implementasi concurrency dalam satu lingkungan, itu bisa menjadi masalah, sehingga Go memasukkannya ke bahasa, bukan ke library

Dua kesalahan dalam concurrency

  • Tim Go pada awalnya tidak memberi panduan yang cukup tentang di mana concurrency sebaiknya digunakan
    • Penggunaan utamanya adalah menyederhanakan software server di library inti seperti net/http
    • Ini bukan fitur yang harus dipakai di semua bagian dari semua program
  • Terlambat menjelaskan perbedaan antara parallelism dan concurrency juga menjadi masalah
    • Banyak developer mencoba memparalelkan kode dengan goroutine agar lebih cepat, tetapi justru bingung ketika hasilnya lebih lambat
    • Kode concurrent hanya bisa menjadi lebih cepat lewat parallelization ketika masalahnya sendiri memang paralel, misalnya pemrosesan request HTTP
  • Untuk melengkapinya, pada 2012 di Waza disampaikan presentasi “Concurrency is not Parallelism”
  • Penjelasan ini seharusnya dilakukan lebih awal
  • Meski begitu, Go berkontribusi dalam memopulerkan concurrency sebagai cara menyusun software server

Interface dan desain berbasis composition

  • Interface adalah ide inti yang membedakan Go bersama concurrency
  • Interface Go mendekati jawaban Go atas desain object-oriented berbasis perilaku yang asli
  • Cara dinamis yang tidak mengharuskan deklarasi lebih dulu bahwa sebuah type mengimplementasikan interface tertentu awalnya dikritik, tetapi penting bagi pemrograman gaya Go
  • Standard library, testing, dan manajemen dependensi sangat bergantung pada sifat terbuka interface
  • sort di Go diimplementasikan sebagai fungsi yang bekerja di atas interface
    • Ini berbeda dari gaya object-oriented yang akrab bagi banyak orang, tetapi merupakan ide yang kuat
  • Interface kecil seperti Reader, Writer, dan empty interface menjadi fondasi library Go
    • Tiga interface terkenal ini rata-rata masing-masing memiliki 2/3 method
    • Kumpulan method yang kecil menjadi idiom khas Go

Jalan memutar panjang seputar generics

  • Tim Go telah melihat bahwa pemrograman generik cenderung membuat orang memikirkan type sebelum algoritme
    • Lebih menyukai desain organik daripada abstraksi awal
    • Lebih menekankan fungsi daripada container
  • Go memasukkan generic container seperti map, slice, array, dan channel ke dalam bahasa, tetapi tidak memberikan genericity itu secara langsung kepada pengguna
  • Dinilai bahwa sebagian besar tugas pemrograman sederhana sudah cukup dengan type-type tersebut, tetapi ada kasus yang tidak demikian, dan batas ini membuat sebagian pengguna merasa tidak nyaman
  • Karena interface adalah fondasi pemrograman Go, model polimorfisme baru harus cocok dengan interface
    • Ada beberapa percobaan dan implementasi yang dihentikan
    • Setelah banyak diskusi, bantuan juga datang dari para ahli teori tipe yang dipimpin Phil Wadler
  • Pada akhirnya, Go merancang generics dengan menggeneralisasi interface dari “kumpulan method” menjadi “kumpulan type”
  • Istilah “generics” berasal dari polimorfisme berbasis struktur data, sehingga tidak secara tepat menunjuk parametric polymorphism yang disediakan Go, tetapi dalam praktiknya istilah generics yang digunakan

Compiler: awalnya C, kemudian Go

  • Fakta bahwa compiler Go awal ditulis dalam C membuat sebagian komunitas bahasa merasa tidak nyaman
    • Ada pendapat bahwa seharusnya memakai toolkit seperti LLVM atau self-hosting dengan Go sendiri
  • Alasan compiler pertama ditulis dalam C bersifat praktis
    • Untuk melakukan bootstrap bahasa baru, dibutuhkan bahasa yang sudah ada
    • Ken Thompson sudah menulis compiler C, dan struktur internalnya bisa menjadi dasar compiler Go
    • Jika merancang bahasa sambil sekaligus menulis compiler dengan bahasa itu, desain bisa condong menjadi bahasa yang bagus untuk menulis compiler
  • Compiler awal menghasilkan kode yang biasa saja dan bagian dalamnya juga tidak rapi, tetapi kecil, familier, dan mudah diubah dengan cepat
  • Penambahan segmented stack yang bertumbuh otomatis menunjukkan kelebihan pilihan ini
    • Jika memakai toolkit seperti LLVM, perubahan dukungan ABI dan garbage collector juga harus disertakan, sehingga integrasinya akan sulit
  • Struktur yang berasal dari keluarga compiler Plan 9 semula juga cocok untuk cross compile
  • Pada Go 1.5, Russ Cox menulis tool yang menerjemahkan compiler dari C ke Go secara semi-otomatis
    • Pada titik ini, bahasanya sudah selesai sehingga kekhawatiran tentang desain bahasa yang berpusat pada compiler hilang
    • Setelah dipindahkan ke Go, kelebihan Go seperti testing, tooling, automatic rewriting, dan analisis performa bisa diterapkan juga pada pengembangan compiler
  • Saat ini ada compiler Go berbasis LLVM dan beberapa compiler lain

Operasi proyek open source dan komunitas

  • Sejak awal Go dinilai harus menjadi proyek open source agar berhasil
  • Namun, sebelum ide inti dan implementasi perilakunya dirapikan, pengembangan secara tertutup dianggap lebih produktif
    • Dua tahun pertama sebelum rilis publik penting untuk memperjelas tujuan
  • Setelah beralih menjadi open source, masukan komunitas sangat besar, dan khususnya Ian Taylor menghabiskan banyak waktu untuk menjawab pertanyaan
  • Port Windows sepenuhnya dilakukan oleh komunitas di bawah arahan Alex Brainman
  • Tim Go membutuhkan waktu lama untuk memahami cara terbaik berkolaborasi dengan komunitas
    • Mereka merasa telah berkomunikasi dengan baik, tetapi kesalahpahaman dan ketidakselarasan ekspektasi membuang banyak waktu
  • Proyek Go memilih cara memastikan kualitas kode yang tinggi sebelum merge, bukan menerima kode cepat lalu merapikannya belakangan
    • Code review wajib
    • Perhatian menyeluruh pada detail
  • Cara ini memberi beban lebih besar pada komunitas, sehingga jika kontributor tidak memahami nilainya, mereka bisa merasa tidak disambut
  • Riwayat repository proyek Go telah melewati SVN, Perforce, Mercurial, dan Git, tetapi Russ Cox mempertahankan riwayatnya sehingga catatan perubahan SVN awal tetap ada di repository Git saat ini
  • Google mendukung Go tetapi tidak menetapkan agenda tim Go
    • Codebase Go besar di internal Google digunakan untuk menguji dan memvalidasi rilis
    • Alurnya adalah mengambil dari repository publik ke Google, bukan sebaliknya
    • Tim inti Go digaji oleh Google tetapi bergerak secara independen

Trial and error dalam manajemen package

  • Desain package dalam bahasa Go sendiri sangat baik, tetapi proses pengembangan manajemen package tidak berjalan dengan baik
  • Menentukan path sebagai string biasa dalam pernyataan import adalah pilihan penting dan fleksibel
  • Masalahnya adalah transisi dari keadaan yang hanya memiliki standard library ke cara mengambil kode dari web berlangsung sulit
  • Tim Go awal terbiasa dengan monorepo Google dan cara build dari head
    • Pengalaman menggunakan package manager dengan beberapa versi package belum cukup
    • Kompleksitas teknis dalam menyelesaikan dependency graph tidak ditangani sejak awal
  • Pekerjaan deps.dev diperlakukan seperti semacam kompensasi atas masalah ini
  • Upaya memecahkan masalah manajemen dependensi bersama komunitas didorong oleh niat baik, tetapi ketika desain akhir keluar, banyak anggota komunitas merasa tersisih
  • Pengalaman ini menjadi pelajaran tentang bagaimana partisipasi komunitas sebenarnya harus dilakukan, dan setelah itu banyak perbaikan terjadi
  • Saat ini desainnya sudah stabil, bagus secara teknis, dan tampaknya bekerja baik untuk sebagian besar pengguna

Dokumentasi dan contoh yang dapat dijalankan

  • Banyak dokumentasi ditulis pada awalnya, tetapi tidak sesuai dengan tingkat yang diinginkan komunitas
  • Bagian yang paling kurang adalah bahwa bahkan fungsi paling sederhana pun memerlukan contoh penggunaan
    • Menunjukkan cara menggunakan lebih bernilai daripada mengatakan apa yang dilakukan
  • Saat ini dokumentasi memiliki banyak contoh, dan sebagian besar disediakan oleh kontributor open source
  • Sejak awal Go membuat contoh bisa dijalankan di web
    • Pada presentasi Google I/O 2012, potongan kode yang menunjukkan concurrency dibuat bisa dijalankan di browser
    • Andrew Gerrand menulis teknologi web yang memungkinkan hal ini
    • Setelah itu, fitur ini juga didistribusikan ke blog dan dokumentasi package online
  • The Go playground disediakan sebagai sandbox publik tempat orang bisa bebas mencoba dan mengembangkan kode

Posisi yang dicapai Go setelah 14 tahun

  • Berkat keputusan yang diambil dalam desain bahasa dan proses pengembangannya, Go telah menjadi bukan sekadar bahasa pemrograman, melainkan cara menulis software
  • Posisi yang dicapai Go didukung oleh elemen-elemen berikut
    • Standard library kuat yang mengimplementasikan sebagian besar fungsi dasar yang dibutuhkan kode server
    • Concurrency sebagai komponen first-class bahasa
    • Pendekatan berbasis composition daripada inheritance
    • Model packaging yang memperjelas manajemen dependensi
    • Tool build dan testing yang terintegrasi dan cepat
    • Formatting yang ketat dan konsisten
    • Sikap yang lebih mengutamakan keterbacaan daripada kepintaran
    • Jaminan kompatibilitas
  • Komunitas Go terdiri dari para Gopher yang beragam dan aktif, serta memainkan peran inti dalam keberhasilan proyek
  • Akibatnya, kode Go terlihat dan bekerja secara serupa siapa pun penulisnya, relatif sedikit faksi yang memakai subset bahasa berbeda, dan dijamin tetap bisa dikompilasi serta dijalankan seiring waktu
  • Karakteristik seperti ini dapat dipandang sebagai hasil yang jarang dalam bahasa pemrograman besar

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-05
Opini Hacker News

  • Sangat patut diapresiasi ketika tokoh-tokoh kunci meluangkan waktu untuk menulis retrospeksi, dan ini sangat membantu orang-orang yang sekarang benar-benar ingin membuat perubahan
    Namun, rasanya Rob Pike belum cukup jelas mengatakan apa saja yang dilakukan Go dengan benar. Go mengelola dengan baik bukan hanya bahasanya sendiri, tetapi juga kekuatan-kekuatan yang bekerja pada proyeknya: membatasi sasaran penggunaannya pada pemrograman sistem, mendefinisikan bahasa dan prinsipnya dengan jelas, mempertahankan sikap yang mengutamakan kualitas dengan memperbaiki masalah sebelum rilis, serta mengontrol bahasa, rilis, dan pesan inti secara ketat sambil tetap memberi ruang bagi komunitas untuk memimpin di area-area bawahan
    Satu hal yang kurang diapresiasi adalah Google sendiri tidak terlalu banyak ikut campur. Mungkin karena Go benar-benar berkontribusi pada tujuan Google dan memang penting. Apakah hal seperti itu masih bisa terjadi pada proyek baru hari ini masih menjadi pertanyaan
    Dart hampir tidak diadopsi di luar Flutter, dan ini menarik jika dibandingkan dengan kenyataan bahwa jumlah kode aplikasi jauh lebih banyak daripada kode sistem. Go adalah teknologi kunci yang memindahkan perangkat lunak sisi server dari lingkungan Java yang membengkak ke kontainer native, dan menjadi fondasi bagi sebagian besar infrastruktur aplikasi web dalam 10 tahun terakhir. Di tengah pertumbuhan itu, timnya tetap kecil dan tokoh-tokoh intinya juga tetap bertahan, tetapi belum tentu itu akan terus begitu ke depannya

    • Go memiliki garbage collection dan runtime berat yang mencakup green thread, sehingga interoperabilitas dengan C menjadi merepotkan dan lambat
      Karena itu, secara desain Go tidak cocok sebagai bahasa pemrograman sistem. Karena pada awalnya Go menyebut dirinya demikian, mitos aneh itu bertahan lama, tetapi frasa tersebut tampaknya sudah dihapus beberapa tahun lalu
      Go lebih dekat sebagai pesaing keluarga Java daripada pesaing C atau Rust, dan itu terlihat dari area penggunaan nyatanya. Namun, karena sistem tipenya yang terbatas dan dukungan konkurensinya yang sangat baik, Go sering berada sedikit lebih rendah di dalam stack
    • Sulit untuk setuju dengan bagian bahwa komunitaslah yang memimpin. Kesan bahwa Google yang menentukan masih kuat
      Terutama soal versioning. Awalnya Go bahkan tidak mengakui masalah itu sendiri, lalu ketika konsensus komunitas makin besar, mereka melupakan diskusi sebelumnya dan memutuskan bahwa sekarang arahnya adalah modules
      Saya juga ingat mereka tidak mau menjadikan monotonic time sebagai API publik sampai Cloudflare mengalami gangguan karena daylight saving time
    • Saya dulu developer Java dan sekarang menyukai Go, tetapi saya tidak yakin rekan-rekan Java saya dulu akan menyukai Go. Bahkan ketika masih menjadi bahasa baru, Go adalah bahasa yang agak membosankan
      Di dunia Java, ada kesenangan dalam merombak codebase dengan memakai fitur-fitur baru, misalnya streams yang bagus. Di Go, kesenangannya datang dari menemukan abstraksi yang paling sederhana dan biasa saja
    • Saya bekerja di Dart. Saya tidak menganggap kritik bahwa Dart tidak diadopsi di luar Flutter sebagai sesuatu yang begitu fatal
      Semua bahasa membutuhkan library dan framework yang sesuai untuk domain tertentu. Flutter adalah framework untuk menulis aplikasi klien dengan Dart; tanpa Flutter, sekalipun Anda sangat menyukai bahasa Dart, Anda harus menghabiskan waktu luar biasa banyak hanya untuk mencari cara menggambar piksel di layar Android dan iOS
      Siapa pun yang menulis aplikasi membangunnya di atas stack library dan framework. Perbedaan antara Go dan Dart yang dipasangkan dengan Flutter kurang lebih hanya bahwa library domain seperti networking, serialisasi, dan kriptografi yang dibutuhkan server sudah masuk ke standard library di Go
      Dart memiliki elemen dasar seperti collection dan async sebagai library bawaan, tetapi untuk fungsi spesifik domain, Dart bergantung pada paket eksternal seperti Flutter. Ini banyak disebabkan oleh Dart yang sejak sangat awal sudah memiliki cara manajemen paket yang solid. Banyak library inti yang ditulis dan dikelola oleh tim Dart juga didistribusikan melalui package manager, bukan dijadikan bawaan, karena cara itu jauh lebih mudah untuk dikembangkan
      Framework UI cenderung berumur lebih pendek daripada bahasa, jadi menurut saya lebih baik Flutter tidak tertanam di standard library Dart. Flutter memang bagus, tetapi tidak akan mengejutkan jika 20 tahun lagi muncul sesuatu yang lebih baik; jika saat itu Flutter tidak menjadi bawaan, pengguna Dart akan lebih mudah berpindah
    • Saat PHK, mereka memangkas tim-tim FOSS inti, dan manajemen benar-benar tidak menyukai FOSS sejati. Sebab itu tidak terlihat bagus di spreadsheet Ruth
      FOSS palsu seperti Android ditoleransi secara strategis, tetapi selain itu, kalau tidak berujung pada klik iklan, suasananya adalah dianggap tidak berguna

  • Pada 2012, sebagai developer Python, saya mulai memakai Go karena harus melakukan manipulasi bit untuk Modbus. Kode itu tidak pernah saya deploy, tetapi saya terkejut karena pekerjaan menyentuh bit dan byte bisa berjalan begitu mudah begitu saja
    Sepuluh tahun kemudian, setelah beberapa kali hampir bekerja penuh waktu dengan Go, fakta bahwa sebagian besar hal langsung berjalan masih terasa mengagumkan
    Saya menyukai bahasa Go dan komunitas Go. Saya berterima kasih atas pekerjaan orang-orang yang membuat Go seperti Rob, Ian, Russ, dan lainnya, dan saya juga menghargai bahwa presentasi/tulisan ini dengan jujur membahas “masa-masa sulit” bersama komunitas
    Namun, sebagai orang yang mengalami masa itu, terutama kekacauan manajemen paket, sangat sulit percaya bahwa mereka benar-benar tidak tahu persis bagaimana mereka bertindak. Meski begitu, penilaian tulisan bahwa sekarang Go sudah sampai pada solusi yang baik juga benar
    Saya berharap 10 tahun ke depan Go, serta bahasa-bahasa serupa yang terinspirasi seperti Zig dan Deno, terus tumbuh bersama komunitas yang sehat

    • Hal yang paling saya sukai dari tim inti Go adalah mereka mampu berkata “tidak” terhadap berbagai macam permintaan, dan untuk generics mereka mampu mengatakan “mari tunggu implementasi yang benar”
      Saya lebih merupakan computational biologist daripada programmer, jadi penggunaan Go saya tidak konsisten, tetapi ketika kembali ke Go, kode lama tetap bisa dikompilasi dan bahasanya bekerja seperti yang saya harapkan
      Pada saat yang sama, saya juga menghargai bahwa Rob Pike mengakui kesalahan dalam proses belajar melibatkan komunitas, sambil tetap tidak menerima semua fitur mengilap begitu saja
    • Saya datang dari Python. Belakangan ini, dengan alat AI seperti Bard dan GPT-4, saya langsung mengonversi utilitas Python lama ke Go
      Beberapa langsung berjalan, beberapa perlu sedikit diperbaiki karena model AI mengetahui informasi API yang agak usang
      Namun tetap saja, fakta bahwa program cukup disalin ke server dengan scp lalu langsung berjalan terasa mengagumkan dibandingkan dengan Python, yang setiap kali mengharuskan kita menari “sistem venv yang sedang tren kali ini apa?”
    • Zig dan Deno tampaknya bukan objek perbandingan yang sangat pas dengan Golang. Justru Elixir dan ReasonML lebih mirip, dan kalau melihat ke internal Google, ada juga Dart

  • Tulisan yang bagus, tetapi juga terlihat cukup memuji diri sendiri. Saya kira akan ada pengakuan atas masalah-masalah bahasa yang lebih dalam, tetapi mungkin intinya bagi mereka bahasanya sudah sempurna dan sayalah yang bermasalah
    Karena itu sulit merekomendasikan Go. Ada masalah pada sistem tipe, penanganan error, concurrency yang tidak aman, sintaks yang terlalu sederhana, nil, nilai nol default, dan banyak paket arus utama yang terbengkalai
    Saat ini saya memakai Rust sebagai bahasa utama. Ekosistemnya aktif dan punya visi dalam banyak hal yang tidak dimiliki Go
    Kalau mau lebih tajam, sepertinya Go pernah punya masanya ketika bersaing dengan PHP sebagai bahasa backend

    • Saya rasa ini tidak banyak berkontribusi pada diskusi. Tanpa poin yang spesifik, ini terbaca seperti pembelaan Rust
      Paragraf pertama “tidak suka”, kedua sindiran, ketiga juga “tidak suka”, keempat “Rust lebih baik”, kelima sindiran lagi
    • Para ilmuwan garis Plan 9 terlalu menyukai merek mereka sendiri. Saya mulai memakai Go pada 2012, tetapi menyerah setelah mereka menghapus deps.dev
      Beberapa tahun kemudian, di perusahaan, saya mencoba memperkenalkan Go ke tim agar pekerjaan selesai, tetapi engineer lain meluangkan waktu mempelajari bahasanya dan merinci alasan mengapa itu tidak bagus, dan dia benar
      Intinya, meski sederhana, hal-hal kecil seperti penanganan error dan imports yang tidak digunakan membuat pemakaiannya menyakitkan. Secara pribadi saya suka penanganan error-nya, tetapi tidak suka sistem tipe-nya
    • Saya memakai Go sebelum belajar Rust, dan melihat perbedaan keduanya sangat mengubah cara pikir saya
      Karena dulu memakai OCaml, saya sudah tahu nilai tipe Option dan Result dibanding try/catch atau nil, tetapi saya memakai Go karena mudah. Namun kemudahan itu membawa biaya pemeliharaan jangka panjang. Lebih baik benar sejak awal dan tidak menghadapi kesulitan belakangan
      Bukan bermaksud meremehkan, tetapi saya sering mendengar Go dijelaskan sebagai bahasa yang mengambil 50 tahun perkembangan bahasa pemrograman terakhir lalu membuangnya
    • Saya setuju dengan kesan tentang bahasa pemrograman itu, tetapi untuk membela Go, Go lebih dekat sebagai bahasa yang dibuat oleh orang-orang yang tidak tertarik pada bahasa pemrograman itu sendiri, untuk orang-orang seperti itu
      Ini bukan dalam arti buruk. Rob Pike tidak peduli bahwa concurrency tidak aman atau bahwa nil adalah kesalahan bernilai 1 miliar dolar, dan sebagian besar pengguna Go juga begitu
      Apakah itu membuat Go menjadi bahasa yang baik? Tidak juga. Tapi bukan itu poinnya. Go adalah bahasa yang nyaman dan cukup baik, dipadukan dengan alat-alat yang meyakinkan yang membuatnya mudah digunakan. Semacam Crocs di dunia bahasa pemrograman
    • Saya sudah belajar Rust, tetapi komunitas pengguna Rust membuat mustahil untuk menyukai bahasanya. Bertahun-tahun berlalu dan itu tidak berubah; kalaupun ada, mungkin malah memburuk, bukan membaik
      Jika butuh integritas dan keamanan tinggi, saya akan memakai Ada atau Ada/SPARK dengan verifikasi formal. Di luar itu, Go memberi produktivitas jauh lebih tinggi daripada Rust
      Secara pribadi, saya melihat Rust seperti C++: contoh utama overengineering

  • Mungkin terdengar getir, tetapi 10 tahun lalu saya diejek di go-nuts dan juga mendapat jawaban meremehkan dari Rob Pike. Itu karena saya berani mengatakan bahwa cara go get dan import modul lewat jaringan bekerja, dipromosikan di seluruh dokumentasi pemula, dan digunakan seperti itu oleh seluruh komunitas, pada akhirnya berbahaya dan berpandangan pendek

    • Sistem paket Go, terutama sebelum modules, terasa seperti hack yang memaksakan perilaku eksternal di atas sistem yang lebih terbatas yang dirancang untuk dipakai hanya di dalam monorepo Google
      Pohon namespace global yang aneh itu masuk akal di dalamnya, dan penekanan pada artefak hasil code generation yang di-check-in juga bisa dipahami mengingat Google memasukkan artefak build ke dalam monorepo
    • Namun menarik bahwa hasil yang dibuat Go lebih baik daripada milik bahasa-bahasa lain
      Tentu ada masalah v2 atau masalah v0 abadi. Meski begitu, masih lebih baik daripada memakai npm atau berurusan dengan sesuatu di Python yang membuat kita ingin membuat tanda salib
    • Itu seperti memperlihatkan kepada dunia betapa tidak tahunya Rob Pike tentang teori bahasa pemrograman yang ditemukan setelah tahun 2000

  • Tulisan ini tampak seperti versi yang lebih personal dari artikel yang dimuat di ACM [1]. Keduanya mengakui bahwa mereka bukan membuat bahasa pemrograman baru yang hebat dari sudut pandang spesifikasi bahasa, melainkan membangun hal-hal di sekitar bahasa pemrograman dengan sangat baik, dan itu mungkin justru lebih penting
    Dalam tulisan yang diajukan, mereka mengatakan telah menciptakan pendekatan penggunaan interface dan pendekatan concurrency. Namun goroutine sama seperti thread Haskell, dan jika interface mendukung argumen generik seperti sekarang, ia sangat mirip dengan typeclass Haskell. Mengingat Haskell mendahului Go, menarik melihat programmer prosedural menemukan secara independen kekuatan ide-ide pemrograman fungsional
    Salah satu inovasi bahasa Go adalah implementasi interface tidak perlu mendeklarasikan interface yang diimplementasikannya. Dari sudut pandang keamanan itu mengerikan, tetapi dalam praktiknya hampir tidak bermasalah, dan menghilangkan masalah dependensi melingkar yang mengerikan yang dialami di Haskell dan Rust
    [1] https://cacm.acm.org/magazines/2022/5/260357-the-go-programm...

    • Saya rasa fakta bahwa interface adalah tipe struktural diremehkan dalam hal dampak menyeluruh fitur ini terhadap bahasa, dan lebih jauh lagi terhadap idiom serta ekosistemnya
      Jika tipe harus lebih dulu mendeklarasikan interface yang diimplementasikannya, Go akan menjadi bahasa yang sama sekali berbeda. Ini adalah salah satu pembeda utama Go. Setidaknya begitu sampai TypeScript hadir dengan interface bertipe struktural karena alasan lain
    • Tipe struktural sudah menjadi konsep lebih dari 25 tahun, dan juga sudah dipakai di bahasa seperti OCaml dan Scala
    • Saya tidak mengerti bagaimana itu disebut inovasi. Semua bahasa arus utama sebelum Go yang terpikir oleh saya bekerja dengan cara seperti itu
      Bisakah menyebut satu bahasa pemrograman yang layak kita pedulikan yang, ketika kita mendefinisikan interface, memaksa kita menyediakan implementasi untuk interface tersebut?

  • Tampaknya masalah terkait kriptografi di Go belum banyak dibahas. Setelah OpenSSH menghentikan SHA1, tim Go butuh satu tahun untuk menambahkan dukungan SHA2 ke x/crypto/ssh [1]. Gitea menjadi korban yang terkenal [2]
    Selain itu, fakta bahwa maintainer kriptografinya menyerang GnuPG [3] dan terlihat berusaha merusak kepercayaan terhadap Dan Bernstein [4] tidak menumbuhkan rasa percaya
    [1]: https://github.com/golang/go/issues/49269
    [2]: https://github.com/go-gitea/gitea/issues/17798
    [3]: https://twitter.com/FiloSottile/status/1127643698676797441
    [4]: https://twitter.com/FiloSottile/status/1555669786826244096

    • Masalahnya, paket-paket x/ cenderung cukup banyak ditelantarkan, dan mengikuti model pengembangan yang membuat kontributor baru sulit berhasil mengirimkan patch
      Sebaliknya, menurut saya paket crypto di pustaka standar adalah salah satu keberhasilan besar Go. OpenSSL sudah lama menjadi bencana, sementara Go, khususnya agl, membuat dan mendistribusikan implementasi alternatif yang sangat luas digunakan, dengan kualitas rata-rata yang juga tinggi. Terutama dari sudut pandang bahwa API publiknya memiliki jauh lebih sedikit “footgun”

  • Tulisan ini menyebut gofmt sebagai hal yang “dilakukan dengan benar”, dan ini memang patut ditekankan
    Bagi banyak perancang dan pendukung bahasa, ini mungkin terlihat sepele, tetapi sejak hari pertama proyek Go, ia sepenuhnya menghilangkan satu perdebatan bikeshed yang umum, sehingga nilainya sangat besar
    Saya melihat beberapa bahasa yang lebih baru sengaja menirunya, atau mengadopsinya karena berpikir kalau Go punya, kita juga harus membuatnya
    Saya pernah melihat aturan pemformatan yang cukup aneh, tetapi hampir tidak ada aturan yang benar-benar tidak bisa dibiasakan. Sebaliknya, pada codebase tanpa aturan pemformatan yang dipaksakan, akibatnya kode sering kali menjadi lebih sulit dipahami

    • Saya punya kecenderungan mengutak-atik pemformatan kode, dan saya suka karena go fmt membuat sebagian besar hal itu menjadi tidak berarti

  • Saya setuju dengan pernyataan bahwa “keberadaan pustaka yang solid dan dibuat dengan baik, yang memiliki sebagian besar hal yang dibutuhkan untuk menulis kode server abad ke-21, adalah aset besar”
    Go didanai oleh Google karena Google punya masalah. Mereka harus menulis banyak kode aplikasi sisi server, sementara Python terlalu lambat dan C++ terlalu rapuh. Go sangat cocok mengisi celah itu
    Bonus besarnya adalah orang-orang Google menulis pustaka yang dibutuhkan untuk pekerjaan semacam itu dan juga memakainya secara internal. Jadi ketika memakai pustaka tersebut, bahkan jalur error pun merupakan kode yang sudah banyak benar-benar dilalui
    Ada perbedaan pendapat teknis soal bahasanya. Terutama pada masa awal, penekanan untuk memakai antrean untuk segala hal, bahkan bagian membuat mutex dengan antrean. Namun green thread yang sesuai dengan use case-nya berhasil mereka tangkap dengan tepat. Masalah warna fungsi adalah masalah nyata, dan trik rumit di Rust untuk membuat async dan thread dipakai bersama terasa terlalu berlebihan. Go mengorbankan sedikit performa dan mendapatkan kesederhanaan besar
    Kebencian lama terhadap thread juga menarik. Saya mulai dari mainframe UNIVAC, yang sudah punya thread sejak 1967, waktu itu disebut “activities”. Pada 1972, bukan hanya sudah ada thread ruang pengguna, tetapi juga berjalan di multiprosesor simetris. Ada juga I/O asinkron dan fungsi penyelesaian ruang pengguna, instruksi bawaan untuk lock, serta sistem operasi yang secara internal sudah berbasis thread
    Thread dan multiprosesor dianggap hal normal, dan ketika pindah ke UNIX rasanya seperti kehilangan semua itu. UNIX/Linux butuh puluhan tahun untuk mengejar di area ini, dan beberapa generasi programmer tidak tahu cara memakai multiprosesor memori bersama
    Teori konkurensi awal Dijkstra ditemukan ulang dengan istilah lain dan sering kali desain yang lebih buruk. Orang-orang Go memahami bounded buffer Dijkstra dan mengapa bounded buffer dengan panjang 0 dan 1 berguna. Senang melihat itu kembali. Dengan operasi primitif yang tepat, konkurensi tidak sesulit itu. Jika mencoba menyelesaikannya dengan menaburkan lock di sana-sini seperti pola pikir pthreads klasik, hasilnya tidak akan bekerja dengan benar. Fakta bahwa pada masa awal UNIX/Linux penjadwal CPU benar-benar buruk sehingga pembukaan blokir thread bekerja dengan mengerikan juga tidak membantu

    • Para komentator HN acak sering mengatakan hal seperti “Go didanai karena Google punya masalah”, tetapi itu karena mereka tidak begitu tahu bagaimana Google berjalan atau sebesar apa perusahaan itu
      Go dibuat karena Rob Pike punya masalah. Ia tidak menyukai C++, Java, dan Python, dan karena ia Rob Pike, Google mengizinkannya mengerjakan bahasa baru selama beberapa tahun. Bukan Larry, Sergey, Sundar, atau Eric yang mendatangi Rob dan memintanya melakukan sesuatu
      Secara garis besar, Go didanai karena Rob Pike meminta dukungan, Google ingin mempertahankan Rob Pike, dan mereka menganggap ia hampir pasti akan membuat sesuatu yang menarik. Di Google Engineering, uang perusahaan pada dasarnya lebih mirip izin agar orang bisa mengerjakan sesuatu
      Karena Rob Pike adalah engineer yang hebat, Go keluar cukup bagus dalam beberapa hal, dan cocok dengan masalah awalnya bahwa untuk menulis aplikasi operasional Google ia harus memakai C++, Python, atau Java. Sebagian orang di internal Google juga setuju lalu mulai memakai Go, dan di antara mereka ada orang-orang berpengaruh yang “mendorong” orang lain memakai Go alih-alih Python
    • Go bukan sekadar proyek Google, melainkan pada dasarnya filosofi compiler Plan 9 untuk Unix/Linux, plus CSP
    • Ini tidak sesuai dengan ingatan saya saat bekerja di Google pada periode itu. Seperti meme “Go dibuat untuk pemrograman sistem”, jika dibedah ini lebih mirip keyakinan yang tidak begitu masuk akal
      Pada 2009 di Google, selain kasus akuisisi YouTube, Python hampir tidak dipakai untuk server di luar beberapa utilitas internal, jadi gagasan itu bisa langsung dibuang. Server Python terbesar yang dibuat langsung oleh Google adalah Mondrian, alat code review yang ditulis Guido van Rossum, dan kemudian digantikan oleh Critique yang ditulis dalam Java
      Saat itu Google memiliki kebijakan tiga bahasa yang cukup ketat untuk menghilangkan perang bahasa pemrograman. Yang boleh dipakai adalah C++, Java, dan Python; Python untuk skrip, C++ untuk infrastruktur, dan Java untuk server web
      Ada juga area yang tumpang tindih. Java diperkenalkan lebih belakangan daripada C++, dan sebagian server web tetap memakai C++ karena sulit ditulis ulang. Ada juga upaya migrasi bertahap ke Java, tetapi tidak terlalu mengakar. Beberapa server infrastruktur seperti Megastore ditulis dalam Java, dan pustaka inti umumnya memakai C++ dengan binding JNI dan Python
      Ada celah dalam kebijakan itu, sehingga beberapa tim membuat bahasa sendiri untuk infrastruktur internal, dan di codebase nyata juga dipakai bahasa konfigurasi kustom serta Sawzall buatan Rob Pike. Sintaksnya agak mirip Go
      Secara keseluruhan orang punya banyak kebebasan memilih; server web baru biasanya ditulis dalam Java, sedangkan hal seperti engine database baru biasanya ditulis dalam C++
      Menulis kode asinkron memang jelas sulit, dan benar bahwa Go menyelesaikan bagian itu dengan baik. Namun Go bukan proyek yang dimulai manajemen senior untuk memecahkan masalah Google. Bukan karena manajemen takut pada proyek seperti itu, melainkan karena ada sangat banyak proyek infrastruktur internal yang dibuat dan diberi staf oleh tim terkait untuk langsung menyelesaikan kesulitan developer. Upgrade jaringan berskala besar yang didorong pada masa itu adalah salah satu contohnya. Proyek-proyek seperti itu diumumkan sebelumnya
      Saya tidak ingat ada ketidakpuasan besar terhadap keadaan itu. Waktu build memang menjadi masalah sampai Bazel/Blaze bekerja bersama klaster build jarak jauh; setelah itu semuanya di-cache secara remote, sehingga codebase raksasa pun bisa dikompilasi dalam hitungan detik. Kecepatan compiler lokal menjadi hampir tidak penting, dan javac juga sangat cepat
      Pengumuman Go cukup mengejutkan. Jika benar-benar dikembangkan untuk memecahkan masalah Google, cara Google yang umum adalah merilisnya lebih dulu secara internal, mengembangkannya bersama pengguna internal selama beberapa tahun, baru kemudian membukanya ke publik. Namun Go justru dipublikasikan terlebih dahulu. Orang-orang di sekitar saya bertanya-tanya ini untuk apa, reaksi yang sulit diharapkan jika benar-benar didorong oleh kebutuhan internal

  • Bagian tentang keputusan memakai compiler C Ken Thompson alih-alih LLVM menarik. Orang-orang mengeluh, dan terutama pada versi-versi awal, hasilnya juga membuat kode yang dihasilkan kurang teroptimasi.
    Sebagai imbalannya, mereka bisa membuat split stack dengan cepat. Jika harus mengimplementasikannya di LLVM dan menyesuaikannya dengan ABI LLVM, mungkin mereka sama sekali tidak bisa melakukannya.
    Dalam tulisan itu, ini bukan disebut sebagai satu-satunya manfaat dari keputusan tersebut, melainkan sebagai salah satu contoh manfaatnya.

    • Isi wawancara terkait LLVM tidak akurat. Untuk Rust, split stack diimplementasikan dengan LLVM, dan sebenarnya itu cukup mudah.
      Dukungan untuk itu sudah ada di X86FrameLowering, dan juga sudah ada saat Go dirilis. Jika stack splitting diaktifkan, LLVM mengeluarkan pemeriksaan di prolog fungsi, lalu bila perlu memanggil __morestack untuk mengalokasikan stack tambahan. ABI Windows MSVC juga memerlukan kode yang sangat mirip untuk mendukung _chkstk, sehingga dukungan __morestack secara alami cocok dengannya.
      Justru membuat GDB memahami split stack lebih sulit daripada bagian mana pun dari implementasi compiler. Ini tidak bergantung pada backend.
      Mungkin yang dibingungkan penulis adalah stack yang dapat direlokasi. Saat itu implementasinya sulit karena membutuhkan garbage collection presisi, tetapi sekarang Azul sudah mengimplementasikannya di LLVM. Pada saat itu, cara termudah untuk mengimplementasikan garbage collection presisi adalah men-spill semua register melewati pemanggilan fungsi, dan ini memang memerlukan lebih banyak upaya implementasi tetapi bukan sampai berlebihan. Compiler Plan 9 tampaknya memang melakukan hal itu, jadi kemungkinan juga tidak akan menjadi regresi performa dibanding 6g/8g. Bagaimanapun, dukungan garbage collection dari Azul kini memiliki implementasi yang benar, yang dapat menyimpan root di register.
    • Bukankah pada akhirnya Go meninggalkan split stack? Itu terjadi di Go 1.3 yang dirilis pada 2014. Penyebabnya adalah masalah “hot spot” [1].
      Jadi memang benar bahwa kemampuan untuk bereksperimen itu bernilai, tetapi contoh khusus ini bukan kasus yang sempurna.
      [1]: https://go.dev/doc/go1.3#:~:text=Go%201.3%20has%20changed%20...

  • Saat merancang bahasa hobi bertipe statis, saya sedang mencoba sesuatu yang menangani interface dan generics bersama-sama, dan saya merasakan sendiri bahwa Rob benar. Membuat keduanya berpadu dengan baik benar-benar sulit.
    Meski begitu, saya merasa itu layak dilakukan. Secara pribadi, memakai bahasa bertipe statis yang penggunanya tidak bisa mendefinisikan tipe generic sendiri rasanya tidak terlalu memuaskan.
    Dulu saya pernah memrogram di lingkungan BASIC yang punya GOSUB untuk subroutine, tetapi tidak ada cara menulis subroutine yang menerima argumen. Saya tidak ingin mengulang pengalaman seperti itu di level sistem tipe.
    Jadi saya paham mengapa tim Go butuh waktu lama untuk menemukan desain yang baik. Merancang bahasa yang baik itu sulit, merancang bahasa yang baik dengan sistem tipe itu 10 kali lebih sulit, dan merancang sistem tipe dengan generics itu 10 kali lebih sulit lagi.

    • Saya tidak setuju. Bagian tersulit dalam implementasi generics adalah ketika mendukung implementation inheritance, sedangkan Go tidak mendukungnya.
      Jadi Go mengambil bagian termudah dari implementasi generics. Alasan mereka tidak melakukannya bukanlah teknis. Itu ideologis, murni berbasis ketidaktahuan, dan karena sebagian besar perancang Go tidak lagi mengikuti bidang teori bahasa pemrograman sejak akhir 90-an.
    • Keluarga ML dan bahasa fungsional tampaknya tidak punya masalah ini, dan banyak di antaranya memiliki sistem tipe yang jauh lebih canggih dan kuat daripada Go.
    • Scala dirilis lebih dulu daripada Golang, dan saat Golang muncul, Scala sudah mulai populer. Scala juga tidak punya sumber daya sebesar GOOG di belakangnya.