BEAM (Erlang VM) kitabını neden yazdım

 (happihacking.com)
3 puan yazan GN⁺ 2025-06-05 | 1 yorum | WhatsApp'ta paylaş
  • Klarna'nın çekirdek sistemlerini ayakta tutarken edinilen gerçek saha deneyimlerinde, BEAM'deki 15 milisaniyelik bir duraklama büyük çaplı ödeme arızalarına ve acil müdahalelere yol açtı
  • BEAM için güvenilir bir referans oluşturmak amacıyla kitap 10 yıla yayılan bir süreçte yazıldı
  • Yazım sürecinde yayınevi değişikliği, teknik sorunlar ve defalarca yapılan yapı değişiklikleri gibi tekrar eden hayal kırıklıkları ve yeniden denemeler yaşandı
  • Açık kaynak hâline geldikten sonra topluluk geri bildirimi ve katılımı, artan yıldız sayısı ve teşvik mesajları sürekli bir motivasyon kaynağı oldu
  • Ana içerik BEAM VM'in yapısı ve işleyişi üzerine odaklanıyor; pratikte çalışan mühendisler için somut fayda sağlayacak şekilde kurgulandı

BEAM kitabını yazma motivasyonu

Post-mortem'ler, kahve ve 10 yıllık inat

  • Klarna'da çekirdek ödeme sistemlerini işletirken, BEAM'in yalnızca 15 milisaniyelik bir durması yüz milyonlarca ödemenin başarısız olmasına, gece yarısı acil toplantılara ve hatta CEO'nun devreye girmesine kadar uzanan durumları defalarca yaşadı
  • Böyle krizleri hızla çözmeye yardımcı olacak kaynakların eksikliği her zaman hissediliyordu; bir sonraki mühendisin sorunu daha hızlı çözebilmesi umuduyla The BEAM Book yazıldı

İlk yazım süreci

Başlangıç ve hayal kırıklığı

  • Ekim 2012'de proje, tek bir DocBook dosyası ve büyük hedeflerle başladı
  • İki haftalık commit'lerin çoğu yapı çalışmaları ve metadata güncellemelerine odaklandı; gerçek içerik ise çok azdı
  • Kasım ayında AsciiDoc ve özel build script'lerine geçildi ve 6 ay içinde tamamlanması beklendi, ancak süregelen yeniden yazımlar ve yapı değişiklikleri nedeniyle ilerleme çok yavaştı

Yayıneviyle iş birliği

  • 2013'te O’Reilly ile yayın sözleşmesi imzalandıktan sonra Atlassian Atlas'a geçildi, ancak dosya kaybı ve bölüm yönetimi sorunları sürüp gitti
  • Git geçmişi, memnuniyetsizlik ve yapı düzeltmeleriyle dolu bir sürecin izlerini taşıyor
  • Mart 2015'te, yalnızca build'in geçmesini sağlamak amacıyla bölümleri zorla chapter bazında ayırmak gibi geçici çözümler denendi
  • İki ay sonra sözleşme sessizce sonlandırıldı; bu durum aynı anda hem yıkım hissi hem de rahatlama getirdi
  • Pragmatic Bookshelf ile yapılan ikinci deneme de yavaş ilerleme nedeniyle yarım kaldı

Sıfırlama ve topluluk katılımı

  • Ocak 2017'de yeni bir repository'ye massive commit ile tam taşıma yapıldı (6622 dosya, 1 milyon satır), ancak yeniden yazım yine tıkandı
  • Mart 2017'de Asciidoctor tabanlı özel bir GitHub repository üzerinde yeniden başlandı; yalnızca gerekli kısımlar kopyalandı
  • İki hafta sonra repository herkese açıldı ve aynı anda dış katkıcıların yazım hatası düzeltmeleri, diyagram eklemeleri ve lisans konusundaki katkıları hızla gelmeye başladı

Sürekli motivasyon kaynakları

  • En büyük itici güç, özünde BEAM'in gerçekte nasıl çalıştığını anlama yönündeki kişisel merak ve istek oldu
  • Topluluktan gelen geri bildirim ve öneriler yazma isteğini artırdı; GitHub'daki artan yıldız sayısı da sürekli bir motivasyon etkisi yarattı
  • “Please continue being awesome” gibi örneklerde görüldüğü üzere, teşvik içeren issue'lar psikolojik destek açısından da önemli bir rol oynadı
  • Erlang ve BEAM ile ilgili akademik etkinlikler ve konferanslarda kitabın giderek daha sık alıntılanması, böyle bir kaynağa ihtiyaç olduğunu gösterdi
  • Twitter gibi platformlardaki sürekli anılmalar ve paylaşımlar da yazımın sürmesini teşvik etti

Kitabın yapısı ve hedef okur kitlesi

  • İçerik, doğrudan büyük ölçekli Erlang sistemlerini tasarlayıp işletirken gerçekten ihtiyaç duyulan başlıklara odaklanıyor
    • Scheduler ve process yönetimi: gerçek yük altında process scheduling, öncelikler ve dengeleme ilkeleri
    • Process belleği: heap, stack, message ve binary yönetiminin biçimi ve bunun operasyonel etkileri
    • Garbage collection ve bellek modeli: process bazlı / global GC'nin çalışma şekli, bellek sızıntıları ve referans yapıları
    • Veri gösterim sistemi: integer, float, tuple, binary gibi verilerin iç etiketleme yapısı
    • Compiler ve VM iç yapısı: derlemeden sonra VM içinde komutların gerçekte nasıl yürütüldüğü
    • Tracing ve debugging: dbg, erlang:trace, message ve event izleme gibi konular
    • Performans ayarı: gerçek kod profil çıkarma, gecikme nedenlerini analiz etme, reduction kavramını anlama
    • Sistem mimarisi: ERTS, BEAM VM ve alt sistemlerin birlikte nasıl çalıştığı
  • Erlang/Elixir'i üretimde kullanan profesyoneller için çok somut bir etki yaratmayı hedefliyor; dağınık kaynakların yerine güvenilir ve kapsamlı bir rehber sunmak temel amaç

Yazım sürecinden çıkarılan dersler

  • Sebat, mükemmeliyetçiliği yener. İki kez yayın iptali yaşansa da sonuçta “bitmemiş” bırakmaktan daha iyi olduğu sonucuna varıldı
  • Odaklanma ve sınır koyma önemlidir. Yazı için zaman ayırma, bildirimleri kapatma ve sıkı zaman yönetimi gerçek ilerlemenin kaynağı oldu
  • Açıklık ve geri bildirim, kalite artışının anahtarıdır. Dışarıdan gelen düzeltmeler, teşvik ve düzenli uyarılar büyük yardım sağladı
  • Kapsam yönetimi zorunludur. Kapsam daraltılarak Dirty Scheduler, JIT gibi zor konular daha sonraki eklere bırakıldı
  • Yayın sonrası yinelemeli iyileştirme stratejisi önemlidir. BEAM her yıl değişiyor ve yaşayan bir Git repository'si olarak sürekli geliştirilebilir
  • Gerçek bir son tarih somut motivasyon sağlar. Code Beam Stockholm etkinliğinden önce basılmış olma hedefi, gerçekten gerekli içeriğin seçilmesini sağladı

Tamamlanmış olmanın tanımı

  • Gerçek basılı kopyayı eline aldığı anda sonunda bunun “tamamlandığı” hissine ulaşabildi
  • Dağınık commit'ler tek bir fiziksel kitapta birleştiği için, en azından şimdilik bunun son olduğu ilan ediliyor

Katılım yolları

  • The BEAM Book 1.0 şu anda Amazon üzerinden basılı kitap olarak satın alınabiliyor
  • Yazım hataları ya da iyileştirme fırsatları fark edilirse veya iç yapılar merak ediliyorsa, GitHub repository'sinde star, fork, issue açma ve pull request kullanılabilir
  • Gerçek kullanıcı yorumları algoritma üzerinde daha etkili olduğu için, inceleme yazılması da özellikle rica ediliyor
  • Gerçek sistemler odaklı BEAM internals workshop da düzenlenebiliyor; iletişim için happi@happihacking.com adresine e-posta gönderilmesi isteniyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-05
Hacker News görüşleri

  • git deposuna buradan bakılabilir

  • Yazarın, BEAM’i gerçekten anlamak istediği için konuyu kazımaya devam etme motivasyonu etkileyici. Bence böyle bir tutku harika işler ortaya çıkarıyor. Bu yüzden hemen satın almaya karar verdim. Kendi deneyimimden söyleyeyim: yayınevlerinden birkaç kez kitap yazma teklifi aldım ama istediklerimiz farklı olduğu için hiçbiri gerçekleşmedi. Örneğin ben 14 yaşındakilere yönelik bir Java başlangıç kitabı yazmak istemedim, yayınevi de benim derinlemesine ele almak istediğim konularla (ör. classloader) ilgilenmedi. Kişisel tutkuyla okur ihtiyacının kesiştiği alanı başkaları nasıl buluyor merak ediyorum

    • Üç kitap yazmış biri olarak söyleyebilirim ki ya kendi kendine yayımlarsın ya da yayınevinin istediği kitabı yazarsın. Her yayınevinin peşinde olduğu kitap türü farklı ve birçoğu başlangıç seviyesindeki pratik kitaplara odaklanıyor; bu yüzden popüler olmayan bir konuda yazmak istiyorsan kendi kendine yayımlanmaya hazırlanmak en gerçekçi seçenek. Neyse ki bugünlerde bunu yapmak kolaylaştı ve çevrimiçi satmak da mümkün. Yani çok niş bir pazara hitap eden bir konuda yazacaksan, yayınevinden medet ummak yerine yayımlama ve tanıtımı kendin üstlenmen gerektiği gerçeği var
    • Eğer gerçekten ilginç bir şey anlatıyorsan, okurlar eninde sonunda onu anlamanın yolunu bulur. Kariyerimin başlarında Don Box’ın “Essential .Net” kitabını okumuştum; o da belirli bir okur kitlesini hedefliyormuş gibi gelmiyordu. Sadece CLR’ın içini derinlemesine eşeleyen bir kitaptı ve ilk başta tam anlamak için birkaç kez okumak gerekiyordu
    • Acaba gerçekten bir yayınevine bağımlı olmak zorunda mıyım, yoksa kitabı bağımsız şekilde kendim de yazabilir miyim diye düşünüyorum. Bunun sebebi yayınevinin adı mı yoksa başka ek faydalar mı, merak ediyorum
    • Öğretmenin en iyi öğrenme yöntemlerinden biri olduğuna katılıyorum. Bunu lisede matematik özel dersi verirken öğrendim, kitap yazma deneyimi de benzer. Basitçe anlamanın ötesine geçip temeli gerçekten içselleştirmenin en iyi yolu bu
    • Biraz övünmek gibi olacak ama ben de tırmanış için kuvvet antrenmanı üzerine bir kitabı böyle derinlemesine çalışırken yazdım. Aslında kendi kendime yayımlamayı planlıyordum ama sonunda bir yayınevi buldum ve kitabı biraz daha okunur hale getirecek şekilde düzenledim. Yayınevlerine doğrudan ulaşmak da bir yöntem olabilir

  • BEAM ve Erlang/OTP ile çalışmak, son 1 yıldaki en iyi geliştirme deneyimlerimden biriydi. Joe Armstrong’un “Programming Erlang: Software for a Concurrent World” kitabını kullandım ve yeni başlayanlara güçlü biçimde tavsiye ederim. “Designing for Scalability with Erlang/OTP” da iyi yorumlar alıyor ama daha başlayamadım. Ama derinlik açısından bu yeni kitap açık ara önde. BEAM gerçekten kadim bir uygarlığın bıraktığı uzaylı teknolojisi gibi. Kitabın tam zamanında çıkması güzel oldu, ben de hemen aldım. İki kez yayını iptal edilmiş olmasına rağmen kitabı tamamladığı için Dr. Erik Stenman’a hayran kaldım

    • BEAM/Erlang/OTP ile ne tür yazılımlar geliştirdiğini merak ettim

  • Elixir ve BEAM, ağ tabanlı ya da yoğun pipeline içeren sistemler kurmak için en sevdiğim seçenek. Yıllarca prodüksiyonda her gün kullandım; son projelerimde seçim yapmak artık o kadar kolay değil ama gelişmeleri düzenli takip ediyorum. Bu kitabın çıkmasına minnettarım. Birkaç yıl önce prodüksiyondaki Elixir sistemlerinde debug yaparken tam da böyle bir kitaba ihtiyaç duymuştum. Mevcut kaynaklar ya fazla zor ya da tersine fazla yüzeyseldi

  • BEAM (Erlang virtual machine) hakkında bilgiye Wikipedia bağlantısından ulaşılabilir

    • Kitabın başlığı zaten bunu gayet iyi açıklıyor

  • Bence BEAM, açık kaynak dünyasının en az değer verilen teknolojilerinden biri. Örnek olarak whatsapp var. Elixir ve Erlang’ın yüksek eşzamanlılık gerektiren projelerde neden daha popüler olmadığını anlamak zor

    • Benim iş yerim Erlang uzmanı bir şirket. Erlang’ın asıl değeri, milyonlarca DAU gibi çok büyük trafikte ortaya çıkıyor. Elixir ile birkaç bin DAU’luk bir web sitesi çalıştırabilirsin ama Erlang ve BEAM’in özü o ölçekte yatıyor. Bu ölçeğe gerçekten ihtiyaç duyan şirket sayısı fazla değil; daha büyük sorun ise Erlang ekosisteminin adeta ayrı bir işletim sistemi gibi çalışması, dolayısıyla ortam kurulumu ve bileşenlerinin oldukça karmaşık olması. Container ya da k8s gibi başka altyapı teknolojilerine de ihtiyaç duymuyor, hatta Erlang’ın kendine özgü yaklaşımı yüzünden alışılmadık hissettiriyor. Ama tam uygun durumda Erlang’ı deneyimlersen, resmen sihir gibi geliyor. Kariyerimin en parlak anlarından biri oldu
    • Sonuçta bunun pazarlama etkisi olduğunu düşünüyorum. Java, C#, Go güçlü kurumsal destekle geliyor ama Erlang’da şirketler ya ayak bağı oluyor ya da teknik dokümantasyon dışında pek ilgi göstermiyor. Elixir, ilk kez başka dillerdeki pazarlama yaklaşımını (Ruby modeli) takip etti ama ortaya çıkış zamanı ve koşulları farklıydı. Geliştiriciler BEAM’in üstünlüğünü anlayabilir ama onun dışındaki karar vericilere bunu anlatmak pek mümkün olmuyor gibi
    • Bence asıl fark yatırımda. Rust, Go, Python gibi diller; statik analiz, tip denetimi, geliştirici deneyimi gibi alanlarda kurumsal destek sayesinde büyük yatırımlar aldı. Erlang tarafı ise bu sevgiyi yeterince görmedi ve büyük kullanıcılar da zamanla doğrudan BEAM dışında çözümler üretmeye ya da göç etmeye başladı
    • Kısa süre önce Squarespace web sitemizi bir Phoenix uygulamasına dönüştürdük ve gerçekten çok keyifliydi
    • Aynı zamanda en az gizli olan ‘gizli sos’ gibi. Yakın zamanda BBC de Elixir’ye geçti, o yüzden popülerliğinin yavaş yavaş arttığını hissediyorum

  • “Erlang Runtime System(ERS)”ın genel Erlang çalışma zamanını, “Erlang RunTime System(ERTS)”ın ise Ericsson uygulamasına özgü ifadeyi anlatması güzel bir açıklama

    • Bence bu tanım saçma değil

  • Kitabı hemen satın aldım. İnternetten ücretsiz okunabiliyor ama yazarı biraz da olsa desteklemek istedim, o yüzden aldım

  • Klarna gibi çok büyük sistemlerde çalışmadığım için hissetmesi zor ama 15ms gecikmenin postmortem konusu olması ilginç

    • BEAM’de mikro saniye (μs) düzeyinde yanıtlar olağan sayıldığı için, iş milisaniye (ms) seviyesine sıçrarsa alarm çalabilir
    • BEAM sistemlerinde böyle bir şey rahatlıkla yaşanabilir. Paylaşılan durumu korumak için bir gen_server oluşturursan, bu devasa bir mutex gibi davranır. gen_server’ın bir isteği işlemesi 20us sürüyorsa, 15ms gecikme mesaj kuyruğunda 750 mesaj birikmesi demektir. Bir de mesaj kuyruğunu verimsiz kalıplarla kullanıyorsan performans sert düşer. BEAM yalnızca belirli kalıplarda mesaj kuyruğu optimizasyonu yapar; diğerlerinde işlem süresi kuyruk uzunluğuyla birlikte artar. Kütüphane içinde güvenli olmayan bir receive kullanılırsa beklenmedik performans düşüşleri oluşabilir. Son dönemde BEAM, mesaj kuyruğu sorunlarını hafifletmek için alias özelliğini ekledi ama birçok kütüphane hâlâ bunu kullanmıyor. alias mesaj kaybını önlemeyi amaçlıyor ve zaman aşımı mesajlarının kuyruğu kirletmesini engelliyor. Genelde uzun ömürlü süreçler kuyruğu bir döngü içinde işleyerek çalışır
    • Bahsedilen olayın postmortem bağlantısını bilen varsa merak ediyorum. İnternette bulamadım

  • BEAM’e benzer başka VM’ler olup olmadığını merak ediyorum. Acaba BEAM o kadar iyi ki rakibi yok mu, yoksa yapmak bu kadar zor olduğu için mi benzeri az, bunu bilmek isterdim

    • Modern Kubernetes altyapısının sağladığı işlevlerin BEAM’e benzediğini düşünüyorum. Bugün bu tür altyapılarla büyük ölçekli self-healing sistemler kurabiliyorsun ve dil kısıtı da yok. Erlang/Elixir dışında da farklı ekosistemler, insan kaynağı ve ilgi alanları mevcut
    • IoT gibi kısıtlı cihazlar için ayrı bir uygulama olan AtomVM de var. BEAM veya OTP’yi başka ekosistemlerde uygulamaya dönük birçok girişim oldu ama çoğu VM seviyesinde değildi
    • BEAM, 90’ların sonu ile 2000’lerin başında çıktığında oldukça benzersizdi. Bugün ise uygulama biçimleri farklı olsa da aynı sorunlar birçok dil ve araçla gayet iyi çözülebiliyor. Erlang topluluğunda zaman zaman görülen “tek doğru BEAM yaklaşımıdır” tavrı da var ama 2025 itibarıyla gerçekten çok sayıda seçenek bulunuyor. BEAM uyumlu uygulamalar da var ama çoğu niş alanlarda kalıyor. Mevcut BEAM altyapısına katılman gerekmiyorsa, yeni bir projede güncel ekosistemin modern çözümleri daha uygun olabilir diye düşünüyorum. ergo gibi küçük projeler de mevcut
    • Dis VM muhtemelen en benzeri, ardından Smalltalk VM geliyor. Aslında BEAM’in asıl gücü tek başına kendisinden değil, üzerine eklenen OTP ile ortaya çıkıyor
    • Pratik kullanımda en benzeri muhtemelen Go’dur. BEAM, “Erlang tarzı diller” için kurulmuş bir ekosistem; bu yüzden Elixir ya da Gleam de temel çalışma biçimi olarak Erlang’a çok benzer. Go, goroutine gibi yapılarla Erlang benzeri eşzamanlılık primitive’leri sunuyor ama OTP gibi uygulama mimarisine dair net bir bakış açısı yok