Gleam OTP – Aktör Tabanlı Hata Toleranslı Çok Çekirdekli Program Geliştirme

 (github.com/gleam-lang)
1 puan yazan GN⁺ 2025-10-21 | 1 yorum | WhatsApp'ta paylaş
  • Gleam OTP, aktör modelini kullanarak hata toleransına ve çok çekirdekli performansa sahip programlar geliştirmeyi destekler
  • Tam tür güvenliği ve Erlang OTP ile uyumluluk hedeflemesiyle öne çıkar
  • Supervisor aracılığıyla hata kurtarma ve kendi kendini iyileştirme özellikleri sunar
  • Erlang/OTP’nin yalnızca bazı özelliklerini sunar; ek yönetim stratejileri şu anda geliştirilmektedir
  • Genel süreçler, aktörler, supervisor’lar gibi çeşitli aktör tiplerini destekler

Gleam OTP Genel Bakış

  • Gleam OTP, Erlang’ın OTP mimarisini temel alan güçlü bir aktör çerçevesidir ve hata toleranslı çok çekirdekli programlar geliştirmek için uygundur
  • Açık kaynaklı bir projedir ve Apache-2.0 lisansı ile sunulmaktadır

Başlıca Özellikler ve Avantajlar

  • Aktörler ve mesajlar için tam tür güvenliği sağlar
  • Erlang OTP ile uyumluluk sunar; bu da mevcut Erlang ortamlarıyla entegrasyonu kolaylaştırır
  • Supervisor sayesinde hata algılama, otomatik kurtarma ve sonlandırma yönetimi gibi hata toleransı özellikleri sağlar
  • Erlang OTP’ye denk aynı performansı hedefler
  • Sağlanan dokümantasyon ve örnekler sayesinde öğrenmesi ve gerçek projelerde uygulanması kolaydır

Aktör Tiplerine Göre Açıklama

  • Process

    • OTP içindeki en temel yapı taşıdır
    • Diğer aktör tiplerinin temelini oluşturur ancak Gleam uygulamalarında doğrudan sık kullanılmaz

  • Aktör

    • En yaygın kullanılan process tipidir ve Erlang’daki gen_server’a benzer işlevler sunar
    • OTP sistem mesajlarını otomatik işler, hata ayıklama ve izleme özelliklerini etkinleştirir

  • Supervisor

    • Diğer process’leri başlatır ve denetleme ile kurtarma görevini üstlenir
    • Alt process’ler çökme veya istisna durumlarında otomatik olarak yeniden başlatılır
    • Supervisor’ların iç içe yapılandırılması (supervision tree) ile uygulamanın hata toleransı yapısı oluşturulur
    • Ayrıntılı uygulama için gleam/otp/static_supervisor, gleam/otp/factory_supervisor belgelerine bakılabilir

Sınırlamalar ve Sorunlar

  • Şu anda aktörler tüm OTP sistem mesajlarını desteklememektedir; desteklenmeyen mesajlar yok sayılır
  • Bazı OTP hata ayıklama API özellikleri sınırlıdır
  • Gerekirse issue açılarak henüz uygulanmamış mesajlar için destek talep edilebilir

Sonuç ve Projenin Önemi

  • Gleam OTP, Erlang ekosisteminin güçlü yönlerini Gleam diline taşıyarak tür güvenliği ve çok çekirdekli hata toleransı sağlaması açısından büyük önem taşır
  • Kararlılık ve performansın kritik olduğu gerçek servis uygulamaları için uygundur
  • Startup’lar, IT alanındaki profesyonel geliştiriciler ve genel geliştirici kitlesi için öğrenme ve pratikte uygulama açısından değeri yüksek bir açık kaynak projedir

İlgili okumalar

1 yorum

 
GN⁺ 2025-10-21
Hacker News görüşleri
  • Ben küçük bir projeye gleam/lustre ile başladım ve şu ana kadar gerçekten çok memnunum
    Statik tipler, null’suz bir ortam, fonksiyonel ve ML ailesinden dillere ilginiz varsa gleam’i denemenizi tavsiye ederim
    Üstelik yine BEAM üzerinde çalışıyor
    • Ben de aynı fikirdeyim
      gleam’i kurduğumda sistemime yaklaşık 50 paket yüklendi; bunlar muhtemelen Erlang/Elixir ile ilgili paketlerdi
      Sadece JS’ye transpile etmek istesem ne olurdu diye merak ediyorum. Belki de bu, sistemimdeki paketleme meselesidir
      Lua’yı transpile hedefi olarak desteklese daha da iyi olurdu. Bana göre bir DSL’i başka programlara gömmek için Lua, JS runtime’ından 3 kat daha kolay
      Şimdiye kadar en sevdiğim şey ise topluluk oldu. gleam topluluğundaki kütüphanelerin ve kaynakların kalitesi gerçekten çok yüksek
      Rust topluluğunu hatırlatıyor; zor problemlerle akıllı insanlar zaten ilgilenmiş oluyor ve iyi çözümler kolayca bulunabiliyor (lustre, squirrel vb.)
      Çok fazla deneysel ve yaratıcı deneme görmek de ayırt edici bir özellik. Büyük dil ekosistemlerinde pek görülmeyen şeyler burada öne çıkıyor. Topluluk büyürken çok sıcak karşılayan bir havası var
    • Söylediklerinin hepsi ilgimi çekiyor. Ama BEAM ya da OTP’yi hâlâ düzgün anlamış değilim
      Nereden başlamanın iyi olacağını önerir misin?
    • Yukarıda bahsedilenlerin hiçbirinde deneyimi olmayan biri olarak, önce gleam/lustre mı yoksa elixir/phoenix mi öğrenmek daha iyi olur merak ediyorum
  • Gleam kullananların Phoenix benzeri bir web framework’ü de kullanıp kullanmadığını merak ediyorum
    Phoenix gibi bir framework’ü Gleam ile birlikte kullanmak mümkünse gerçekten harika olur diye bakınıyorum
    Şu anda Python ile yeni bir proje hazırlıyorum ama Gleam tarafında da kullanılabilir bir seçenek varsa denemek isterim
    • Lustre geliştiricisinin Gleam/Lustre ile LiveView benzeri özellikler yaptığı bir sunum videosu var
      Ön yüz/arka yüzün hangi kısımda yer alacağını çok kolay seçebilmek bunun avantajlarından biri
      YouTube bağlantısı
    • Phoenix, Django ya da Rails gibi tam kapsamlı bir framework henüz yok
      Bunun yerine web uygulaması geliştirirken sık kullanılan araçlar var
      Lustre temel görünüm aracı, Wisp ise sunucu tarafını üstleniyor
      SQL tarafında squirrel ve POG var (yeni ama popülerleşiyor)
  • PureScript, Erlang backend’ini destekleyen olgun bir fonksiyonel programlama dili
    BEAM için farklı bir statik tip alternatifi istiyorsanız iyi bir seçenek
    Haskell’in bir lehçesi gibi ve strict evaluation ile row polymorphism destekliyor
    • PureScript’in JS backend’i olgun, ama Erlang backend’i ve onun ekosistemi Gleam’e kıyasla çok daha küçük
    • Resmî web sitesinde ve github reposunda PureScript’in JS’ye derlendiği yazıyor; Erlang backend’i bilgisini nereden duydun merak ettim
  • Erlang/BEAM’e büyük ilgim var ama gerçekten denemeye hiç zamanım olmadı
    Pratikte nasıl kullanıldığını merak ediyorum. Tüm servis mantığını bununla mı kuruyorsunuz, yoksa sadece belirli bölümler için mi kullanılıyor?
    • Ben bir ekibe liderlik ederken Gleam’e kademeli geçiş yapıyorum
      "functional core, imperative shell" desenini en uç noktaya kadar uygulayarak, Gleam’in mevcut Ruby on Rails kod tabanında ağır hesaplama işlerini üstlenen ayrı bir katman olmasını sağladım
      OTP özelliklerini neredeyse hiç kullanmıyoruz; Rails ise web UI/HTTP API gibi asıl güçlü olduğu alanlara odaklanıyor
      Job giriş değerlerini Rails hazırlıyor ve job verisi Redis üzerinden Gleam’e tek bir atomik değer kümesi olarak aktarılıyor
      Ağ ve dosya IO için Elixir ile ince bir wrapper yaptık; iş mantığı ise Gleam modüllerinde yer alıyor
      Bu yöntem hakkında daha teknik ve ayrıntılı bir yazıyı yakında makale olarak paylaşmayı düşünüyorum. HN’de sık ilgi gören bir konu
    • TV Labs’te Elixir ile web servisleri, gerçek zamanlı eşleştirme motoru, Lua kod sandboxing, binary protokolle mikrodenetleyicilerle iletişim, makine öğrenmesi ve daha birçok şey yapıyoruz
      Elixir genel amaçlı olarak harika bir dil ve pek çok alanda güçlü
      Daha ayrıntılı sohbet için Developer Voices videoma bakabilirsiniz
      YouTube bağlantısı
    • elixirforum.com’a gelip sohbet etmeni tavsiye ederim
      Birçok insan Erlang/Elixir & BEAM ile ciddi sistemler kuruyor; merak ettiğin şeyleri sorarsan iyi yanıtlar alırsın
    • İki yaklaşımı da gördüm
      OTP’yi yeterince anladıktan sonra tüm sistemi onun üzerine kurmak doğal gelmeye başlıyor
      Ben de 7 yıldır böyle yapıyorum ama yeni geliştiricilerin bu ekosisteme alışmasının uzun sürdüğünü gördüm
  • Gleam’in daha ciddiye alınmasını istiyorsa, proje sayfasına güçlü siyasi mesajlar yazmaması daha iyi olur diye düşünüyorum
    Teknik bir proje sayfasına neden siyasi bir mesaj koymak gereksin, anlamıyorum
    Bu, katılıp katılmama meselesi değil; profesyonel bir bağlamda bu tür tartışmaların dışarıda bırakılmasının daha uygun olduğunu düşünüyorum
    Aksi halde konuşma gereksiz yere konudan sapıyor
    • "Black lives matter. Trans rights are human rights. No nazi bullsh*t."
      Sayfanın alt tarafında sadece bir kez geçen o tek satırdan mı bahsediyorsun?
      Eğer bu tek cümle yüzünden kullanmamaya karar veriyorsan, o zaman tam da amaçlandığı gibi çalışıyor demektir
    • "Konuşma gereksiz yere konudan sapıyor" dedin ama
      Aslında konuyu saptıran kişinin sen olduğun düşünülebilir
  • Bana göre actor modeli, süreçler arasında bilgi paylaşmanız gerektiğinde dağıtık hesaplama problemlerini beraberinde getiriyor
    Benim açımdan hata toleransı ve çok çekirdek desteği için Scala/ZIO’daki gibi software transactional memory ve fonksiyonel effect sistemi kullanmak daha iyi
    Yine de actor modeline ihtiyaç duyulan yerlerde kullanılabilir
    Ayrıca JVM ekosisteminin olgunluğu, gözlemlenebilirliği ve üretim sahasındaki gerçekliği düşünüldüğünde BEAM’den daha üstün
    • Oldukça sıra dışı bir bakış açısı bence
      BEAM’in zayıf yanlarını eleştirmeni anlarım ama güçlü olduğu tarafı eleştirmek bana pek anlamlı gelmiyor
      BEAM, immutable mesajların hafif ve ucuz green thread’ler arasında iletildiği bir yapı
      Sağlam supervisor tree’leri var; bu sayede data race ya da thread’in durması gibi şeyler için endişelenmiyorsunuz
      Bunların hepsi varsayılan olarak yerleşik olduğundan boilerplate de yok
      Immutable yapı sayesinde performans da şaşırtıcı derecede iyi
      Sonuçta BEAM, hata toleranslı, dağıtık/eşzamanlı sistemler için en optimize platformlardan biri
    • Bahsedilmeyen bir nokta var: Erlang (gleam’in dayandığı temel), %99.9999999 uptime sağlayabilmiş bir dil
      Böyle bir dayanıklılığın önemli parçalarından biri güçlü supervising ve makineler arası altyapı
      Actor sistemlerinin ortaya çıkmasına büyük ilham veren dillerden biri
      Kelimenin tam anlamıyla Erlang bu tek iş için var ve bunu gerçekten çok iyi yapıyor
    • "Actor modelinde süreçler arası paylaşım zor" diyorsun ama aslında actor modeli veriyi ya kopyalayarak ya da mesajla sahipliği devrederek işler
      Gerçekten paylaşılması gereken veri varsa bunun zaten immutable olması gerekir
    • Mutable veriyi immutable veri yapıları üzerinden aktaramadığınız bir duruma örnek verebilir misin, merak ettim
      Benim aklıma sadece aşırı ağır sayısal hesaplamalar geliyor; onlar da zaten elixir ya da erlang ile doğrudan yazılmaz, NIF ile uygulanır
    • Elixir/Gleam/OTP’de programların tamamı bağımsız süreçlerin bir kümesidir
      Actor desenini açıkça kullanmasanız bile durum aktarımı ve koordinasyon zaten çözülmüş problemler
      Task, Agent, GenServer, Supervisor gibi temel primitive’lerin hepsi mevcut