1 puan yazan GN⁺ 2025-10-17 | 1 yorum | WhatsApp'ta paylaş
  • Elixir 1.19 sürümü, tip sisteminin güçlendirilmesi ve derleme performansının iyileştirilmesi sayesinde daha fazla hatanın daha hızlı tespit edilmesini sağlıyor
  • Tip çıkarımı, anonim fonksiyonlar ve protokollere kadar genişletildi; böylece kullanıcının tip notları olmadan da çok daha kapsamlı otomatik doğrulama mümkün hale geliyor
  • Büyük projelerde 4 kata kadar daha yüksek derleme hızı sunuyor; buna paralel derleme ve kod yükleme optimizasyonları da dahil
  • Erlang/OTP 28 desteği, OpenChain uyumluluğunun eklenmesi gibi yeniliklerle ekosistem ve tedarik zinciri şeffaflığı da güçlendiriliyor
  • Bunun yanı sıra opsiyon ayrıştırma iyileştirmeleri, ExUnit hata ayıklama kabiliyetlerinde artış, shell tabanlı dokümantasyon erişilebilirliğinde geliştirmeler gibi birçok özellik de bulunuyor

Elixir 1.19 başlıca iyileştirmeleri

Tip sistemi iyileştirmeleri

Tüm bileşenler için tip çıkarımı

  • Type inference (tip çıkarımı), ifadelerin tipini derleme anında otomatik olarak belirleme özelliğidir
  • Daha önce tip çıkarımının ağırlıklı olarak pattern, guard ve dönüş değerleri için desteklenmesi hedefleniyordu; bu sürümle birlikte tüm bileşenler için (guard'lar hariç) tip çıkarımı getirildi
  • Modül içi çağrılar ve Elixir standart kütüphanesi fonksiyon çağrıları da dikkate alınarak tip çıkarımı yapıldığından, eskiden dynamic() -> boolean() olarak çıkarılan fonksiyonlar artık integer() -> boolean() gibi daha net şekilde çıkarılabiliyor
  • Tip çıkarımı; derleme hızı, ifade gücü, artımlı derleme ve hata açıklığı gibi çeşitli ödünleşimler içerdiğinden, ileride guard tip çıkarımı ve bağımlılıkların tip bilgileri de eklenmesi planlanıyor
  • Bir fonksiyon için tip imzası açıkça belirtilirse, sistem tip çıkarımı yerine açık tip denetimi olarak çalışır ve yalnızca kullanıcının notlarına uyan tiplere izin verir

Protokol dağıtımı ve implementasyonda tip denetimi

  • Elixir artık protokol çağrıları ve implementasyonları sırasında tip denetimi uyguluyor
  • Örneğin, String.Chars protokolünü uygulamayan bir tip string interpolation içine verilirse uyarı mesajı üretiliyor
  • for comprehension içinde Enumerable protokolünü karşılamayan bir tip jeneratör olarak verilirse de uyarı oluşuyor
  • Bu tip denetimleri sayesinde derleme zamanında daha fazla hata önlenebiliyor

Anonim fonksiyonlar için tip çıkarımı ve denetim

  • Elixir 1.19, anonim fonksiyonlar için tip çıkarımı ve tip denetimi desteği sunuyor
  • Örneğin %{} tipi bekleyen bir anonim fonksiyona "hello" gibi yanlış bir tip verilirse, bu durum derleme zamanı uyarısı olarak anında tespit edilebiliyor
  • Fonksiyon yakalama (&String.to_integer/1 gibi) için de tip çıkarımı uygulanarak otomatik tip doğrulamasının kapsamı genişletiliyor

Referanslar ve iş ortakları

  • Bu tip sistemi, CNRS ile Remote ortaklığında geliştirildi
  • Fresha, *Starfish* *, Dashbit ve diğerleri destek verdi

Büyük projelerde daha hızlı derleme

Kod yükleme darboğazlarının iyileştirilmesi

  • Daha önce modüller tanımlanır tanımlanmaz yükleniyordu; bu sürümde ise lazy loading (tembel yükleme) stratejisine geçildi
  • Böylece kod sunucusunun yükü azalıyor ve paralel derleme performansı artıyor; büyük projelerde derleme hızı 2 kattan fazla yükseliyor
  • Dikkat edilmesi gereken iki önemli nokta
    • Derleme sırasında ayrı bir süreç oluşturup aynı proje içindeki modüllere erişiliyorsa, yükleme atlanabilir; bunu aşmak için Kernel.ParallelCompiler.pmap/2 veya Code.ensure_compiled!/1 gibi yöntemler kullanılabilir
    • @on_load callback'i içinde aynı proje içindeki modüller çağrılırsa hata oluşabilir; gerekirse @compile {:autoload, true} seçeneği kullanılabilir
  • Her iki durumda da geçmişte belirlenemeyen derleme hataları oluşabiliyordu; bu iyileştirmeyle birlikte deterministik (yeniden üretilebilir) bir derleme ortamı sağlanıyor

Bağımlılıkların paralel derlenmesi

  • MIX_OS_DEPS_COMPILE_PARTITION_COUNT ortam değişkeni kullanılarak bağımlılıkların paralel derlenmesi destekleniyor
  • Birden fazla OS süreci aynı anda kullanılarak bağımlılıklar paralel biçimde derleniyor; proje boyutuna ve CPU çekirdek sayısına göre derleme performansı 4 kata kadar artabiliyor
  • Deneysel olarak, toplam çekirdek sayısının yaklaşık yarısının ayarlanması kaynak kullanımında etkili görülüyor
  • Paralelleştirme bellek kullanımını artırabileceğinden, CI veya build sunucularında uygulanırken dikkat edilmesi gerekiyor

Erlang/OTP 28 desteği

  • Elixir 1.19, Erlang/OTP 28.1+ sürümünü resmî olarak destekliyor
  • Erlang/OTP 28'deki regular expression gösterimindeki değişiklik nedeniyle, struct'ların varsayılan değeri olarak regular expression kullanmak artık mümkün değil
  • Ancak struct başlatılırken regular expression kullanımı hâlâ mümkün

OpenChain uyumluluğunun eklenmesi

  • Bu sürüm, OpenChain standardına uyumluluğun başladığı ilk sürüm
  • Her sürümle birlikte CycloneDX 1.6/SPDX 2.3 biçiminde SBoM (Source Bill of Materials) sunuluyor
  • Bu, sürüm bileşenleri ile lisansların tedarik zinciri şeffaflığını artırıyor ve daha sıkı yönetime katkı sağlıyor
  • Bu çalışma Jonatan Männchen tarafından yürütüldü ve Erlang Ecosystem Foundation tarafından desteklendi

Diğer iyileştirmeler

  • Opsiyon ayrıştırma, ExUnit'in hata ayıklama ve performans özellikleri, shell tabanlı dokümantasyon erişilebilirliği gibi alanlarda çeşitli araç ve kütüphane iyileştirmeleri eklendi
  • Daha ayrıntılı sürüm notları için CHANGELOG'a bakılabilir

1 yorum

 
GN⁺ 2025-10-17
Hacker News görüşleri
  • Elixir’e otomatik tip denetimini kademeli olarak getirme yaklaşımının, diğer programlama dillerinin de örnek alabileceği harika bir dil geliştirme örneği olduğu vurgulanıyor; geçmişte büyük değişiklikler yüzünden ekosistemi ikiye bölünen pek çok dil örneği vardı ve José’nin 2018’den beri dilin kendisinin tamamlandığını açıkça söylemiş olması güven veriyor. Dil ve çekirdek artık kırılmayacağı için ciddi bir istikrar hissi verdiği anlatılıyor. İlgili sunum videosu öneriliyor; tutarlı ve başarılı yönetim çok etkileyici bulunuyor

    • Büyük değişiklikler nedeniyle ekosistem bölünmesi denince akla esas olarak Python 3 ve Perl 6 geliyor; bu ikisinin yarattığı etki çok büyük olduğu için diğer dil değişimleri de devasa görünüyormuş gibi hissediliyor
    • Elixir’de insan sürekli sürüm yükseltmeye zorlanmış hissetmiyor; gelen değişiklikleri görüp kullanışlı yeni özellikler için yükseltme yapmak isteme deneyimi yaşanıyor. “Mecburen şimdi sürüm değiştir” denildiğindeki türden kaygı veya stres oluşmuyor
    • 2017’den beri production ortamında Elixir kullanan biri, her yükseltmenin beklediğinden çok daha sorunsuz geçtiğini söylüyor. Hatta uyumluluk sorunları nedeniyle Erlang/OTP yükseltmeleri daha karmaşık olmuş; bu yüzden çoğu zaman en güncel Elixir kullanılırken OTP sürümü için bir iki ay daha beklenip çatışma ihtimalleri giderildikten sonra yükseltme yapılıyor
    • Elixir’nin hâlâ bazı yönlerden eksik ve kullanım kolaylığı açısından yetersiz olduğu, hedefe ulaşmak için daha net yönlendirme ve ekosistemin daha da oturmasına ihtiyaç bulunduğu belirtiliyor. Birçok paketin bakımsız kalması veya dokümantasyonunun yetersiz olması, Phoenix ekosistemindeki değişim hızını takip etmeyi zorlaştırıyor. LiveViews ya da belirli component sistemlerini istemeyen çok sayıda kullanıcı da var ve diğer araçlar ile teknolojilerle uyumluluğa giriş eşiği yüksek. Python 3 geçişi 2’den 3’e zorunluydu ve otomatik migration araçlarıyla görece iyi yönetildi ama çok sayıda deneme-yanılma da yaşandı. Buna karşılık Ruby 3’te harici tip dosyalarının gelmesi ve araçların parçalanması daha fazla kafa karışıklığı yarattı; boilerplate, yönetişim sorunları ve gem ele geçirmeleri gibi olumsuz deneyimler de eklenince Ruby daha az kullanılır olmuş. Harika bir dilin bile kötü yönetim yüzünden zarar görebileceği, bu yüzden olgun iş birliği, iletişim ve iyi değişim yönetiminin çok önemli olduğu vurgulanıyor. Dil tasarımındaki değişikliklerin yeterli ön deney, dikkat ve kullanıcılara önceden yeterince bilgi verilerek gereksiz karmaşayı en aza indirecek biçimde yapılması gerektiği düşünülüyor. İleride Elixir/Phoenix/OTP’nin daha kolay, daha güçlü, daha üretken ve daha yüksek performanslı hale gelip çok farklı kullanıcıların güvenle kullanabileceği bir noktaya gelmesi umuluyor. Livebook ve Exercism Elixir track gibi kaynaklar öneriliyor
  • Elixir sürekli olarak harika özellikler ve iyileştirmeler çıkarırken istikrarlı biçimde gelişiyor; dil yapısı olağanüstü ve yaratıcıları da sürekli doğru yönü koruyor, bu gerçekten etkileyici. Asıl üzücü olan şey, gündelik hayatta Elixir kullanma fırsatının pek olmaması

    • Elixir kullanabilmek için işini bırakıp doğrudan kendi şirketini kurmuş
  • Phoenix’in bağımlılık derleme hızıyla ilgili deney verileri paylaşılıyor. Mac M1 Max üzerinde, yalnızca varsayılan Phoenix bağımlılıklarını içeren küçük bir uygulama için MIX_OS_DEPS_COMPILE_PARTITION_COUNT ortam değişkeni değerine göre şu derleme süreleri ölçülmüş:

    PARTITION_COUNT=1:  12.336초 (유저 32.30s, 시스템 7.23s, CPU 320%)
    PARTITION_COUNT=5:  6.970초 (유저 0.37s, 시스템 0.49s, CPU 12%)
    PARTITION_COUNT=10: 7.236초 (유저 0.38s, 시스템 0.50s, CPU 12%)
    

    Aralarda önbelleği silmek için rm -rf _build komutu kullanılmış

    • Sonraki çalıştırmaların önbellek etkisiyle ölçülmüş göründüğü, muhtemelen yerel derlemenin doğrudan dep klasöründe yapıldığı ve bu yüzden _build içinde iz bırakmadığı söyleniyor
    • Bu sürüm özelliğine dair benchmark sonucunun neden downvote aldığını anlamadığını, buna dair bir yorum yazabilecek biri olup olmadığını soruyor
  • Son birkaç ayda Gleam’i gerçekten çok sevmeye başlamış. Elixir’ye tip sisteminin gelmesi de sevindirici ama geçmişte tam da bu konu Elixir’yi benimsemeyi zorlaştıran başlıca etkenlerden biriydi. Bir gün Elixir’ye yeniden şans vermek istiyor fakat JavaScript’te TypeScript gibi yalnızca görünüşte typed olup pratikte birçok library ya da pakette yine dynamic/any tiplerine düşülmesinden endişe ediyor. Bu kaygının yersiz olup olmadığını merak ediyor. BEAM’in gerçekten harika olduğu da ekleniyor

    • TypeScript ile koşullar farklı; pattern matching sayesinde mevcut Elixir kod tabanlarında en az %50 civarında tip çıkarımı mümkün görünüyor ve sade Elixir zaten tipleri temel düzeyde sunduğu için bakımı yapılan kodlarda tiplemenin hızlı ilerleyeceği düşünülüyor. Bunu söyleyen kişi tip sistemlerini tercih etmiyor ve yalnızca JS kullanıyor ama Elixir’de tiplerin uygulanışı doğal geliyor. TypeScript yukarı doğru çıkarken Elixir’de tipler doğal biçimde aşağıya doğru yayılıyor gibi bir ortam var
    • Gleam, OTP/BEAM’in gerçek güçlü yanlarından tam olarak yararlanamıyor; bu çekicilik sadece Elixir’de var
    • Elixir’de primitive tipler, struct’lar ve shape tabanlı destructuring gibi şeylerle tip kavramı zaten eskiden beri vardı; Dialyzer ve TypedStruct gibi araçlarla da tip denetimi yapılabiliyor. JavaScript gibi absürt derecede tipsiz bir dil değil
    • Gleam güzel ama JVM tarafında Kotlin de Ruby’ye benzer sözdizimine sahip typed bir dil ve compile-to-JS de kullanılabiliyor
  • Elixir’nin web geliştirme ortamları arasında en umut verici seçenek olduğu hissediliyor; gerçek iş hayatında Elixir kullanan organizasyonlar veya ekiplerle her karşılaşıldığında bunların ortalamanın üstünde bir seviyede olduğu izlenimi oluşuyor. Sürekli geliştirme gereken ortamlarda Elixir’nin yön ve standart göstermeye devam ettiği düşünülüyor

  • Elixir sürümünün CycloneDX 1.6+ ve SPDX 2.3+ Source SBoM formatlarını desteklemeye başladığı belirtiliyor; SBOM yönetiminin dil seviyesinde yapılması gerçekten takdir ediliyor. Ne yazık ki şu anki şirkette Elixir kullanılmıyor

  • Gerçek kullanımda olan açık kaynak bir Elixir projesine katkı vermek isteyenler için, eski Mozilla Hubs’ın ana bileşenlerinden biri bağımsız bir proje olarak Elixir ile geliştirilmeye devam ediyor: Hubs Foundation/reticulum

  • Elixir standart kütüphanesi temelinde, dinamik tiplerde boolean, integer’dan boolean’a gibi uygulamaya özgü durumlara uygun tip çıkarımı derleme zamanında yapılabiliyor

  • Elixir geliştirme deneyimi yok ama hayranı. Eskiden Ruby’nin pratikliğini ve zarafetini seviyormuş ancak tip sistemlerine ilgi duymaya başlayınca kullandığı dilleri değiştirmiş. Elixir ve Ruby de tip sistemleri ekledi ama şimdi daha çok sözdizimi açısından “typed Ruby” hissi veren Kotlin kullanıyor

    • Kotlin neredeyse gerçekten istediğimiz jruby hissi
  • Soketi ile pusher sdk entegrasyonu kullanarak event broadcast yapılıyor; uygulama gerçek zamanlı endpoint’ler ile rest endpoint’lerinin karışık olduğu bir yapıda ve gerçek zamanlı işlem yükü çok büyük değil, ama gerekirse bunu Go ile ayrı ele almayı düşünüyor. Yakında iş birliği özellikleri de eklenecek; bu durumda Phoenix’e geçmenin doğru olup olmadığını sorguluyor