Çekirdek Türlerin (Core Types) Kaldırılması ve Go dilinin sade evrimi

• Go 1.18’de generics özelliğinin kullanıma sunulmasıyla birlikte yeni bir kavram olan çekirdek tür (core type) eklendi, ancak 1.25’te kaldırılmasına karar verildi
• Çekirdek tür, derleyici uygulamasını kolaylaştırmak için kullanılan soyut bir kavramdı ve jenerik tür operandlarının işlenmesinde mevcut temel türün (underlying type) yerini alıyordu
• Dil belirtiminde de mevcut "temel tür" yerine "çekirdek tür" ifadesi kullanılmaya başlandı

Tür parametreleri ve tür kısıtları

• Tür parametreleri, gelecekte belirlenecek bir tür için yer tutucu görevi görür ve derleme sırasında belirlenir
• Tür kısıtları, ilgili parametre türü üzerinde hangi işlemlerin mümkün olduğunu belirler
• Go’da tür kısıtları, metot ve tür gereksinimlerinin birleştirilmesiyle tanımlanır; bu da bir tür kümesi (type set) oluşturur
• Tür kümesi, belirli bir arayüzü sağlayan tüm türlerin kümesini ifade eder

  type Constraint interface {
    ~[]byte | ~string
    Hash() uint64
  }
  

• Tür kümesi temelli bu yaklaşım, jenerik tür işlemlerini tanımlamada oldukça esnek ve güçlüdür

  func at[bytestring Constraint](s bytestring, i int) byte {
    return s[i]
  }
  

Çekirdek türün eklenmesi ve sınırları

• Çekirdek tür, bazı işlemlerde jenerik türlerin kullanımını basitleştirmek için tanımlanmış bir kuraldı
• Çekirdek türün tanımlanma biçimi:
  • Normal bir tür söz konusuysa, çekirdek tür o türün temel türüyle aynıdır
  • Bir tür parametresi söz konusuysa, tür kümesindeki tüm türlerin aynı temel türe sahip olması durumunda çekirdek tür vardır
• Ancak bu yaklaşım şu sorunlara yol açtı:
  • Dil belirtimi karmaşıklaştı ve basit kurallar bile anlaşılması zor hale geldi
  • Jenerik olmayan kodlarda bile gereksiz yere çekirdek tür kavramından söz edilmeye başlandı
  • Çekirdek tür kavramını kullanan bazı işlemler aşırı derecede kısıtlayıcı hale geldi ve pratikte güvenli olan işlemler bile izin verilmez oldu
  • Çekirdek tür kullanmayan kurallarla olan uyumsuzluk, dil tasarımının genelinde tutarlılığı azalttı

Go 1.25’te çekirdek türün kaldırılması

• Go 1.25 sürümünde (Ağustos 2025’te planlanıyor) çekirdek tür kavramının dil belirtiminden kaldırılmasına karar verildi
• Bunun yerine, her işlem için gerekli kısıtların açık cümlelerle tanımlandığı bir yaklaşıma geçiliyor
• Değişikliğin başlıca etkileri:
  • Kavram sayısı azalacağı için Go dilini öğrenmek kolaylaşacak
  • Jenerik olmayan kod, jenerik kavramlara dayanmadan daha açık hale gelecek
  • Belirli işlemler için daha esnek kural tasarımları mümkün olacak
  • Gelecekteki özellik genişlemeleri için zemin hazırlanacak (ör. ortak alan erişimi, slice yeteneklerinin güçlendirilmesi, tür çıkarımının iyileştirilmesi vb.)

Başlıca uygulamalar ve beklenen etkiler

• Belirtimde çekirdek türden söz eden tüm ifadeler kaldırılacak ya da açık cümlelerle değiştirilecek
• Derleyici hata mesajlarından da çekirdek tür terimi çıkarılacak ve daha somut açıklamalar sunulacak
• Mevcut Go programlarının davranışı etkilenmeyecek
• Dil belirtimi sadeleşecek ve kullanıcı açısından Go dili daha sezgisel ve daha açık hale gelecek

[GN⁺]

Hacker News görüşü

• Go ekibinin spesifikasyon değişikliklerini çok temkinli ele alması güzel

  • Go generics büyük bir değişiklik ve kullanımı zor olabilir
  • Kısıtlamaların generics'in aşırı kullanımını engellediğini düşünüyorum
  • Java ve Typescript projelerinde tip sisteminin aşırı kullanılması yüzünden kodun belirsiz hale geldiği durumlar gördüm
  • Go ekibinin dile muhafazakar yaklaşmasını umuyorum

• Go geliştirme ekibinin son 10 yılı, özellikler ile sadelik arasında denge bulma süreciydi

  • Generics bu dinamiğin özünü iyi gösteriyor
  • Go üzerine Rust benzeri bir tip sistemi kurmak fazla karmaşık olur
  • Sadelik odaklı yöne doğru küçük bir geri dönüş iyi
  • Go'nun hedefi, orta seviye mühendis ekipleri için daha iyi bir Java olmak

• Go 1.25 fiilen yeni bir dil özelliği eklemiyor

  • 1.30'da sum types eklenebilir

• Go'yu Windows derlemelerinden öncesinden beri takip ediyorum

  • 2011'de öğrendiğim her şey hâlâ geçerli
  • Go ile çalışma fırsatım olmadı ama küçük projelerle öğrendim
  • Go geliştiricileriyle yapılan bir röportajda generics'in Go'ya gelmeyecek gibi söylenmesi hayal kırıklığı yaratmıştı
  • Artık generics geldiğine göre Go ile yan projelere başlamayı planlıyorum

• close argümanı bir tip parametresi olduğunda tüm tiplerin aynı öğe tipine sahip kanal olması gerektiği doğru değil

  • Öğe tipi close'u etkilemiyor ve farklı öğe tiplerine sahip tip kümeleri kullanıldığında da derleme sorunsuz oluyor
  • Belgelerin iyileştirilmesi gerekiyor
  • Ortak alanlar gibi esneklik genişletmelerinin hızlanmasını umuyorum

• Go'yu yavaş yavaş öğreniyorum ve C++ geçmişim var

  • Bunun template specialization benzeri bir şey olup olmadığını merak ediyorum
  • Daha fazla dilin bunu desteklemesini isterim

• [dead]

• Artık üretken yapay zeka kod yazabildiğine göre, çöp toplayıcının hâlâ gerekli olup olmadığını merak ediyorum

[aer0700]

Artık üretken yapay zeka kod yazabildiğine göre, çöp toplayıcının hâlâ gerekli olup olmadığını merak ediyorum.
> Düşündürücü...

[galadbran]

Oha.. Yapay zeka o seviyede kodu (bellek yönetimini kusursuz yapan kodu) yazabilecek düzeye gelirse, insan geliştiricilerin bugünküyle aynı rolde kalması zor olur herhalde

[kandk]

1+1=2 matematikle çözülebiliyorken bunu neden illa yapay zekayla çözmeye gerek var ki..

[jeiea]

İnsanların okuduğu boilerplate’i ve takip edilmesi gereken kod bağlamını azaltma açısından bakarsak, GC’nin de bir anlamı yok mu?
Kod okumaya bile gerek kalmayacağını öngörüyorsanız, orası ayrı tabii.
Orijinal yorumun da soluk gösterildiğine bakılırsa, pek fazla destek görmemiş gibi duruyor.

[savvykang]

Bellek tahsisi ve serbest bırakma zamanını derleme anında hesaplamak mümkün olduğunda referans sayımını kaldırmak mümkün olmaz mı? Görünüşe göre Hacker News'teki asıl yorumun yazarı bellek geri dönüşümü sorununu anlamıyor.