1 puan yazan GN⁺ 2025-02-15 | 1 yorum | WhatsApp'ta paylaş
  • Go 1.24, Go 1.23’ten sonraki resmi güncelleme olarak dil özelliklerinden runtime’a, standart kütüphaneden WebAssembly’ye kadar geliştiricilerin doğrudan hissedeceği geniş kapsamlı değişiklikler içeriyor
  • Dil düzeyinde generic type alias desteği tamamen geldi; böylece type alias’lar da tanımlı tipler gibi parametreleştirilebiliyor
  • Runtime; Swiss Tables tabanlı map, küçük nesne ayırmalarındaki iyileştirmeler ve dahili mutex değişiklikleriyle temsilî benchmark’larda ortalama CPU overhead’inde %2–3 azalma gösteriyor
  • go komutu, modülün araç bağımlılıklarını izleme ve çalıştırma akışı ekledi; go vet ise testle ilgili bildirim hatalarını daha iyi yakalıyor
  • Standart kütüphane ve platform desteği de genişletildi; FIPS 140-3, testing.B.Loop, os.Root, runtime.AddCleanup, go:wasmexport, WASI reactor/library derlemelerinin incelenmesi gerekiyor

Go 1.24’ün değişiklik kapsamı

  • Go 1.24, Go 1.23’e göre çeşitli iyileştirmeler içeren bir sürüm; tam değişiklik listesi Go 1.24 release notes içinde görülebilir
  • Yeni sürüm Go indirme sayfasından alınabilir

Dil değişikliği: generic type alias’lar

  • Go 1.24, generic type aliases özelliğini tamamen destekliyor
  • Type alias’lar da tanımlı tipler gibi parametreleştirilebildiği için generic kodda ifade alanı genişliyor
  • Ayrıntılı sözdizimi language spec içinde yer alıyor

Runtime performans iyileştirmeleri

  • Runtime iyileştirmeleriyle temsilî benchmark gruplarında ortalama CPU overhead’i %2–3 azaldı
  • Performans değişiminin üç ana ekseni var
    • Swiss Tables tabanlı yeni yerleşik map implementasyonu
    • Küçük nesneler için daha verimli bellek ayırma
    • Yeni runtime dahili mutex implementasyonu

Go araç iyileştirmeleri

  • go komutu, modülün araç bağımlılıklarını izlemek için bir mekanizma sağlıyor
    • go get -tool ile mevcut modüle tool yönergesi ekleniyor
    • go tool [tool name] ile tool yönergesinde tanımlanan araç çalıştırılıyor
    • Ayrıntılar release notes içindeki go command bölümünde yer alıyor
  • go vet alt komutuna yeni test analizcisi eklendi
    • Test paketlerindeki test, fuzzer, benchmark ve örnek bildirimlerinde sık yapılan hataları raporluyor
    • Ayrıntılar release notes içindeki vet bölümünde yer alıyor

Standart kütüphane ve runtime API eklemeleri

  • Standart kütüphane, FIPS 140-3 uyumluluğunu destekleyen yeni mekanizmalar kümesini içeriyor
    • Onaylı algoritmalar için yeni mekanizmaları kullanmak üzere uygulama kaynak kodunda değişiklik gerekmiyor
    • Ayrıntılar release notes içindeki FIPS 140-3 compliance bölümünde yer alıyor
  • FIPS 140 dışında, daha önce x/crypto modülünde bulunan çeşitli paketler de standart kütüphane içinde sunuluyor
  • Benchmark kodu testing.B.Loop metodunu kullanabiliyor
    • Benchmark tekrarları for b.Loop() { ... } biçiminde yürütülüyor
    • for range b.N gibi b.N kullanan yaygın döngü yapılarının yerini alabiliyor
    • Bu yöntem daha hızlı ve hata olasılığı daha düşük
  • Yeni os.Root tipi, belirli bir dizinin altıyla sınırlandırılmış dosya sistemi işlemlerini mümkün kılıyor
  • Runtime’a yeni temizleme mekanizması runtime.AddCleanup eklendi

WebAssembly desteği iyileştirmeleri

  • Go 1.24, Go programlarının WebAssembly host’una fonksiyon dışa aktarabilmesini sağlayan yeni go:wasmexport yönergesini ekliyor
  • Go programları WASI reactor/library olarak derlenebiliyor
  • Ayrıntılar release notes içindeki WebAssembly bölümünde yer alıyor

Sonraki bilgilendirmeler ve geri bildirim

  • Tüm ayrıntılar Go 1.24 release notes içinde yer alıyor
  • Bazı konular sonraki blog yazılarında daha derinlemesine ele alınacak
  • Sorun bulunursa issue açılabilir

1 yorum

 
GN⁺ 2025-02-15
Hacker News yorumları
  • Daha hızlı map implementasyonu özellikle sevindirici; text/template’in artık range-over-func desteklemesi de güzel.
    Go 1.23’te fonksiyon tipleri üzerinde range gelmişti, ancak Go template’lerinde şimdiye kadar çalışmıyordu.

  • Sıkıcı denecek kadar sorunsuz olduğu için hoşuma gidiyor.

  • os.Rootun nerelerde kullanılacağını merak ediyorum.
    Anladığım kadarıyla https://github.com/golang/go/issues/67002 gibi güvenlikle ilgili; ama içeride Chroot kullanmadığına göre, sonunda birileri Root’un dışına çıkmanın bir yolunu bulabilir gibi geliyor.

    • chroot yalnızca uygulamanın bundan sonra da tek bir dizin içinde çalışacağını kesinleştirebildiğiniz durumlarda anlamlıdır.
      Üstelik süreç için süper kullanıcı yetkisi gerekir; bu yüzden normal kullanıcı yetkileriyle çalışan uygulamalarda kullanılamaz.
      os.Root() daha çok dosya sistemi işlemlerine emniyet kemeri takmaya benzer. Örneğin uygulama önbelleğiyle ilgili işlemleri önbellek diziniyle sınırlamak ya da bir dosya sunucusunun yalnızca uygun paylaşım dizini içindeki dosyaları sunmasını sağlamak gibi. chroot gibi aşılmaz bir garanti değildir, ama basit dizin gezinme saldırılarını engeller.
    • Neden chroot kullanmak gerektiğini anlamıyorum.
      Capsicum gibi sandbox özellikleriyle birlikte kullanıldığında, capability mode’a girmeden önce dizini açık tutabilir, daha sonra os.Root ile o açık dizinin altındaki dosya sistemi ağacındaki dosyaları açabilirsiniz.
  • tools yönergesiyle belirtilen araçları kurarken kullanılacak taglerin belirtilebilip belirtilemeyeceğini merak ediyorum.
    Aşağıdaki gibi denedim ama tag olmadan kuruluyor gibi görünüyor.
    go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

  • GODEBUG=fips140=only kullanıldığında FIPS 140-3’e uymayan kripto algoritmalarının hata döndüreceği veya panic edeceği belirtilmiş; standart kütüphanenin bilinçli olarak panic etmesi pek hoşuma gitmiyor.
    Koda henüz bakmadım, ama geriye dönük uyumluluk nedeniyle bunun yalnızca şu anda hata döndürmeyen fonksiyonlarda mı yapıldığını merak ediyorum.

    • Bu, kamu ortamlarında gerekli bir özellik.
      FIPS’in ayarlı olup olmadığını runtime’da kontrol etmezseniz uyumluluğu bozma riski doğar ve bu da sonunda denetimlere ve bitmek bilmeyen toplantılara yol açar. Yeni kontroller ve doğrulama süreçleri kurmak için günlerce uğraşmaktansa, panic yüzünden 30 dakikalık bir kesinti yaşamak bence çok daha iyi.
    • O zaman o flag’i ayarlamazsınız.
      Bu tür davranış, yalnızca runtime’da tespit edilebilen durumlarda yararlıdır. En temel test kapsamı bile bunu hemen ortaya çıkarır.
    • Gerçekçi alternatif yalnızca hata döndürmek; ama hatalar yakalanıp yok sayılabilir.
      Kriptografi söz konusu olduğunda bunun arzu edilir olup olmadığı tartışılır. Uyarı log seviyesi bence kaçınılması gereken bir şey. Önemli ve aksiyon alınabilir ise hata ya da fatal log olmalı; değilse info log yeterlidir.
    • Bu kısmın Go 1.25’te toparlanacağını okudum.
      https://devblogs.microsoft.com/go/go-1-24-fips-update/
    • Kardeş yorumlarda söylendiği gibi bazı durumlarda zorlama gerekir.
      Bunu gizli bug’lardan kaçınmanın bir yolu olarak da görebilirsiniz. "The server chose violence" [1] [2] örneğine benzer; Postel yasasının birlikte çalışabilirliği ne kadar yavaşlattığını da düşünmeye değer. Bu nokta FIPS sertifikasyonunun birçok yönünde sıkça unutuluyor.
      [1] https://cliffle.com/blog/hubris-reply-fault/
      [2] https://news.ycombinator.com/item?id=40178652
  • Sonunda generic type alias geldi; çoktan gerekli olan bir özellikti.

  • Yeni tool flag beni en çok heyecanlandıran şey. Artık çirkin görünen tools.godan kurtulabiliriz.

  • Güzel. Bu sürümü GOAUTH yüzünden bekliyordum.
    Özel git depolarıyla çalışmanın daha az zahmetli hale gelmesini umuyorum, ama go help goautha bakınca çok da büyük beklentiye girmek zor görünüyor.