Penghapusan Core Types dan Evolusi Sederhana Bahasa Go

• Bersamaan dengan diperkenalkannya fitur generics di Go 1.18, konsep baru bernama core type juga ditambahkan, tetapi diputuskan untuk dihapus pada 1.25
• Core type adalah konsep abstrak untuk memudahkan implementasi compiler, yang menggantikan underlying type yang sudah ada saat menangani operand bertipe generik
• Dalam spesifikasi bahasa, istilah "underlying type" juga diganti dan digunakan sebagai "core type"

Parameter tipe dan batasan tipe

• Parameter tipe berperan sebagai placeholder untuk tipe yang akan ditentukan di masa depan, dan diputuskan pada saat kompilasi
• Batasan tipe menentukan operasi apa saja yang dimungkinkan untuk tipe parameter tersebut
• Di Go, batasan tipe didefinisikan dengan menggabungkan persyaratan method dan tipe, yang membentuk type set
• Type set berarti kumpulan semua tipe yang memenuhi interface tertentu

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

• Pendekatan berbasis type set seperti ini sangat fleksibel dan kuat untuk mendefinisikan operasi pada tipe generik

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

Pengenalan core type dan keterbatasannya

• Core type didefinisikan sebagai aturan untuk menyederhanakan penggunaan tipe generik pada beberapa operasi
• Cara mendefinisikan core type:
  • Untuk tipe biasa, core type sama dengan underlying type dari tipe tersebut
  • Untuk parameter tipe, core type hanya ada jika semua tipe dalam type set memiliki underlying type yang sama
• Namun, pendekatan ini menimbulkan masalah berikut:
  • Spesifikasi bahasa menjadi lebih kompleks sehingga aturan yang sederhana pun sulit dipahami
  • Konsep core type ikut disebut secara tidak perlu bahkan pada kode non-generik
  • Beberapa operasi yang memiliki konsep core type menjadi terlalu membatasi, sehingga operasi yang sebenarnya aman pun tidak diizinkan
  • Karena tidak konsisten dengan aturan lain yang tidak memakai core type, konsistensi keseluruhan desain bahasa menurun

Penghapusan core type di Go 1.25

• Dalam rilis Go 1.25 (direncanakan pada Agustus 2025), diputuskan untuk menghapus konsep core type dari spesifikasi bahasa
• Pendekatannya diubah dengan menuliskan batasan yang diperlukan untuk tiap operasi dalam kalimat yang eksplisit
• Dampak utama perubahan ini:
  • Jumlah konsep berkurang sehingga mempelajari bahasa Go menjadi lebih mudah
  • Kode non-generik menjadi lebih jelas tanpa bergantung pada konsep generik
  • Aturan dapat dirancang lebih fleksibel untuk operasi tertentu
  • Menjadi landasan untuk perluasan fitur di masa depan (misalnya: akses field bersama, penguatan kemampuan slice, perbaikan type inference, dan lain-lain)

Penerapan utama dan dampak yang diharapkan

• Semua redaksi spesifikasi yang menyebut core type dihapus atau diganti dengan kalimat yang eksplisit
• Dalam pesan error compiler, istilah core type juga dihapus dan diganti dengan penjelasan yang lebih spesifik
• Tidak ada dampak terhadap perilaku program Go yang sudah ada
• Spesifikasi bahasa menjadi lebih sederhana, dan dari sudut pandang pengguna, bahasa Go menjadi lebih intuitif dan jelas

[GN⁺]

Komentar Hacker News

• Saya suka karena tim Go menangani perubahan spesifikasi dengan sangat hati-hati

  • Generics di Go adalah perubahan besar dan bisa sulit digunakan
  • Saya pikir pembatasan membantu mencegah penggunaan generics secara berlebihan
  • Saya pernah melihat sistem tipe dipakai berlebihan di proyek Java dan Typescript hingga membuat kode menjadi tidak jelas
  • Saya berharap tim Go tetap mengambil pendekatan konservatif terhadap bahasa ini

• Sepuluh tahun terakhir tim pengembang Go adalah proses mencari keseimbangan antara fitur dan kesederhanaan

  • Generics menunjukkan dinamika ini dengan sangat baik
  • Menerapkan sistem tipe seperti Rust di atas Go akan membawa kompleksitas yang terlalu besar
  • Sedikit kembali ke arah yang lebih mengutamakan kesederhanaan itu bagus
  • Tujuan Go adalah menjadi Java yang lebih baik untuk tim engineer tingkat menengah

• Go 1.25 tidak menambahkan fitur bahasa yang nyata

  • Di 1.30, sum types mungkin bisa ditambahkan

• Saya sudah mengikuti Go sejak sebelum build Windows tersedia

  • Semua yang saya pelajari pada 2011 masih tetap berlaku
  • Saya belum pernah mendapat kesempatan bekerja dengan Go, tetapi mempelajarinya lewat proyek kecil
  • Saya kecewa saat wawancara pengembang Go mengatakan generics sepertinya tidak akan diperkenalkan ke Go
  • Sekarang generics sudah diperkenalkan, saya berencana memulai side project dengan Go

• Tidak benar bahwa ketika argumen close adalah parameter tipe, semua tipe harus berupa channel dengan tipe elemen yang sama

  • Tipe elemen tidak memengaruhi close, dan kompilasi tetap berjalan baik bahkan saat memakai type set dengan tipe elemen berbeda
  • Dokumentasinya perlu diperbaiki
  • Saya berharap perluasan fleksibilitas seperti shared fields bisa dipercepat

• Saya sedang belajar Go secara perlahan dan punya latar belakang C++

  • Saya penasaran apakah ini mirip dengan template specialization
  • Saya berharap lebih banyak bahasa mendukung ini

• [mati]

• Sekarang AI generatif sudah bisa menulis kode, saya jadi penasaran apakah garbage collector masih diperlukan

[aer0700]

Sekarang AI generatif sudah bisa menulis kode, jadi saya penasaran apakah garbage collector masih tetap diperlukan
> Cukup bermakna...

[galadbran]

Ooh.. kalau AI sudah mencapai level yang bisa menulis kode seperti itu (kode yang mengelola memori dengan sempurna), sepertinya akan sulit bagi developer manusia untuk tetap punya peran seperti sekarang.

[kandk]

1+1=2 bisa diselesaikan dengan matematika, jadi untuk apa repot-repot memakai AI..

[jeiea]

Bukankah GC juga punya makna dari sisi mengurangi boilerplate yang harus dibaca manusia dan konteks kode yang perlu dilacak?
Kalau memprediksi bahwa bahkan membaca kode pun nantinya tidak perlu lagi, nah itu saya kurang tahu juga.
Melihat komentar aslinya juga diburamkan, sepertinya tidak terlalu banyak mendapat simpati.

[savvykang]

Bukankah reference counting bisa dihapus jika waktu alokasi dan pelepasan memori dapat dihitung pada saat kompilasi? Tampaknya penulis komentar asli di Hacker News tidak memahami masalah daur ulang memori.