https://nalar.dev/id/tags/golang/ Recent content in Golang on Nalar Hugo id-id Sat, 19 Sep 2026 00:00:00 +0000 https://nalar.dev/id/otp-email-di-go-kode-sekali-pakai-kedaluwarsa-dan-perlindungan-replay/ Sat, 19 Sep 2026 00:00:00 +0000 https://nalar.dev/id/otp-email-di-go-kode-sekali-pakai-kedaluwarsa-dan-perlindungan-replay/ <h1 id="otp-email-di-go-kode-sekali-pakai-kedaluwarsa-dan-perlindungan-replay">OTP Email di Go: Kode Sekali Pakai, Kedaluwarsa, dan Perlindungan Replay</h1> <p>OTP email terlihat sederhana: buat enam digit, kirimkan, lalu bandingkan dengan input pengguna. Namun, batas keamanannya bukan berada pada API email. Bagian pentingnya adalah lifecycle challenge di sisi server.</p> <p>Implementasi yang benar harus membuat kode sulit ditebak, membatasi masa berlakunya, membatasi tebakan, menonaktifkan challenge lama ketika diperlukan, dan memastikan kode yang sudah berhasil dipakai tidak dapat dikonsumsi untuk kedua kalinya. Properti ini berbeda dari TOTP, meskipun keduanya sering disebut OTP.</p> https://nalar.dev/id/go-defer-menyimpan-argumen-pemanggilan-sebelum-return/ Wed, 16 Sep 2026 00:00:00 +0000 https://nalar.dev/id/go-defer-menyimpan-argumen-pemanggilan-sebelum-return/ <p>Statement <code>defer</code> pada Go mengevaluasi nilai fungsi dan parameter pemanggilannya ketika eksekusi mencapai statement tersebut, meskipun fungsi yang ditunda baru berjalan saat fungsi di sekitarnya melakukan return. Mutasi di antara dua momen itu tidak mengubah secara retroaktif nilai argumen yang sudah disimpan.</p> <p>Pemisahan antara evaluasi dan invocation ini merupakan bagian dari semantik bahasa, bukan detail optimisasi. Setiap <code>defer</code> yang dieksekusi mencatat sebuah pemanggilan dengan nilai yang ditetapkan pada saat itu. Proses return kemudian menjalankan pemanggilan yang tercatat dalam urutan registrasi terbalik.</p> https://nalar.dev/id/go-errgroup-setlimit-memblokir-submitter-saat-batas-concurrency-tercapai/ Wed, 16 Sep 2026 00:00:00 +0000 https://nalar.dev/id/go-errgroup-setlimit-memblokir-submitter-saat-batas-concurrency-tercapai/ <p><code>errgroup.Group.SetLimit</code> dapat memblokir goroutine yang memanggil <code>Group.Go</code>. Limit diterapkan sebelum worker goroutine baru dimulai, sehingga group yang penuh menerapkan backpressure pada saat task submission alih-alih membangun internal queue.</p> <p>Perilaku ini penting ketika submission merupakan bagian dari control path lain. Loop yang tampak meluncurkan pekerjaan secara asynchronous dapat berhenti di <code>g.Go(...)</code> sampai salah satu active function selesai.</p> <h2 id="limit-berada-pada-admission">Limit berada pada admission</h2> <p>Zero-value <code>errgroup.Group</code> tidak memiliki concurrency limit. Setelah <code>SetLimit(n)</code>, paling banyak <code>n</code> function yang dimulai oleh <code>Go</code> aktif secara bersamaan. Negative limit mengembalikan unlimited admission, sedangkan zero limit mencegah setiap pemanggilan <code>Go</code> berikutnya memulai function.</p> https://nalar.dev/id/go-singleflight-hanya-membagikan-hasil-yang-sedang-in-flight/ Wed, 16 Sep 2026 00:00:00 +0000 https://nalar.dev/id/go-singleflight-hanya-membagikan-hasil-yang-sedang-in-flight/ <p><code>singleflight.Group</code> menekan eksekusi function duplikat hanya selama operasi dengan key yang sama masih in-flight. Caller concurrent dapat menerima satu hasil bersama, tetapi caller yang datang setelah completion akan memulai eksekusi baru. Karena itu group adalah mekanisme request coalescing, bukan result cache.</p> <p>Boundary ini memengaruhi cache fill, metadata refresh, backend read, dan operasi berbasis key lain yang dapat menerima burst pekerjaan concurrent identik. Group dapat mengurangi tekanan simultan pada backing operation tanpa memperpanjang lifetime value yang dikembalikan.</p> https://nalar.dev/id/go-sync-cond-wait-memeriksa-ulang-shared-state/ Wed, 16 Sep 2026 00:00:00 +0000 https://nalar.dev/id/go-sync-cond-wait-memeriksa-ulang-shared-state/ <p><code>sync.Cond.Wait</code> melanjutkan eksekusi setelah notification, tetapi notification tidak menyatakan bahwa kondisi khusus milik caller masih true ketika goroutine memperoleh lock kembali. Shared predicate tetap menjadi source of truth, sehingga waiter memeriksanya lagi setiap kali <code>Wait</code> kembali.</p> <p>Boundary ini memisahkan notification dari state. <code>Signal</code> dan <code>Broadcast</code> mengumumkan bahwa state yang relevan mungkin telah berubah; keduanya tidak memindahkan ownership state tersebut atau memesannya untuk waiter tertentu.</p> <h2 id="wait-membuka-lock-lalu-memperolehnya-kembali">Wait membuka lock lalu memperolehnya kembali</h2> <p>Sebuah <code>Cond</code> terkait dengan <code>Locker</code>, umumnya <code>*sync.Mutex</code>. Caller memegang lock tersebut saat memeriksa shared state. Jika predicate false, <code>Wait</code> secara atomik membuka locker dan menangguhkan caller. Sebelum <code>Wait</code> kembali, ia mengunci locker lagi.</p> https://nalar.dev/id/reuse-go-waitgroup-memerlukan-boundary-wait-yang-sudah-selesai/ Wed, 16 Sep 2026 00:00:00 +0000 https://nalar.dev/id/reuse-go-waitgroup-memerlukan-boundary-wait-yang-sudah-selesai/ <p><code>sync.WaitGroup</code> dapat digunakan kembali setelah sebuah wait phase selesai, tetapi task set independen baru tidak boleh dimulai selama call <code>Wait</code> dari phase sebelumnya masih aktif. Boundary-nya adalah return dari setiap <code>Wait</code> sebelumnya, bukan sekadar saat internal task counter mencapai nol.</p> <p>Constraint ini penting ketika satu instance <code>WaitGroup</code> dipertahankan lintas batch, epoch, request wave, atau coordination cycle berulang. Reuse didukung, tetapi phase tidak boleh overlap pada transisi counter dari nol menjadi positif.</p> https://nalar.dev/id/urutan-iterasi-map-go-tidak-stabil/ Wed, 16 Sep 2026 00:00:00 +0000 https://nalar.dev/id/urutan-iterasi-map-go-tidak-stabil/ <p><code>range</code> pada map Go dapat mengunjungi entri yang sama dalam urutan berbeda pada iterasi berturut-turut. Spesifikasi bahasa menyatakan bahwa urutan iterasi map tidak ditentukan dan tidak menjamin bahwa iterasi berikutnya pada map yang tidak berubah akan mengulangi urutan sebelumnya.</p> <p>Kontrak ini lebih kuat daripada sekadar mengatakan bahwa map tidak terurut. Container yang tidak terurut masih bisa saja menampilkan urutan stabil yang bergantung pada insertion order atau layout storage. Program Go tidak boleh memberikan makna seperti itu pada traversal map.</p>