Rilis Go 1.24

• Go 1.24 adalah pembaruan resmi setelah Go 1.23, mencakup secara luas perubahan yang dapat langsung dirasakan developer, mulai dari fitur bahasa hingga runtime, standard library, dan WebAssembly
• Pada level bahasa, Go 1.24 sepenuhnya mendukung alias tipe generik, sehingga alias tipe juga dapat diberi parameter seperti tipe yang didefinisikan
• Runtime menunjukkan rata-rata penurunan overhead CPU 2–3% pada benchmark representatif, berkat map berbasis Swiss Tables, peningkatan alokasi objek kecil, dan perubahan mutex internal
• Perintah go menambahkan alur untuk melacak dan menjalankan dependensi tool modul, sementara go vet lebih baik dalam menangkap kesalahan deklarasi terkait test
• Dukungan standard library dan platform juga diperluas, sehingga perlu memeriksa FIPS 140-3, testing.B.Loop, os.Root, runtime.AddCleanup, go:wasmexport, serta build WASI reactor/library

---

Cakupan perubahan di Go 1.24

• Go 1.24 adalah rilis yang memuat berbagai peningkatan dibandingkan Go 1.23, dan daftar perubahan lengkap dapat dilihat di Go 1.24 release notes
• Versi baru ini dapat diunduh dari halaman unduhan Go

Perubahan bahasa: alias tipe generik

• Go 1.24 sepenuhnya mendukung generic type aliases
• Alias tipe juga dapat diberi parameter seperti tipe yang didefinisikan, sehingga memperluas cakupan ekspresi dalam kode generik
• Detail sintaks disertakan dalam language spec

Peningkatan performa runtime

• Berkat peningkatan runtime, rata-rata overhead CPU turun 2–3% pada kumpulan benchmark representatif
• Ada tiga pilar utama perubahan performa
  • Implementasi map bawaan baru berbasis Swiss Tables
  • Alokasi memori yang lebih efisien untuk objek kecil
  • Implementasi mutex internal runtime yang baru

Peningkatan tool Go

• Perintah go menyediakan mekanisme untuk melacak dependensi tool modul
  • Menambahkan direktif tool ke modul saat ini dengan go get -tool
  • Menjalankan tool yang dideklarasikan dalam direktif tool dengan go tool [tool name]
  • Detailnya ada di bagian go command pada release notes
• Subperintah go vet menambahkan analyzer test baru
  • Melaporkan kesalahan umum pada deklarasi test, fuzzer, benchmark, dan example di paket test
  • Detailnya ada di bagian vet pada release notes

Penambahan standard library dan API runtime

• Standard library mencakup serangkaian mekanisme baru yang membantu kepatuhan FIPS 140-3
  • Tidak diperlukan perubahan kode sumber aplikasi untuk menggunakan mekanisme baru pada algoritme yang disetujui
  • Detailnya ada di bagian FIPS 140-3 compliance pada release notes
• Selain FIPS 140, beberapa paket yang sebelumnya ada di modul x/crypto kini tersedia di standard library
• Kode benchmark dapat menggunakan metode testing.B.Loop
  • Melakukan iterasi benchmark dalam bentuk for b.Loop() { ... }
  • Dapat menggantikan struktur loop umum yang memakai b.N, seperti for range b.N
  • Pendekatan ini lebih cepat dan lebih kecil kemungkinan menimbulkan kesalahan
• Tipe baru os.Root memungkinkan operasi filesystem yang diisolasi di bawah direktori tertentu
• Runtime menambahkan mekanisme cleanup baru, runtime.AddCleanup
  • Lebih fleksibel, efisien, dan kecil kemungkinan menimbulkan kesalahan dibandingkan runtime.SetFinalizer

Peningkatan dukungan WebAssembly

• Go 1.24 menambahkan direktif baru go:wasmexport yang memungkinkan program Go mengekspor fungsi ke host WebAssembly
• Program Go dapat dibangun sebagai WASI reactor/library
• Detailnya ada di bagian WebAssembly pada release notes

Panduan lanjutan dan masukan

• Informasi lengkap tersedia di Go 1.24 release notes
• Beberapa topik akan dibahas lebih mendalam dalam artikel blog lanjutan
• Jika menemukan masalah, Anda dapat mendaftarkan issue

[GN⁺]

Komentar di Hacker News

• Implementasi map yang lebih cepat sangat menyenangkan, dan bagus juga text/template kini mendukung range-over-func
  Di Go 1.23, range untuk tipe fungsi sudah masuk, tetapi sejauh ini belum berfungsi di template Go

• Saya suka karena rilisnya biasa-biasa saja sampai terasa membosankan

• Saya penasaran apa kegunaan os.Root
  Sejauh pemahaman saya, ini tampaknya terkait keamanan seperti https://github.com/golang/go/issues/67002, tetapi karena secara internal tidak memakai Chroot, pada akhirnya mungkin saja seseorang menemukan cara untuk keluar dari Root

  • chroot hanya masuk akal ketika aplikasi dapat memastikan bahwa ke depannya ia hanya akan berjalan di dalam satu direktori
    Selain itu, prosesnya memerlukan hak superuser, jadi tidak bisa dipakai untuk aplikasi yang berjalan dengan hak pengguna biasa
    os.Root() lebih mirip memasang sabuk pengaman pada operasi file system. Misalnya, membatasi operasi terkait cache aplikasi ke direktori cache, atau memastikan file server hanya menyajikan file di dalam direktori berbagi yang sesuai. Tidak sekuat jaminan tembok besi ala chroot, tetapi dapat mencegah serangan directory traversal sederhana
  • Saya tidak paham mengapa harus memakai chroot
    Jika bersama fitur sandbox seperti Capsicum, kita bisa membuka direktori sebelum masuk ke capability mode, lalu nantinya memakai os.Root untuk membuka file di tree file system di bawah direktori yang sudah dibuka itu

• Saya penasaran apakah bisa menentukan tag yang akan dipakai saat menginstal tool yang ditentukan dengan direktif tools
  Saya sudah mencoba seperti di bawah ini, tetapi sepertinya terinstal tanpa tag
  go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

• Disebutkan bahwa jika memakai GODEBUG=fips140=only, algoritma kriptografi yang tidak mematuhi FIPS 140-3 akan mengembalikan error atau panic, tetapi saya kurang suka pendekatan standard library yang sengaja melakukan panic
  Saya belum melihat kodenya, tetapi penasaran apakah ini hanya terjadi pada fungsi-fungsi yang saat ini tidak mengembalikan error demi kompatibilitas mundur

  • Ini adalah fitur yang dibutuhkan di lingkungan pemerintahan
    Jika tidak memeriksa saat runtime apakah FIPS sudah disetel, ada risiko melanggar compliance, yang akhirnya berujung pada audit dan rapat tanpa akhir. Menurut saya, outage 30 menit karena panic jauh lebih baik daripada bersusah payah berhari-hari membuat kontrol dan prosedur verifikasi baru
  • Kalau begitu, cukup jangan setel flag itu
    Perilaku seperti ini berguna untuk situasi yang hanya bisa dideteksi saat runtime. Dengan coverage pengujian dasar saja, hal ini akan langsung terlihat
  • Alternatif realistisnya hanya mengembalikan error, tetapi error bisa ditangkap lalu diabaikan
    Dalam situasi yang melibatkan enkripsi, saya ragu apakah itu hal yang diinginkan. Menurut saya level log peringatan sebaiknya dihindari. Jika penting dan bisa ditindaklanjuti, seharusnya berupa error atau log fatal; jika tidak, log informasi sudah cukup
  • Saya membaca bahwa bagian ini kemungkinan akan dibereskan di Go 1.25
    https://devblogs.microsoft.com/go/go-1-24-fips-update/
  • Seperti komentar-komentar sejajar lainnya, dalam beberapa kasus pemaksaan memang diperlukan
    Ini juga bisa dilihat sebagai cara menghindari bug tersembunyi. Mirip dengan "The server chose violence" [1] [2], dan patut dipikirkan juga seberapa besar Hukum Postel telah menghambat interoperabilitas. Poin ini sering terlupakan dalam banyak aspek sertifikasi FIPS
    [1] https://cliffle.com/blog/hubris-reply-fault/
    [2] https://news.ycombinator.com/item?id=40178652

• Akhirnya alias tipe generik masuk, fitur yang memang sudah lama dibutuhkan

• Flag tool baru adalah yang paling saya nantikan. Sekarang tools.go yang tidak enak dilihat itu bisa dihapus

• Bagus. Saya menunggu rilis kali ini karena GOAUTH
  Semoga bekerja dengan repositori git privat jadi tidak terlalu merepotkan, tetapi setelah melihat go help goauth, rasanya sulit untuk berharap terlalu banyak