Alasan Saya Menulis Buku tentang BEAM (Erlang VM)

• Berdasarkan pengalaman langsung saat memelihara sistem inti Klarna, jeda BEAM selama 15 milidetik memicu gangguan pembayaran berskala besar dan respons darurat
• Dengan tujuan membuat referensi yang dapat diandalkan tentang BEAM, buku ini ditulis selama 10 tahun
• Selama proses penulisan, penulis mengalami frustrasi dan mencoba lagi berulang kali, termasuk berganti penerbit, masalah teknis, dan beberapa kali perubahan struktur
• Setelah dijadikan open source, umpan balik komunitas dan partisipasi, bertambahnya bintang, serta dorongan dari orang lain menjadi sumber motivasi yang berkelanjutan
• Inti pembahasannya berfokus pada struktur dan operasional BEAM VM, dengan susunan yang benar-benar membantu engineer praktis

---

Motivasi menulis buku BEAM

Post-mortem, kopi, dan kegigihan selama 10 tahun

• Saat mengoperasikan sistem pembayaran inti di Klarna, penulis berulang kali mengalami situasi ketika jeda BEAM hanya 15 milidetik berujung pada jutaan kegagalan pembayaran, rapat darurat dini hari, hingga CEO ikut dipanggil
• Penulis selalu merasa kurang karena tidak adanya materi yang bisa dipakai untuk menyelesaikan krisis semacam itu dengan cepat, dan menulis The BEAM Book dengan harapan engineer berikutnya dapat menyelesaikan masalah lebih cepat

Proses penulisan awal

Awal dan frustrasi

• Pada Oktober 2012, proyek dimulai dengan satu file DocBook dan ambisi besar
• Commit selama 2 minggu sebagian besar berfokus pada pekerjaan struktur dan pembaruan metadata, dengan isi nyata yang sangat sedikit
• Pada November, penulis beralih ke AsciiDoc dan custom build script serta berharap selesai dalam 6 bulan, tetapi kemajuan sangat lambat karena penulisan ulang dan perubahan struktur yang terus berulang

Kolaborasi dengan penerbit

• Setelah menandatangani kontrak penerbitan dengan O’Reilly pada 2013, proyek dimigrasikan ke Atlassian Atlas, tetapi masalah kehilangan file dan pengelolaan bab terus terjadi
• Riwayat Git dipenuhi keluhan dan revisi struktur yang tidak ada habisnya
• Pada Maret 2015, penulis mencoba langkah darurat seperti memisahkan konten secara paksa per bab hanya agar build bisa lolos
• Dua bulan kemudian, kontrak dihentikan secara diam-diam, memunculkan rasa hancur sekaligus lega pada saat yang sama
• Upaya kedua bersama Pragmatic Bookshelf juga terhenti di tengah progres yang lambat

Reset dan partisipasi komunitas

• Pada Januari 2017, seluruh proyek dipindahkan ke repositori baru melalui massive commit (6622 file, 1 juta baris), tetapi penulisan ulang kembali mandek
• Pada Maret 2017, penulis memulai lagi dari repositori GitHub privat berbasis Asciidoctor, hanya menyalin bagian yang diperlukan
• Dua minggu kemudian, repositori dibuka untuk publik dan kontributor eksternal segera aktif memperbaiki typo, menambahkan diagram, serta membantu lisensi

Faktor yang menjaga motivasi

• Pada dasarnya, rasa ingin tahu pribadi dan keinginan untuk memahami cara kerja BEAM yang sebenarnya menjadi pendorong terbesar
• Umpan balik dan saran dari komunitas memperkuat tekad untuk terus menulis, dan jumlah bintang di GitHub memberi efek motivasi yang berkelanjutan
• Issue berisi dukungan seperti “Please continue being awesome” juga berperan besar sebagai penopang psikologis
• Buku ini makin sering dirujuk dalam forum akademik dan konferensi terkait Erlang dan BEAM, yang membuktikan kebutuhannya
• Penyebutan dan pembagian berkelanjutan di Twitter dan tempat lain juga mendorong penulis untuk terus melanjutkan

Struktur buku dan target pembaca utama

• Isinya berfokus pada hal-hal yang benar-benar dibutuhkan saat merancang dan mengoperasikan sistem Erlang berskala besar
  • Scheduler dan manajemen proses: penjadwalan proses di bawah beban nyata, prioritas, dan prinsip balancing
  • Memori proses: heap, stack, pesan, cara pengelolaan biner, dan dampaknya terhadap operasional
  • Garbage collection dan model memori: cara kerja GC per proses/global, kebocoran memori, dan struktur referensi
  • Sistem representasi data: struktur tagging internal untuk integer, float, tuple, binary, dan data lain
  • Compiler dan struktur internal VM: alur eksekusi instruksi yang sebenarnya di VM setelah kompilasi
  • Tracing dan debugging: dbg, erlang:trace, pelacakan pesan dan event, dan lain-lain
  • Performance tuning: profiling kode nyata, analisis penyebab latensi, dan cara memahami reduction
  • Arsitektur sistem: prinsip kerja terintegrasi dari ERTS, BEAM VM, dan subsistemnya
• Buku ini memberi dampak yang sangat praktis bagi operator Erlang/Elixir di dunia kerja, dengan tujuan utama menjadi panduan komprehensif yang tepercaya sebagai pengganti materi yang tercerai-berai

Pelajaran dari proses penulisan

• Ketekunan mengalahkan perfeksionisme. Bahkan setelah dua kali pembatalan penerbitan, kesimpulannya tetap bahwa hasil yang belum sempurna lebih baik daripada tidak selesai
• Fokus dan penetapan batas itu penting. Menyediakan waktu khusus untuk menulis, mematikan notifikasi, dan manajemen waktu yang ketat menjadi sumber kemajuan nyata
• Keterbukaan dan umpan balik adalah inti peningkatan kualitas. Koreksi dari luar, dukungan, dan dorongan yang konsisten sangat membantu
• Manajemen scope adalah keharusan. Dengan menyesuaikan ruang lingkup, topik yang lebih sulit seperti Dirty Scheduler dan JIT dipindahkan ke lampiran di masa depan
• Strategi perbaikan berulang setelah rilis itu penting. BEAM berubah setiap tahun, dan sebagai repositori Git yang hidup, buku ini bisa terus disempurnakan
• Menetapkan deadline yang nyata adalah motivasi paling efektif. Tenggat untuk dicetak sebelum acara Code Beam Stockholm memaksa penulis memilih isi yang benar-benar esensial

Definisi selesai

• Saat benar-benar memegang edisi cetak di tangan, penulis akhirnya bisa merasakan arti “selesai”
• Commit yang sebelumnya tersebar kini terikat menjadi satu buku yang utuh, sehingga untuk saat ini penulis menyatakan proyek ini selesai

Cara berpartisipasi

• The BEAM Book 1.0 saat ini dapat dibeli dalam versi cetak di Amazon
  • Tautan Amazon
• Jika menemukan typo atau hal yang bisa ditingkatkan, atau ingin memahami struktur internalnya, Anda bisa menggunakan star, fork, membuat issue, dan pull request di repositori GitHub
  • Nama asli kontributor akan disebutkan dalam bagian ucapan terima kasih
  • GitHub: theBeamBook
• Karena ulasan pengguna lebih berpengaruh pada algoritme, pembaca juga sangat didorong untuk meninggalkan review
• Workshop BEAM internals yang berfokus pada sistem nyata juga dapat diadakan; untuk pertanyaan, silakan kirim email ke [e-mail]

[GN⁺]

Komentar Hacker News

• Repositori git bisa dilihat di sini

• Motivasi penulis yang terus menggali karena ingin benar-benar memahami BEAM sangat berkesan. Menurut saya, gairah seperti inilah yang menghasilkan karya hebat. Karena itu saya langsung memutuskan untuk membeli. Dari pengalaman saya sendiri, saya beberapa kali mendapat tawaran menulis buku dari penerbit, tetapi tidak pernah jadi karena arah yang diinginkan berbeda. Misalnya, saya tidak ingin menulis buku pengantar Java untuk anak usia 14 tahun, sementara penerbit tidak tertarik pada topik yang saya dalami secara mendalam (misalnya classloader). Saya penasaran bagaimana orang lain menemukan irisan antara gairah pribadi dan kebutuhan pembaca

  • Dari pengalaman menulis tiga buku, pilihannya biasanya hanya dua: menerbitkan sendiri atau menulis buku yang diinginkan penerbit. Setiap penerbit punya karakter buku yang dikejar, dan banyak yang fokus pada buku praktis untuk pemula, jadi kalau ingin menulis topik yang tidak terlalu populer, secara realistis lebih baik menyiapkan self-publishing. Untungnya, sekarang self-publishing makin mudah dan penjualan online juga memungkinkan. Artinya, kalau topiknya benar-benar membidik pasar yang sangat niche, jangan berharap pada penerbit dan bersiaplah menangani penerbitan serta promosi sendiri
  • Kalau Anda membawakan sesuatu yang benar-benar menarik, pada akhirnya pembaca akan mencari cara untuk memahaminya. Di awal karier saya, saya membaca “Essential .Net” karya Don Box, dan rasanya dia juga tidak menargetkan segmen pembaca tertentu. Itu murni buku yang menggali bagian dalam CLR secara mendalam, dan untuk benar-benar memahaminya pada awalnya saya harus membacanya berkali-kali
  • Saya sedang memikirkan apakah memang harus bergantung pada penerbit, atau boleh saja menulis buku secara mandiri. Saya penasaran apakah alasannya nama penerbit atau manfaat tambahannya
  • Saya setuju bahwa mengajar adalah cara belajar terbaik. Saya merasakannya saat menjadi tutor matematika di SMA, dan pengalaman menulis buku pun mirip. Ini adalah cara terbaik untuk melampaui sekadar paham dan benar-benar menjadikan hal-hal mendasar itu milik kita sendiri
  • Sedikit terdengar seperti pamer, tapi saya juga akhirnya menulis buku latihan kekuatan untuk panjat tebing dengan cara mendalaminya seperti ini. Awalnya saya ingin self-publishing, tetapi pada akhirnya saya mencari penerbit dan merevisinya agar sedikit lebih mudah dibaca. Mencoba mendekati penerbit secara langsung juga bisa jadi salah satu cara

• Pengalaman saya dengan BEAM dan Erlang/OTP adalah salah satu pengalaman pengembangan terbaik dalam setahun terakhir. Saya memakai buku Joe Armstrong “Programming Erlang: Software for a Concurrent World”, dan sangat ingin merekomendasikannya untuk pemula. “Designing for Scalability with Erlang/OTP” juga mendapat ulasan bagus, tetapi saya belum sempat memulainya. Namun dari sisi kedalaman, buku kali ini jelas jauh lebih unggul. BEAM benar-benar terasa seperti teknologi alien yang ditinggalkan peradaban kuno. Buku itu terbit di waktu yang tepat, jadi saya langsung membelinya. Saya kagum pada Dr. Erik Stenman yang tetap menyelesaikan buku ini bahkan setelah penerbitannya dibatalkan dua kali

  • Saya penasaran perangkat lunak seperti apa yang Anda kembangkan dengan BEAM/Erlang/OTP

• Elixir dan BEAM adalah pilihan favorit saya untuk membangun sistem yang berbasis jaringan atau memiliki banyak pipeline. Saya menggunakannya setiap hari di production selama beberapa tahun, dan walau pada proyek-proyek terbaru pilihannya tidak selalu mudah, saya tetap rutin mengikuti perkembangannya. Terima kasih atas terbitnya buku ini. Ini adalah buku yang sangat saya harapkan beberapa tahun lalu saat melakukan debugging di Elixir production. Materi yang ada sebelumnya terasa terlalu sulit atau sebaliknya terlalu dangkal

• Informasi tentang BEAM (Erlang virtual machine) bisa dilihat di tautan Wikipedia

  • Judul bukunya sendiri sudah menjelaskannya dengan baik

• Saya rasa BEAM adalah salah satu teknologi paling diremehkan di dunia open source. Contohnya ada WhatsApp. Masih jadi misteri bagi saya mengapa Elixir dan Erlang tidak lebih populer untuk proyek dengan konkurensi tinggi

  • Tempat kerja saya adalah perusahaan spesialis Erlang. Nilai sesungguhnya Erlang muncul pada lalu lintas berskala besar, seperti jutaan DAU. Anda bisa menjalankan situs web dengan ribuan DAU memakai Elixir, tetapi esensi Erlang dan BEAM ada pada skala seperti itu. Tidak banyak perusahaan yang membutuhkan skala sebesar ini, dan masalah yang lebih besar adalah ekosistem Erlang sendiri beroperasi hampir seperti OS terpisah, sehingga penyiapan lingkungan dan komponennya cukup kompleks. Teknologi infrastruktur lain seperti container atau k8s juga tidak terlalu dibutuhkan, dan justru pendekatan khas Erlang membuatnya terasa asing. Kalau Anda mengalami Erlang dalam situasi yang benar-benar pas, rasanya seperti sihir. Itu adalah salah satu puncak karier saya
  • Pada akhirnya saya rasa ini pengaruh pemasaran. Java, C#, dan Go didukung sponsor korporat yang sangat kuat, sementara Erlang justru sering tertahan oleh perusahaan atau nyaris tidak mendapat perhatian selain dokumentasi teknis. Elixir adalah yang pertama mengikuti pemasaran ala bahasa lain (model Ruby), tetapi waktu masuk dan konteksnya berbeda. Para pengembang mungkin bisa memahami keunggulan BEAM, tetapi tampaknya sulit menarik para pengambil keputusan di luar itu
  • Menurut saya perbedaan investasinya besar. Rust, Go, Python, dan lainnya mendapat banyak investasi berkat dukungan perusahaan dalam hal analisis statis, pemeriksaan tipe, pengalaman pengembang, dan sebagainya. Sementara di sisi Erlang, hal-hal seperti ini tidak cukup banyak mendapat perhatian, dan para pengguna besar pun sedikit demi sedikit membangun solusi sendiri di luar BEAM atau beralih ke tempat lain
  • Kami baru-baru ini mengubah situs web Squarespace menjadi aplikasi Phoenix, dan itu pengalaman yang benar-benar menyenangkan
  • Pada saat yang sama, ini juga ‘secret sauce’ yang paling tidak rahasia. Baru-baru ini BBC juga beralih ke Elixir, jadi rasanya popularitasnya memang sedang meningkat

• Saya suka penjelasan bahwa “Erlang Runtime System(ERS)” mengacu pada runtime Erlang secara umum, sedangkan “Erlang RunTime System(ERTS)” adalah istilah yang terbatas pada implementasi Ericsson

  • Menurut saya definisi itu tidak bodoh

• Saya langsung membeli bukunya. Memang bisa dibaca gratis secara online, tetapi saya tetap ingin sedikit mendukung penulisnya dengan membeli

• Saya tidak mengerjakan sistem berskala besar seperti Klarna, jadi sulit membayangkan bahwa delay 15ms bisa menjadi isu postmortem

  • Di BEAM, respons dalam satuan mikrodetik (μs) itu hal yang umum, jadi kalau melonjak ke milidetik (ms), alarm bisa langsung berbunyi
  • Di sistem BEAM, situasi seperti ini sangat mungkin terjadi. Jika Anda membuat gen_server untuk melindungi shared state, konsepnya mirip mutex raksasa. Kalau gen_server membutuhkan 20us untuk memproses satu permintaan, maka delay 15ms berarti ada 750 pesan menumpuk di message queue. Jika message queue itu kemudian digunakan dengan pola yang tidak efisien, performanya bisa turun drastis. BEAM hanya mengoptimalkan message queue untuk pola-pola tertentu, sedangkan pada pola lain waktu pemrosesan meningkat seiring panjang queue. Jika ada receive yang tidak aman dipakai di dalam library, penurunan performa yang tak terduga bisa muncul. Baru-baru ini BEAM menambahkan fitur alias untuk membantu masalah message queue, tetapi banyak library belum memakainya. Tujuan alias adalah mencegah kehilangan pesan, dan juga mencegah queue tercemari oleh pesan timeout. Biasanya proses yang berumur panjang akan memproses queue dalam loop
  • Kalau ada yang tahu tautan postmortem dari insiden yang disebut itu, saya penasaran. Saya tidak menemukannya secara online

• Saya penasaran apakah ada VM yang mirip dengan BEAM. Apakah memang BEAM sedemikian unggul sampai tidak punya pesaing, atau memang sesulit itu untuk dibuat

  • Saya melihat fungsi yang disediakan infrastruktur Kubernetes modern cukup mirip dengan BEAM. Sekarang orang membangun sistem self-healing skala besar dengan infrastruktur seperti ini, tanpa terikat bahasa tertentu. Di luar Erlang/Elixir juga ada beragam ekosistem, talenta, dan minat
  • Ada juga implementasi terpisah bernama AtomVM untuk perangkat yang terbatas seperti IoT. Banyak upaya mencoba mengimplementasikan BEAM atau OTP di ekosistem lain, tetapi kebanyakan tidak sampai pada level VM
  • Pada akhir 1990-an dan awal 2000-an, BEAM memang cukup unik. Sekarang, meski implementasinya berbeda, banyak bahasa dan alat bisa menyelesaikan masalah yang sama dengan baik. Ada juga sikap khas komunitas Erlang bahwa “hanya cara BEAM yang benar”, tetapi pada 2025 sebenarnya ada banyak sekali opsi. Implementasi yang kompatibel dengan BEAM memang ada, tetapi kebanyakan berada di area niche. Jika Anda tidak perlu bergabung dengan infrastruktur BEAM yang sudah ada, menurut saya solusi modern dari ekosistem masa kini lebih cocok untuk proyek greenfield. Ada juga proyek kecil seperti ergo
  • Dis VM mungkin yang paling mirip, lalu Smalltalk VM. Sebenarnya bukan hanya BEAM itu sendiri, melainkan OTP yang membuat BEAM benar-benar menunjukkan keunggulannya
  • Dalam penggunaan nyata, yang paling mirip mungkin Go. BEAM adalah ekosistem yang disesuaikan untuk “bahasa keluarga Erlang”, jadi perilaku inti Elixir atau Gleam juga mirip dengan Erlang. Go menyediakan primitive ala Erlang untuk konkurensi seperti goroutine, tetapi tidak punya pandangan yang sejelas OTP soal bagaimana struktur aplikasi seharusnya dibangun