- Go diline UUID oluşturma ve ayrıştırma işlevlerinin standart kütüphaneye dahil edilmesi önerisi GitHub'da tartışılıyor
- Öneri sahibi, bugün çoğu Go sunucu ve veritabanı projesinin github.com/google/uuid gibi harici paketlere bağımlı olmasını gerekçe gösteriyor
- C#, Java, Python gibi başlıca diller zaten standart kütüphane düzeyinde UUID desteği sunuyor
- Tartışma sürecinde UUIDv7 gibi yeni spesifikasyonlar, RFC 9562 uyumluluğu, ayrıştırma işlevlerinin kapsamı ve API tutarlılığı başlıca gündem maddeleri oldu
- Bu öneri daha sonra crypto/rand paketine UUIDv4·UUIDv7 desteği ekleme önerisi (#76319) ile birleştirilerek ilerlemeye başladı
Önerinin özeti
- Go standart kütüphanesine UUID oluşturma ve ayrıştırma API'si ekleme planı sunuldu
- Hedef sürümler: UUID v3, v4, v5
- Başlıca gerekçeler, harici paket bağımlılığı ve diğer dillerdeki standart destek örnekleri
- UUID, RFC 4122'de (daha sonra RFC 9562) tanımlanan uluslararası bir standarttır
- Öneri sahibi, Go'nun başlıca diller arasında UUID için standart destek sunmayan istisnai bir örnek olduğunu belirtiyor
İlk tepkiler ve tartışma
- Bazı katılımcılar, geçmişte de benzer öneriler yapıldığını ancak reddedildiğini hatırlattı (#23789, #28324)
- Gerekçeler arasında harici paket kullanımının yeterince kolay olması ve standart kütüphaneye kıyasla daha esnek bir sürüm döngüsü sunması vardı
- Öneri sahibi, “Projelerin çoğu her seferinde harici paket içe aktarmak zorundaysa, bunu doğrudan standarda dahil etmek daha iyidir” görüşünü savundu
- UUID'nin birçok dilde kriptoyla ilgili standart kütüphane içinde yer alması da destekleyici bir argüman olarak öne çıktı
Yeni UUID sürümleri ve RFC yansımaları
- Bazı görüşler, UUID v1~v5'in artık eski kaldığını ve v7'nin yeni ve gelecek vadeden sürüm olduğunu vurguladı
- v7 için çeşitli uygulama seçenekleri bulunduğu ve gerçek kullanım sonuçlarının izlenmesi gerektiği belirtildi
- RFC taslağı, UUID'nin gereksiz yere ayrıştırılmamasını ve opak bir tanımlayıcı olarak ele alınmasını öneriyordu
- Daha sonra RFC 9562 resmen yayımlanınca, ilgili tartışma UUIDv7 desteği odağına kaydı
Önerinin güncellenmesi ve birleştirilmesi
- 2025'te RFC 9562 resmileşince, PostgreSQL 18'in UUIDv7 desteği sunduğu da gündeme geldi
- Ardından Go tarafında, crypto/rand paketine yalnızca UUIDv4·UUIDv7 oluşturma işlevleri eklemeyi amaçlayan ayrı bir öneri (#76319) başlatıldı
- Ayrıştırma işlevleri, RFC tavsiyeleri doğrultusunda kapsam dışında bırakıldı
- İlk öneri (#62026), yinelenen öneri (duplicate) olarak işaretlenip kapatıldı
API tasarımı tartışmaları
uuid.New() varsayılan davranışının v4 mü olacağı, yoksa ileride değiştirilebilir mi olacağı tartışıldı
- Bazıları, “Sürüm değişirse uyumluluk sorunu doğabilir” diyerek bunun her zaman v4'e sabitlenmesini önerdi
Compare, MustParse, Parse gibi metotların sunulup sunulmaması da konuşuldu
Compare için, RFC tanımı gereği sıralanabilir UUID desteği açısından gerekli olduğu görüşü öne çıktıMustParse ise standart kütüphanedeki diğer Must* işlevleriyle tutarlılık için savunuldu
IsZero() metodunun UUID tipi için gerekli olmadığı sonucuna varıldıGenerator yapısının eklenmesi, sürüm bazlı tip ayrımı (UUIDv4, UUIDv7 vb.) gibi çeşitli tasarım önerileri ortaya atıldı- Bazıları,
New() işlevinin muğlak olduğunu söyleyerek yalnızca açık sürüm işlevleri (NewV4, NewV7) sunulmasını önerdi
Başlıca teknik tartışma noktaları
- UUID sıralaması (sorting) tanımının yalnızca v6 ve v7 için mi açık olduğu tartışıldı
- UUIDv7 üretiminde zaman temelli sıralama garantisi ve eşzamanlılık çakışmalarını önleme (sayaç temelli yaklaşım) yöntemleri incelendi
- Sürümler arasındaki anlamsal farklar (ör. v1'in MAC adresi içermesi, v7'nin zaman tabanlı olması) nedeniyle tek tipli tasarımın sınırlarına dikkat çekildi
- Bazıları, sürüme göre ayrı tipler ve açık dönüşüm metotları (
AsV4(), AsV7() vb.) eklenmesini önerdi
Sonuç ve mevcut durum
- Go topluluğu, UUID için standart desteğin gerekli olduğu konusunda genel olarak hemfikir
- Ancak standart kütüphanenin sadeliğini korumak ve RFC tavsiyelerine uymak adına
- ayrıştırma işlevleri dışarıda bırakıldı
- ve yalnızca UUIDv4·UUIDv7 oluşturma işlevlerinin crypto/rand'e eklenmesi yönünde bir çerçeve oluştu
- İlk öneri (#62026), #76319 önerisine entegre edilerek ilerliyor ve
Go dilinde UUID için standart desteğin resmileşmesine oldukça yaklaşıldığı görülüyor
1 yorum
Hacker News görüşleri
UUID sürüm 1~5'in zaten eski sayıldığını söylemeleri ilginçti
Ancak v4 hâlâ en yüksek rastgeleliği sunuyor ve dağıtık veritabanlarında hotspot sorunları ile gizlilik meselelerinden kaçınmak için birincil anahtar olarak öneriliyor
İlgili bağlantılar: CockroachDB UUID dokümanı, Google Cloud Spanner UUID rehberi
Her UUID sürümünün (v4 dahil) belirli durumlarda kusurları var. Nitekim birçok kuruluş, standart UUID yerine kendi tanımladıkları salt 128 bit değerleri kullanıyor
Sonuçta UUID'nin tasarım sınırlarını aşan karmaşık gereksinimler giderek arttı
Bugün HN'de böyle ufak bir Go haberi görmek sevindiriciydi
Son zamanlarda her yer programlamanın geleceği ya da yapay zeka konuşmalarıyla dolu; bu tür teknik konular daha taze hissettiriyor
Mükemmeliyetçiler, uygulamacı geliştiriciler ve crypto topluluğu farklı pozisyonlar alıyor
İlgili belge: RFC 9562
Umarım Go doğru kararı verir. Özellikle TinyGo, mikrodenetleyiciler için gerçekten harika
Go'nun UUID üretimini desteklemesi umurumda değil ama standart bir UUID türünün gelmesi gerçekten önemli
JSON, Text, database/sql gibi yerlerde tutarlı marshaling mümkün olacak
Yakın tarihli bir Go bağımlılık analizinde google/uuid, en çok kullanılan ikinci paket çıkmıştı
İlgili analiz: The most popular Go dependency
Go'nun çekiciliği gösterişli özelliklerden çok pratikliğinde yatıyor
Dil, çökecek kadar karmaşıklaşmadan yalnızca gerekli özellikleri ekliyor
Uyumluluk garantisi sayesinde güvenle kullanılabiliyor. Değişim yavaş ama dil istikrarlı biçimde daha iyiye gidiyor
Google'ın uuid paketinin pasif kalmasından çok, gofrs/uuid'nin yeni standardı takip etmesi ve aktif biçimde bakım görmesi daha önemli bence
gofrs/uuid deposu
Issue #194
UUID'den gerçekten nefret ediyorum. İnsan dostu olmayan bir tanımlayıcı
Hata ayıklamada ya da sorgu sonuçlarında fazla uzun ve kullanışsız.
Elbette tamamen ayrık sistemler arasında benzersiz ID gerektiğinde işe yarıyor ama çoğu yerde aşırı kullanılıyor
Genel durumda merkezi bir numara üreticisi çok daha iyi.
Örneğin veritabanındaki GetNextId gibi bir prosedür daha insani ve daha verimli
Sonuçta insanın okuyamadığı kodlar ortaya çıktı; üstelik kendi implementasyonlarıydı ve garip biçimde sıralıydı. Tam bir felaketti
Postgres'te sayaç tablosu kullanarak saniyede on binlerce ID üretilebiliyor
Bu da bellek tasarrufu, sıkıştırma verimi ve hash map performansı sağlıyor
UUID kullanışlı ama performansı mahvediyor
Örneğin
BASKETBALL-...-FISHgibi, kelime tabanlı bir checksum eklenirse akılda tutmak kolay olurGo'ya UUID'nin gerçekten eklenip eklenmeyeceğini merak etmiştim
Özel bir itiraz çıkmazsa dahil edilme olasılığı yüksek
Kotlin de yakın zamanda 2.3 sürümünde RFC 9562 tabanlı UUID sürüm desteğini standart kütüphaneye ekledi
JVM, JS, WASM ve Native'ın tamamını destekliyor.
IETF RFC istikrara kavuştuğuna göre Go'nun da bunu takip etmesi mantıklı
Go'nun böyle temel işlev desteği eksikleri biraz üzücü
Benim açımdan Go'nun loglama sistemi fazla basit olduğu için kendim kurmak zorunda kaldım
slog modülü yavaş ve kullanışsız. Sanki sadece kurumsal ortam düşünülmüş gibi
v7'nin DB kümeleme verimliliğini ve v4'ün rastgeleliğini aynı anda elde etmenin bir yolu olur mu diye düşündüm
İçeride v7 kullanıp dışarı gönderirken XOR ya da AES ile karıştırmak mümkün olabilir
Örneğin Feistel şifrelemesi kullanarak UUID'nin performans sorunları olmadan opak genel ID'ler üretilebilir