Usulan Penambahan Paket UUID ke Pustaka Standar Go

 (github.com/golang)
1 poin oleh GN⁺ 2026-03-08 | 1 komentar | Bagikan ke WhatsApp
  • Proposal untuk menyertakan fungsi pembuatan dan parsing UUID ke pustaka standar bahasa Go sedang dibahas di GitHub
  • Pengusul menyatakan bahwa saat ini sebagian besar proyek server·DB Go bergantung pada paket eksternal seperti github.com/google/uuid
  • Bahasa utama seperti C#, Java, dan Python sudah menyediakan dukungan UUID di tingkat pustaka standar
  • Dalam proses diskusi, isu utama yang dibahas meliputi spesifikasi terbaru seperti UUIDv7, kepatuhan terhadap RFC 9562, cakupan fungsi parsing, dan konsistensi API
  • Proposal ini kemudian digabung ke proposal dukungan UUIDv4·UUIDv7 di paket crypto/rand (#76319) dan saat ini sedang dilanjutkan

Ringkasan proposal

  • Diajukan rencana untuk menambahkan API pembuatan dan parsing UUID ke pustaka standar Go
    • Versi yang ditargetkan adalah UUID v3, v4, v5
    • Alasan utamanya adalah ketergantungan pada paket eksternal dan contoh dukungan standar di bahasa lain
  • UUID adalah standar internasional yang didefinisikan dalam RFC 4122 (kemudian RFC 9562)
  • Pengusul menyoroti bahwa Go merupakan kasus pengecualian di antara bahasa utama karena belum memiliki dukungan UUID standar

Reaksi awal dan diskusi

  • Beberapa peserta menyebut bahwa proposal serupa pernah ada di masa lalu namun pernah ditolak (#23789, #28324)
    • Alasannya, penggunaan paket eksternal sudah cukup mudah, dan siklus rilisnya lebih fleksibel dibanding pustaka standar
  • Pengusul berargumen bahwa “jika sebagian besar proyek harus mengimpor paket eksternal setiap kali, lebih baik itu dimasukkan ke standar”
  • Fakta bahwa banyak bahasa memasukkan UUID ke pustaka standar terkait crypto juga diajukan sebagai dasar dukungan

Versi UUID terbaru dan penerapan RFC

  • Beberapa pendapat menunjukkan bahwa UUID v1~v5 sudah usang, dan v7 adalah versi terbaru yang paling menjanjikan
    • v7 memiliki beragam opsi implementasi, sehingga hasil penerapannya dinilai masih perlu diamati
  • Draf RFC merekomendasikan agar UUID tidak diparsing tanpa perlu dan diperlakukan sebagai pengenal yang opak
  • Setelah RFC 9562 resmi diterbitkan, diskusi terkait bergeser ke dukungan UUIDv7

Revisi dan penggabungan proposal

  • Pada 2025, setelah RFC 9562 diresmikan, muncul penyebutan bahwa PostgreSQL 18 mendukung UUIDv7
  • Setelah itu, pihak Go memulai proposal terpisah untuk hanya menambahkan fungsi pembuatan UUIDv4·UUIDv7 ke paket crypto/rand (#76319)
    • Fungsi parsing dikecualikan sesuai rekomendasi RFC
  • Proposal asli (#62026) ditutup sebagai duplikat (duplicate)

Diskusi desain API

  • Ada pembahasan apakah perilaku default uuid.New() sebaiknya menggunakan v4, atau dibiarkan bisa berubah di masa depan
    • Sebagian berpendapat bahwa “jika versinya berubah, masalah kompatibilitas bisa muncul”, sehingga disarankan selalu tetap v4
  • Dibahas juga apakah perlu menyediakan metode seperti Compare, MustParse, dan Parse
    • Ada pendapat bahwa Compare diperlukan untuk mendukung UUID yang dapat diurutkan sesuai definisi RFC
    • MustParse dinilai perlu dimasukkan agar konsisten dengan fungsi Must* lain di pustaka standar
  • Disimpulkan bahwa metode IsZero() tidak diperlukan untuk tipe UUID
  • Berbagai usulan desain turut diajukan, seperti pengenalan struct Generator, pemisahan tipe per versi (UUIDv4, UUIDv7, dan lain-lain), dan sebagainya
  • Sebagian pihak menilai fungsi New() terlalu ambigu, lalu mengusulkan agar hanya fungsi versi eksplisit (NewV4, NewV7) yang disediakan

Isu teknis utama

  • Ada diskusi apakah definisi pengurutan UUID (sorting) hanya benar-benar jelas untuk v6·v7
  • Ditinjau juga metode implementasi untuk menjamin pengurutan berbasis waktu saat membuat UUIDv7 serta mencegah tabrakan dalam konkurensi (metode counter)
  • Perbedaan makna antar versi**(misalnya v1 menyertakan alamat MAC, v7 berbasis waktu)** memunculkan kritik terhadap keterbatasan desain tipe tunggal
  • Sebagian mengusulkan pemisahan tipe per versi dan metode konversi eksplisit seperti AsV4(), AsV7(), dan lain-lain

Kesimpulan dan status saat ini

  • Komunitas Go pada umumnya setuju bahwa dukungan UUID standar memang diperlukan
  • Namun, untuk menjaga kesederhanaan pustaka standar dan mematuhi rekomendasi RFC
    • fungsi parsing dikecualikan
    • arah yang diambil adalah menambahkan hanya fungsi pembuatan UUIDv4·UUIDv7 ke crypto/rand
  • Proposal asli (#62026) telah digabungkan ke proposal #76319 dan sedang dilanjutkan, sehingga
    dukungan UUID standar di bahasa Go dinilai sudah mendekati tahap formalisasi

Bacaan terkait

1 komentar

 
GN⁺ 2026-03-08
Komentar Hacker News

  • Menarik melihat pendapat bahwa UUID versi 1~5 sudah usang
    Namun v4 masih punya tingkat keacakan tertinggi dan direkomendasikan sebagai kunci utama untuk menghindari masalah hotspot dan isu privasi di DB terdistribusi
    Tautan referensi: dokumentasi UUID CockroachDB, panduan UUID Google Cloud Spanner

    • Saya juga merasa pernyataan itu aneh. v7 bagus saat monotonicity dibutuhkan, tetapi timestamp bisa membocorkan informasi sistem. Jadi v4 tetap valid
    • Saya rasa ungkapan “outdated” tidak tepat. Masalahnya adalah ketidakcocokan kebutuhan, bukan usia
      Setiap versi UUID, termasuk v4, punya kekurangan dalam situasi tertentu. Bahkan banyak organisasi mendefinisikan sendiri nilai 128-bit murni alih-alih memakai UUID standar
      Pada akhirnya, makin banyak kebutuhan kompleks yang melampaui keterbatasan desain UUID
    • v4 adalah pilihan default, dan versi lain dipakai hanya jika benar-benar perlu mempertahankan urutan
    • Jika benar-benar butuh keacakan 128-bit, cukup pakai bilangan acak 128-bit. Tidak perlu dipaksakan ke format UUID
    • Tapi v4 bisa merusak penyisipan B-Tree. Saya belajar bahwa v7 jauh lebih cepat karena efisiensi page caching di kernel

  • Senang melihat berita kecil terkait Go seperti ini muncul di HN hari ini
    Akhir-akhir ini isinya cuma masa depan pemrograman atau AI, jadi topik teknis seperti ini terasa segar

    • Senang rasanya melihat lagi diskusi teknis yang mendalam setelah sekian lama
    • Rasanya menenangkan bisa lepas sejenak dari FUD soal AI. Dulu membuka HN tidak bikin cemas, tapi belakangan semua orang seolah cuma bicara soal “semuanya akan hancur”
    • Sekilas ini tampak seperti isu teknis kecil, tapi sebenarnya ini keputusan besar yang menentukan arah arsitektur dan kepemimpinan bahasa Go
      Kaum perfeksionis, pengembang praktis, dan komunitas crypto punya posisi yang berbeda-beda
      Dokumen terkait: RFC 9562
      Saya berharap Go mengambil keputusan yang benar. Terutama TinyGo sangat keren untuk mikrokontroler
    • Menarik melihat lanskap orang-orang yang tidak suka Go. Sekarang sudah masuk era AI yang membaca kode, jadi keseruan mengkritik bahasa sepertinya ikut hilang

  • Saya tidak terlalu peduli apakah Go mendukung pembuatan UUID, tetapi hadirnya tipe UUID standar itu sangat penting
    Ini akan memungkinkan marshaling yang konsisten di JSON, Text, database/sql, dan lain-lain
    Dalam analisis dependensi Go terbaru, google/uuid adalah paket kedua yang paling banyak dipakai
    Analisis terkait: The most popular Go dependency

    • Saya juga berharap tipe dec128 masuk ke standar. Idealnya disediakan dalam bentuk struct yang mudah dikonversi ke uint128

  • Daya tarik Go ada pada kepraktisan, bukan fitur yang mencolok
    Bahasanya tidak menjadi serumit sampai runtuh sendiri, dan hanya menambahkan fitur yang memang diperlukan

    • Saya juga baru-baru ini upgrade dengan melewati beberapa versi, dan tidak ada masalah sama sekali
      Berkat jaminan kompatibilitas, bahasa ini aman dipakai dengan tenang. Perubahannya lambat, tetapi terus membaik

  • Menurut saya yang lebih penting daripada paket uuid milik Google yang tidak aktif adalah bahwa gofrs/uuid mengikuti standar baru dan dipelihara secara aktif
    repositori gofrs/uuid

    • Menyenangkan membuat library tanpa dependensi eksternal. Perubahan kali ini membuat pekerjaan seperti itu lebih mudah
    • Namun google/uuid tidak punya rilis setelah 2024, dan bahkan pada Juni 2025 masih ada isu terkait yang dibuka
      isu #194
    • Proposal ini sudah dibahas sejak 3 tahun lalu

  • Saya benar-benar tidak suka UUID. Ini adalah identifier yang tidak ramah manusia
    Untuk debugging atau hasil query, bentuknya terlalu panjang dan merepotkan.
    Tentu berguna jika butuh ID unik di antara sistem yang benar-benar terpisah, tetapi dalam kebanyakan kasus justru dipakai berlebihan
    Untuk kasus umum, penerbit nomor terpusat jauh lebih baik.
    Misalnya prosedur seperti GetNextId di DB terasa lebih manusiawi dan efisien

    • Dulu di perusahaan saya, proyek dikelola dengan kode 6 digit, lalu seseorang menggantinya dengan UUID
      Akhirnya kodenya jadi tidak bisa dibaca manusia, dan bahkan implementasinya buatan sendiri jadi anehnya berurutan. Itu keputusan yang benar-benar buruk
    • Sebenarnya dalam kebanyakan kasus counter integer sudah cukup
      Di Postgres, memakai tabel counter bisa menghasilkan puluhan ribu ID per detik
      Dengan cara ini, penghematan memori, efisiensi kompresi, dan performa hash map juga jadi lebih baik
      UUID memang praktis, tapi merusak performa
    • Akan lebih baik jika ada unsur yang mudah dibaca manusia
      Contoh: menambahkan checksum berbasis kata dalam bentuk seperti BASKETBALL-...-FISH agar lebih mudah diingat
    • Anda tadi menyebut “randomisasi deterministik”, dan saya juga merasa pendekatan seperti LFSR (linear feedback shift register) cukup oke

  • Saya penasaran apakah UUID benar-benar akan ditambahkan ke Go

    • Saat ini statusnya ‘Likely accept’. Bisa dicek di project board Go
      Jika tidak ada penolakan khusus, kemungkinan besar akan dimasukkan
    • Ya, rencananya akan ditambahkan

  • Kotlin juga baru-baru ini menambahkan dukungan versi UUID berbasis RFC 9562 ke standard library di versi 2.3
    Mendukung JVM, JS, WASM, dan Native.
    Karena RFC IETF-nya sudah stabil, masuk akal jika Go ikut mengadopsinya

  • Agak disayangkan Go punya dukungan fungsi dasar seperti ini yang masih kurang

    • Saya penasaran bahasa mana yang lebih baik dalam menstandarkan hal seperti ini. Mungkin Java? Python dan Rust sepertinya mirip juga
    • Makna “batteries included” sudah banyak berubah dalam 20 tahun terakhir. Mungkin ini memang bukan fitur yang dibutuhkan di internal Google
    • UUID pada akhirnya cuma array 16-byte. Membuat v4 hanya butuh beberapa baris. Bukan hal besar
    • Saya penasaran fitur apa yang menurut Anda kurang
      Secara pribadi, menurut saya sistem logging Go terlalu sederhana sehingga saya harus membuat implementasi sendiri
      Modul slog lambat dan kurang nyaman. Rasanya seperti hanya mempertimbangkan lingkungan enterprise
    • Meski begitu, kualitas standard library Go tetap berada di level tertinggi. Menurut saya ini stdlib yang paling sering terpakai dalam pengembangan sehari-hari

  • Saya sempat berpikir apakah ada cara mendapatkan efisiensi clustering DB dari v7 sekaligus keacakan dari v4
    Mungkin bisa dengan memakai v7 secara internal, lalu saat dikirim ke luar diacak dengan XOR atau AES

    • Memang ada upaya seperti itu: proyek uuidv47
    • Jika tujuannya privasi, menurut saya lebih baik mengenkripsi kunci integer saja
      Misalnya memakai Feistel encryption untuk membuat ID publik yang opak tanpa masalah performa UUID