Elixir v1.20: Artık kademeli olarak türlenen bir dil

 (elixir-lang.org)
2 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Tür çıkarımı ve kademeli (gradually) tür denetimi tüm Elixir programlarına uygulanıyor; böylece tür anotasyonları olmadan da ölü kod ve çalışma anında kesin olarak başarısız olacak doğrulanmış hatalar bulunabiliyor
  • dynamic() türü, “her şeye izin veren” any()'den farklı olarak, çalışma zamanında mümkün olan tür aralığını izliyor ve yalnızca izin verilen türlerle tamamen örtüşmediğinde ihlal bildiriyor
  • dynamic(integer() or binary()) değeri, sayısal işlemler veya string fonksiyonları gibi olasılıkların kısmen örtüştüğü çağrılarda ihlal üretmezken, yalnızca map kabul eden Map.fetch! gibi çağrılarda ihlal üretiyor
  • dynamic(), kullanım biçimine göre daraltılıyor ve data.a + data.b gibi kodlarda datayı %{..., a: number(), b: number()} biçimindeki bir map olarak rafine ediyor
  • Guard içinde birleşim, kesişim ve değilleme çıkarımı yapılarak is_list, is_integer, is_map_key, not is_map_key, tuple_size gibi koşullar tür bilgisi olarak kullanılıyor
  • case ve koşul ifadeleri, önceki dalın bilgisini sonraki dala yansıtarak, önce nil'i işleyip ardından kalan değeri binary() olarak daraltma gibi tür denetimleri yapıyor
  • Standart kütüphanedeki tuple ve map ile ilgili çeşitli fonksiyonlara türler eklendi; bu da mevcut kod tabanlarında yinelenen dalları ve ölü kodu bulmaya yardımcı oluyor
  • “If T: Benchmark for Type Narrowing” içinde 13 kategorinin 12'sini geçerek, genel Elixir kodunda hassas tür bilgisinin geri kazanılabildiğini gösteriyor
  • v1.20, çok çekirdekli ortamlardaki uygulamalarda derleme süresini yeniden iyileştirdi ve sentetik benchmark'ta Elixir build aracının BEAM dilleri arasında en hızlı sonucu verdiği görüldü
  • Yeni derleyici seçeneği :module_definition, module tanımı yürütme biçiminin varsayılanını :compiled veya :interpreted olarak seçmeyi sağlıyor ve mix.exs içindeki elixirc_options: [module_definition: :interpreted] ile etkinleştiriliyor
  • :module_definition seçeneği, diske yazılan .beam dosyalarını etkilemiyor ve yalnızca defmodule içindeki yürütme biçimini değiştiriyor; bu da büyük projelerde derleme süresini iyileştirmeye yardımcı olabilir
  • Küme kuramı türlerini kullanan yeni tür imzaları, v1.20'nin tür sistemi performansı, özyinelemeli türler, parametreli türler ve map key-value dolaşımı araştırmaları tamamlandıktan sonra typed struct tanımlarıyla birlikte tartışılacak

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News görüşleri

  • Bu kişisel bir deneyim olabilir ama, baştan beri tipleri olan bir dil değilse gerçek anlamda statik tipli bir dil kadar iyi çalışmıyor gibi geliyor

    • Katılıyorum ama başka bir bakış açısı da var: “Why are gradual static types so great?” https://www.benkuhn.net/gradual/
    • Öte yandan TypeScript, tipsiz bir dilde insanların yıllar boyunca yaptığı her türlü tuhaf deseni desteklemek zorunda olduğu için benim en sevdiğim tip sistemi haline geldi

  • Yaklaşık 10 yıldır profesyonel Elixir geliştiricisi olarak çalışıyorum ve tiplerin gelmesini uzun zamandır bekliyordum. Bu başlangıcın gerçekten hayata geçmiş olmasına çok sevindim
    Yine de v1.20’deki durumun, spesifikasyonsuz Dialyzer ile karşılaştırıldığında nasıl olduğunu bilmek isterim. Dialyzer’ın success typing yaklaşımını, “başarısız olabilecek bir argüman kombinasyonu varsa uyarı ver”den ziyade “çalışan en az bir argüman kombinasyonu varsa uyarı verme” şeklinde anlamıştım; Elixir’in burada yaptığı şeyin de buna benzer olduğunu sanıyordum ve Dialyzer’ı pek faydalı bulmamıştım

    • Hâlâ üretimde olan 10 yıllık bir Elixir kod tabanında neler bulacağını merak ediyorum

  • Elixir’in kademeli tip sistemiyle ilgili yazıları HN’de birkaç kez gördüm ama ayrıntılı takip etmedim. Bu kademeli tip sisteminin, tipsiz kodla karşılaştırıldığında programın asimptotik karmaşıklığını değiştirip değiştiremeyeceğini bilen biri var mı merak ediyorum
    Bildiğim kadarıyla Racket gibi çoğu kademeli tip sistemi programı asimptotik olarak daha yavaş hale getirebilir ve bazı istisnalar da var [1]
    [1] https://doi.org/10.1145/3314221.3314627

    • Elixir’in kademeli tip sistemi programın asimptotik karmaşıklığını değiştiremez. Tasarım gereği, diğer kademeli tip sistemlerinde yavaşlamaya neden olan statik/dinamik sınırdaki çalışma zamanı cast’lerini açıkça dışarıda bırakır
      Kademeli tip sistemlerinin çoğu, tipli kod ile tipsiz kod arasındaki sınırı bir değer geçtiğinde zorlayıcı kontroller ekler. Örneğin bir listedeki tüm öğeleri kontrol eder ya da değeri bir tip proxy’siyle sarar. Ancak Elixir ekibi, bu tür çalışma zamanı kontrolleri olmadan soundness elde etmek için strong arrows sonuçlarını yayımladı ve derleyicinin ürettiği bytecode anlamsal olarak tipsiz kodla aynıdır

  • İronik şekilde eleştirmenler tiplerin gerekli olduğunu söylüyordu, Elixir hayranları ise tiplere gerek olmadığını ve Elixir’in bir şekilde sihirli olduğunu, bu yüzden tipe ilişkin hatalar üretmediğini söylüyordu; şimdi ise tip ekleyince hataları buluyor. Hani hata önlemek için gerekmiyordu? Yine de iyi bir değişim. Eskiden Elixir’i epey kullandım ve keyif aldım ama tip eksikliğini kabul etmek zordu

    • Bu bir Goomba fallacy
      https://en.wiktionary.org/wiki/Goomba_fallacy
    • Elixir’i özellikle yakından takip etmedim ama Erlang tarafındaki tartışmalarda gördüğüm şey biraz farklıydı. Nasıl olsa hataları zarif biçimde ele almak zorunda olduğunuz için, tip hataları da zaten sahip olmanız gereken hata kurtarma mekanizması ile ele alınabilir diye düşünülüyordu
      Bu bakış açısına katılmıyorum ama “$LANGUAGE sihirlidir” demekten çok daha savunulabilir bir iddia
    • Böyle bir iddiayı hiç görmedim diyemem ama hatırlamıyorum; varsa da büyük olasılıkla çok küçük bir azınlıktı. Asıl karşı argüman genelde “tipler iyidir ama bir maliyetleri vardır ve bu maliyet her zaman yeterli getiri sağlamayabilir” şeklindeydi
      Küme kuramsal tip teorisi gelişmeden önce bu pozisyon muhtemelen doğru da olabilirdi
    • Aynı şey JavaScript/TypeScript ve Python’da da oldu. Bazen insanları inanmak istedikleri şeye inanmaya bırakmaktan başka çare olmuyor
    • Hayatın döngüsü bu. Dinamik tipli bir dil taraftar toplar, başka insanlar da statik tipler olsa çok daha kullanışlı olacağını — haklı olarak — söyler. Taraftarlar bunu kişisel algılar ve statik tiplerin gerekli olmadığını savunur. Gerekçeler çeşitlidir: “zaten o kadar faydalı değil”, “dilin ruhuna aykırı”, “sadece bir betik dili”, “debugger kullan yeter”, “statik tipler üretkenliği düşürür” vb.
      Sonunda da statik tipler eklenir. Python, JavaScript ve Ruby’de oldu; başka örnekler de vardır

  • Elixir’i güncellediğinizde birden fazla projede kırıcı değişiklik olmaması ve derleyicinin bedavaya hatalar bulması gerçekten harika. Buna fazla alıştım

  • Bunu görmek beni gerçekten mutlu ediyor. Artık “harika dil” seviyesine iyice yaklaşıyor ve benim için Elixir bir numaralı aday
    Eğer kullanımı zaten rahat olup da buna rağmen harika özellikleri istikrarlı ve güvenli biçimde eklemeyi sürdüren başka bir dil biliyorsanız, duymaktan memnun olurum. Go’da ustalaşmaya çalışırken sonra ileri seviye C# öğrenmeye yöneldim; Go’nun iyi özellikler ekleme konusunda durakladığını hissettim

  • Son bir aydır Elixir exercism.io parkurunu yapıyorum https://exercism.org/tracks/elixir
    Gerçekten mükemmel

  • Ah, yine başlıyoruz. Sanırım bir yıl boyunca tekrar Elixir öğreneceğim
    Elixir’nin her şeyi hoşuma gidiyor ama başka herhangi bir dilden daha çok, Elixir sürekli kendimden şüphe etmemi sağlıyor. Sanırım beynim fonksiyonel yapıya uygun değil ama bu değişiklik yüzünden tekrar denemek istiyorum
    Üzücü olan şu ki ekosistemin yeni başlayanlar için dost canlısı olduğunu söylemek zor ve sorulara yanıt verilirken genelde dili zaten epey bildiğin varsayılıyor

    • https://pragprog.com/titles/lhelph/functional-web-developmen...
      Başlığına aldanmayın. Kitabın ilk yarısı dümdüz Elixir
      Son 8 yılda Elixir’ye her yeniden alışmaya çalıştığımda bu kitaba döndüm ve her seferinde işe yaradı. Hiç sonuna kadar okumuş değilim
      Bu tür öğretici proje odaklı programlama kitaplarının iyi olup olmadığını anlamak için ölçütlerimden biri şu: birkaç kez başlayıp hiç bitirmeseniz bile, daha ortalarına geldiğinizde kendi işinizi yapmaya koyulacak araçları size veriyor mu?
    • Üniversitede ilk kez Haskell’i “programlama paradigmalarına giriş” gibi bir derste denediğimde bunu gerçekten acı verici şekilde yaşamıştım. O zamana kadar zaten birkaç yıldır programlama yapıyordum ama uzun süredir temel saydığım şeyleri yapmakta bu kadar çaresiz kalabilmeme inanamamıştım
      Ama bunun beynimin uyumsuz olmasından çok, zorunlu programlama dillerinde biriktirdiğim deneyim seviyesiyle saf fonksiyonel stilde yeniden acemi olarak başlama arasındaki tezatla ilgili olduğunu düşünüyorum
      Zamanla daha iyi olacak. Fonksiyonel programlamaya ısınmamı sağlayan şey, bol boşluklu Bash “tek satırlık komutları” birleştirmeyi ne kadar sevdiğimi fark etmek oldu. Verinin nasıl başladığını görüp bir komutla döküyorum, istediğim şekle biraz daha yaklaşan adımları düşünüp bir sonraki komuta pipe’lıyorum, sonra tekrar bakıyorum. Böyle böyle sonunda genelde değiştirilmeden kalan veriler üzerinde yapılan dönüşümlerin bir zinciri ortaya çıkıyor
      Bunu shell’de rahat yapan şeylerden biri, her gün dosya sistemi içinde dolaşırken bir komut dağarcığı biriktiriyor olmanız. Unix benzeri bir ortamda aşina olduğunuz “fonksiyon” kütüphanesi yıllar içinde oldukça büyümüş oluyor. Saf fonksiyonel programlama ortamında da aynı şeyi yapmak gerekiyor ama dağarcığı öğrenmek biraz daha fazla emek istiyor. Sık kullanılan “komutlar” grep, cat, sort yerine map, fold, zip gibi fonksiyonlar oluyor
      Ama özünde gerçekten aynı şey ve pipeline kurmanın cazibesi iki tarafta da aynı. Parça parça inşa edebiliyorsunuz ve her bulmacada önceki adımı unutup sadece önünüzdeki veriyi sıradaki adımda nasıl dönüştüreceğinizi düşünmeniz yetiyor. Bu düşük bağlam ihtiyacı tazeleyici ve rahatlatıcı
      Umarım denersiniz ve keyif alırsınız. Bir şeyi yapamıyor olma halinden keyif almayı başardığınızda, sonunda gerçekten iyi olmaya başlıyorsunuz
    • Rust’ı biraz bilip bilmediğinizi merak ediyorum. Benim de fonksiyonel dillerle çok deneyimim yok ama Gleam, Rust benzeri yönleri sayesinde tanıdık hissettirdi ve bu da sözdiziminden çok kavramlara odaklanmamı sağladı
      Tabii ki sadece birkaç öğleden sonra kurcaladım ama beynimi yeniden fonksiyonel dillere alıştıracak olsam, tanıdıklık yüzünden Gleam’i seçerdim
    • ElixirForum’da sormanızı tavsiye ederim. Gerçekten düşmanca bir tepki gördüğümü hatırlamıyorum
      Bazen belirsiz olduğu için ilgi görmeyen ya da “ödevimi benim yerime yap” havası verdiği için görmezden gelinen gönderiler oluyor
      Ama gerçekten merak içeren gönderilerin, benim gördüğüm kadarıyla, hepsi yanıt alıyor
    • Bu tür sözler bana hep kafa karıştırıcı geliyor. Durumla iyice iç içe geçmiş nesne yönelimli programlar bana çok daha zor akıl yürütülebilir geliyor

  • Harika. 1.20’de büyük umbrella uygulamamızın derlenmesi epey daha hızlı olmuş gibi görünüyor

  • Gleam’le karşılaştırınca nasıl acaba? Ya da artık neden Gleam yerine Elixir kullanalım? Phoenix, özellikle de LiveView, Elixir’nin büyük çekim noktası gibi görünüyor

    • Fark, Rust’ı mı sevdiğiniz yoksa Erlang’ı mı sevdiğinizle ilgili. Gleam kullanmak Rust kullanmak gibi hissettiriyor, Elixir kullanmaksa Erlang kullanmak gibi
      Gleam OTP’nin şu anki durumunu bilmiyorum ama en son baktığımda iyi değildi
      İkisi de size fark etmiyorsa ve önemli olan sadece tiplerse, o zaman Gleam kullanın. Ama o durumda neden doğrudan Rust kullanmıyorsunuz ki?
    • Gleam sitesinde doğrudan bir karşılaştırma sayfası var
    • Gleam’de makrolar yok ve Phoenix ya da Ecto gibi birçok Elixir kütüphanesi makroları çok etkili kullanıyor
      Örneğin Gleam’de JSON decode/encode işleri hantallaşabiliyor. Rust’ta serde derive edersiniz, Elixir’de ise tek bir fonksiyon çağrısı yeter
      Elixir daha olgun bir ekosisteme sahip. Örneğin Gleam’de Phoenix ya da başka Gleam framework’leri kullanabilirsiniz ama deneyim aynı olmuyor
      Gleam’in Elixir’den daha çekici gelmesinin büyük nedeni tiplerdi ve Elixir şimdi bu farkı kapatıyor. Bir de JavaScript’e derlenebilmesi var; Elixir tarafında Hologram benzer bir şey yapıyor
      Kişisel olarak Gleam’in tip sistemini ve Rust benzeri sözdizimini daha çok seviyorum ama şu anda tüm web geliştirme projelerim için Elixir’nin daha iyi seçim olduğunu düşünüyorum
    • Esasen mesele Phoenix ve Ecto