Erlang'ın hafif süreçler ve mesaj iletiminden ibaret olmayan özü (2023)

Arka plan

• Erlang, güvenilir dağıtık sistemler kurmak için geliştirilen bir dildir; başlangıçta bir Prolog kütüphanesi olarak başladı ve zamanla bağımsız bir dile dönüştü.
• Ericsson'da telefon santrallerini programlamak için kullanıldı ve 1998'de açık kaynağa dönüştü.
• Joe Armstrong, Erlang'ın başlıca tasarımcılarından biriydi; doktora tezi, yazılım hataları varken güvenilir dağıtık sistemlerin nasıl inşa edileceğini ele alıyordu.

Davranışlar (Behaviours)

• Erlang'daki davranışlar, Java veya Go'daki arayüzlere benzer; birden çok uygulamaya sahip olabilen tür imzaları kümesidir.
• Davranışlar sayesinde yalnızca programın iş mantığını tanımlayan kodu yazmak gerekir; altyapı kodu ise otomatik olarak sağlanır.
• Davranışlar uzmanlar tarafından yazılır ve en iyi uygulamalara dayanır.

Genel sunucu davranışı

• gen_server, bir anahtar-değer deposu uygulama örneği üzerinden açıklanır.
• handle_call, durumu güncelleme veya anahtarı sorgulama görevini üstlenir; tüm eşzamanlılık gen_server bileşeninin içinde gizlenmiştir.

Olay yöneticisi davranışı

• gen_event, olay yöneticisi olarak çalışır; olay işleyicilerini kaydeder ve bir mesaj geldiğinde onları çalıştırır.
• Hata günlükleme için kullanışlıdır ve basit bir logger örneği verilir.

Durum makinesi davranışı

• gen_fsm daha sonra gen_statem olarak yeniden adlandırılmıştır ve protokol uygulamaları için uygundur.

Gözetmen davranışı

• Gözetmen, diğer süreçlerin düzgün çalışıp çalışmadığını denetler ve başarısızlık durumunda önceden tanımlanmış stratejiye göre yeniden başlatır.
• one_for_one stratejisi yalnızca başarısız olan süreci yeniden başlatırken, one_for_all stratejisinde bir süreç başarısız olursa tüm alt süreçler yeniden başlatılır.

Uygulama ve sürüm davranışı

• Uygulama, gözetmen ağacını ve gerekli olan her şeyi içerir; sürüm ise bir veya daha fazla uygulamayı paketler.
• Yükseltme başarısız olursa geri alma mümkün olmalıdır.

Davranışların uygulanması

• Erlang'ın hafif süreçleri ve mesaj iletiminden ziyade, davranışların yapısı güvenilir yazılıma yol açar.
• Başka dillerde davranışları uygulamak için arayüz imzaları kullanılarak başlanabilir.

Davranışların doğruluğu

• Simülasyon testleri dağıtık sistemlerin test edilmesini kolaylaştırır ve gen_server davranışının yapısı kullanılarak sorun çözme basitleştirilebilir.

Katkı

• Martin Thompson'ın çalışmalarından fikirler ödünç alarak hızlı bir olay döngüsü oluşturma ve asenkron I/O ekleme gibi fikirler vardır.
• İlgileniyorsanız veya görüş, öneri ya da sorularınız varsa iletişime geçebilirsiniz.

[GN⁺]

Hacker News görüşleri

• Erlang ve BEAM’de şaşırtıcı olan şey, sundukları özelliklerin derinliği. OP için Erlang’ın Behavior/Interface yapısı en büyük kazanımdı. Bana göre ise önemli olan, karmaşık sistemler kurmak için gereken geliştirme kaynaklarının diğer dillere kıyasla çok daha az olması. Birçok kişi için hafif süreçler ve programlama modeli çekici geliyor

  • OTP çok geniş bir özellik seti içeriyor. Şu anda Elixir’yi iOS cihazlarda çalıştırılabilecek şekilde derleme üzerinde çalışıyoruz. Erlang’ın ei kütüphanesini kullanarak C’den düğümler derleyebiliyor ve diğer Erlang düğümleriyle arayüz kurabiliyoruz. Erlang’ın rpc kütüphanesi sayesinde C’den fonksiyon çağrıları yapmak ve Elixir uygulamasıyla arayüz kurmak mümkün
  • Erlang, modern teknoloji yığınlarının zorlandığı birçok problemi zaten çözdü; ölçeklenebilirlik ve uygulama maliyeti meselelerini onlarca yıl önce halletti. Ama HN’de Erlang/Elixir’e yönelik ilgi gerçek benimsemeye dönüşmedi ve birçok şirket Erlang yığınının ücretsiz sunduğu şeyleri yeniden inşa etmeye para harcıyor

• Deneyimlerine dayanarak kitap yazmak isteyen birkaç yöneticiyle birlikte çalıştım. Başarının nedenleri konusunda hep farklı düşündük. Bazıları hafif süreçler ve mesajlaşmanın gizli sos olmadığını söylüyor, ama Erlang’ın Communicating Sequential Processes yaklaşımının bu özelliklerden ayrı düşünülemeyeceğini gözden kaçırıyor

  • Örnek: uygulama programcısı sıralı kod yazar ve tüm eşzamanlılık behavior’ların içinde gizlenir
  • Yeni bir ekip üyesinin başlaması kolaydır: iş mantığı sıralıdır ve daha önce görmüş olabileceği benzer bir yapıya sahiptir
  • Supervisor’lar ve "çökmesine izin ver" felsefesi güvenilir sistemler oluşturmaya katkı sağlar

• Hafif süreçler ve mesajlaşma nedeniyle Erlang’a yeniden ilgi duymaya başladım. Şimdiye kadar behavior’lar ikincil plandaydı

  • Proje, görsel Flow Based Programming’i (FBP) Erlang’a getirmek üzerine. FBP, Erlang için uygun görünüyor ve bunun zaten mevcut olması şaşırtıcıydı
  • FBP için araç olarak Node-RED kullanıyorum; temel fikir Node-RED frontend’ini Erlang backend’ine bağlamak ve tüm düğümleri süreçlere dönüştürmek

• Ericsson’ın neden Erlang kullanımını bıraktığını ve Joe’nun işten çıkarılmasıyla ilgili bilgi arıyordum

  • Kısa cevap şu: yeni projelerde Java’ya geçmeleriyle Erlang geri planda kaldı. Joe ve arkadaşları 1998’de Bluetail’i kurdu ve şirket Nortel tarafından satın alındı. Nortel bir telekom deviydi; 2000’de hissesi $125’e kadar çıktı, ancak 2002’de $1’in altına düştü. Bu, dot-com balonunun patlaması ve telekom harcamalarındaki düşüşle bağlantılıydı

• Erlang/Elixir’nin gücü, Actor modelini uygulaması, Prolog tarzı eşleştirme, değişmezlik ya da behavior’lar değil; Joe’nun daha az kaynakla daha fazlasını yapmanın mümkün olduğunu gösterme tutkusu

  • İyi tasarlanmış, tutarlı bir sistem ve başka dillerde nadiren görülen bir bütünlük hissi var. Kusursuz değil ama etkileyici
  • Yazılım dünyasında sadeliğin gücüne dair farkındalık ve kabulün eksik olduğunu düşünüyorum

• Erlang, OTP ve BEAM behavior’ların ötesinde şeyler sunuyor. VM, sanal bir çekirdeğe benziyor; supervisor’lar, yalıtılmış süreçler ve dağıtık mod sağlıyor. OTP ayrıca Mnesia (veritabanı), atomik sayaçlar/ETS tabloları (önbellekleme) gibi faydalı modüller sunuyor

  • Bir yıl önce kişisel danışmanlık şirketimde Erlang’ı backend dili olarak benimsedim. BEAM’in iç yapısını inceleyerek TCP tabanlı yığını QUIC ile değiştirdim ve Rust yamalarını entegre ettim

• Erlang/BEAM’deki en ilginç kavramın, kısmi toparlanmanın varsayılan olarak yerleşik gelmesi olduğunu düşünüyorum. Beklenmeyen bir durum ortaya çıktığında, tüm süreci sonlandırmak ya da bozulma riskini almak yerine, mümkün olan en ince ayrıntı seviyesinde bilinen iyi bir duruma geri dönülüyor

• Erlang’ın behavior yapısının diğer diller ve kütüphane tasarımcıları tarafından kopyalanmamasının nedeni, Erlang’daki behavior fonksiyon imzalarının, özellikle değişmezlik olmak üzere Erlang’ın diğer özellikleriyle sıkı sıkıya bağlı olması

  • Diğer dillerde aynı hedefe ulaşmak için Erlang’ın yaklaşımı birebir kopyalanmamalı. Erlang’dan güvenilir yazılım hakkında ders çıkarmayı öneririm, ancak Erlang’ın yöntemlerini başka dillere doğrudan taşımaya kesinlikle karşıyım

• Bu yazının söylediklerine katılmıyorum. Behavior’lar, sistemin temel mimarisi sayesinde mümkün oluyor. Behavior’lar bir arayüz değil; daha çok Java gibi dillerdeki soyut nesnelere benziyor

  • Joe’nun makalesi, verilen bir Lego blok setiyle güvenilir sistemlerin nasıl kurulacağını gösteriyor

• Behavior’lar o kadar da ilginç değil. Başka programlama dillerinde de var. BEAM’i ilginç kılan şey, hata fırlatmanın son derece zarif olması. Hata fırlatma ve behavior’ların gücü, hataları yakalamayı, bağlam bilgisini raporlamayı kolaylaştırıyor ve genel olarak bunları birleştirilebilir hale getiriyor