เหตุผลที่ผมเขียนหนังสือเกี่ยวกับ BEAM (Erlang VM)

• จากประสบการณ์จริงในการดูแลระบบหลักของ Klarna การหยุดชะงักของ BEAM เพียง 15 มิลลิวินาทีก็สามารถก่อให้เกิดปัญหาการชำระเงินวงกว้างและการรับมือฉุกเฉินได้
• เขาใช้เวลาถึง 10 ปีในการเขียนหนังสือเพื่อ สร้างแหล่งอ้างอิงที่เชื่อถือได้ เกี่ยวกับ BEAM
• ระหว่างการเขียนได้เผชิญกับความท้อแท้และการเริ่มใหม่ซ้ำแล้วซ้ำเล่า ทั้งจาก การเปลี่ยนสำนักพิมพ์ ปัญหาทางเทคนิค และการปรับโครงสร้างหลายครั้ง
• หลังเปิดเป็นโอเพนซอร์ส ฟีดแบ็กจากชุมชน การมีส่วนร่วม จำนวนดาวที่เพิ่มขึ้น และกำลังใจจากผู้อื่น กลายเป็นแรงผลักดันอย่างต่อเนื่อง
• เนื้อหาหลักมุ่งเน้นที่ โครงสร้างและการทำงานของ BEAM VM โดยจัดทำให้เป็นประโยชน์ต่อวิศวกรสายปฏิบัติจริง

---

แรงจูงใจในการเขียนหนังสือ BEAM

Post-mortems, กาแฟ และความมุ่งมั่นตลอด 10 ปี

• ขณะดูแลระบบชำระเงินหลักที่ Klarna เขาเผชิญซ้ำแล้วซ้ำเล่าว่า การหยุดของ BEAM เพียง 15 มิลลิวินาที นำไปสู่การชำระเงินล้มเหลวนับล้านรายการ การประชุมฉุกเฉินกลางดึก และถึงขั้นต้องเรียก CEO เข้ามา
• สิ่งที่น่าเสียดายเสมอคือการขาด ข้อมูลที่ช่วยแก้วิกฤตได้อย่างรวดเร็ว จึงเขียน The BEAM Book ขึ้นด้วยความหวังว่าวิศวกรคนถัดไปจะสามารถแก้ปัญหาได้เร็วยิ่งขึ้น

กระบวนการเขียนในช่วงแรก

การเริ่มต้นและความท้อแท้

• ในเดือนตุลาคม 2012 เขาเริ่มโครงการด้วย ไฟล์ DocBook เพียงไฟล์เดียวและความตั้งใจอันยิ่งใหญ่
• คอมมิตในช่วง 2 สัปดาห์แรกส่วนใหญ่เน้นงานโครงสร้างและการอัปเดตเมทาดาทา โดยมีเนื้อหาจริงน้อยมาก
• ในเดือนพฤศจิกายนได้เปลี่ยนไปใช้ AsciiDoc และ custom build script และคาดว่าจะเสร็จภายใน 6 เดือน แต่ความคืบหน้ากลับช้ามากจากการเขียนใหม่และปรับโครงสร้างอย่างต่อเนื่อง

การทำงานร่วมกับสำนักพิมพ์

• ในปี 2013 เขาเซ็นสัญญาตีพิมพ์กับ O’Reilly และย้ายไปใช้ Atlassian Atlas แต่ก็ยังเจอปัญหาไฟล์หายและการจัดการบทอยู่เรื่อย ๆ
• Git history เต็มไปด้วยร่องรอยของความไม่พอใจและการแก้โครงสร้างอย่างต่อเนื่อง
• เดือนมีนาคม 2015 เขาถึงกับใช้วิธีเฉพาะหน้า เช่น บังคับแยกไฟล์ตามบทเพียงเพื่อให้ build ผ่าน
• สองเดือนต่อมาสัญญาก็ถูกยกเลิกอย่างเงียบ ๆ ทำให้รู้สึกทั้งหมดกำลังใจและโล่งใจในเวลาเดียวกัน
• ความพยายามครั้งที่สองกับ Pragmatic Bookshelf ก็หยุดลงเช่นกันท่ามกลางความคืบหน้าที่ล่าช้า

รีเซ็ตและการมีส่วนร่วมของชุมชน

• ในเดือนมกราคม 2017 มีการย้ายทั้งหมดไปยังรีโพใหม่ด้วย massive commit (6622 ไฟล์, 1 ล้านบรรทัด) แต่การเขียนใหม่ก็ยังชะงักอยู่ดี
• เดือนมีนาคม 2017 เขาเริ่มใหม่อีกครั้งบน GitHub repository แบบ private ที่ใช้ Asciidoctor โดยคัดลอกมาเฉพาะส่วนที่จำเป็น
• สองสัปดาห์ต่อมาเมื่อเปิดเป็นสาธารณะ ก็เกิดการมีส่วนร่วมจากคนนอกอย่างคึกคัก ทั้งการแก้ typo เพิ่มไดอะแกรม และช่วยงานด้านไลเซนส์

ปัจจัยที่ช่วยสร้างแรงจูงใจอย่างต่อเนื่อง

• แรงขับที่ใหญ่ที่สุดโดยเนื้อแท้คือความอยากรู้อยากเข้าใจเป็นการส่วนตัวว่า BEAM ทำงานจริงอย่างไร
• ฟีดแบ็กและข้อเสนอแนะ จากชุมชนช่วยเพิ่มแรงใจในการเขียน และ จำนวนดาวบน GitHub ที่เพิ่มขึ้น ก็มีผลเป็นแรงจูงใจอย่างต่อเนื่อง
• ประเด็นให้กำลังใจอย่าง “Please continue being awesome” แสดงให้เห็นว่า issue ที่เข้ามาให้กำลังใจ มีบทบาทเป็นแรงสนับสนุนทางจิตใจอย่างมาก
• หนังสือถูกอ้างอิงบ่อยขึ้นใน งานวิชาการและคอนเฟอเรนซ์ ที่เกี่ยวกับ Erlang และ BEAM ซึ่งยืนยันถึงความจำเป็นของหนังสือเล่มนี้
• การถูกพูดถึงและแชร์ต่ออย่างต่อเนื่องบน Twitter และแพลตฟอร์มอื่น ๆ ก็ช่วยกระตุ้นให้เขียนต่อไป

โครงสร้างหนังสือและผู้อ่านเป้าหมายหลัก

• เนื้อหาถูกเขียนโดยยึดจากส่วนที่จำเป็นจริงจากประสบการณ์ตรงในการออกแบบและดูแล ระบบ Erlang ขนาดใหญ่
  • ตัวจัดตารางงานและการจัดการโปรเซส: หลักการ scheduling ของโปรเซส ภายใต้โหลดจริง ลำดับความสำคัญ และการบาลานซ์
  • หน่วยความจำของโปรเซส: วิธีจัดการ heap, stack, message, binary และผลกระทบต่อการปฏิบัติงาน
  • Garbage collection และ memory model: วิธีทำงานของ GC ระดับโปรเซส/ระดับรวม รวมถึง memory leak และโครงสร้างการอ้างอิง
  • ระบบการแทนข้อมูล: โครงสร้าง tagging ภายในของข้อมูล เช่น จำนวนเต็ม จำนวนจริง tuple และ binary
  • คอมไพเลอร์และโครงสร้างภายในของ VM: ลำดับการทำงานจริงของคำสั่งภายใน VM หลังการคอมไพล์
  • การ tracing และ debugging: dbg, erlang:trace, การติดตาม message และ event เป็นต้น
  • การปรับแต่งประสิทธิภาพ: การ profiling โค้ดจริง การวิเคราะห์สาเหตุของ latency และวิธีทำความเข้าใจ reduction
  • สถาปัตยกรรมระบบ: หลักการทำงานร่วมกันของ ERTS, BEAM VM และซับซิสเต็มต่าง ๆ
• หนังสือนี้มีผลในทางปฏิบัติอย่างมากต่อ ผู้ดูแลระบบ Erlang/Elixir ในงานจริง และมีเป้าหมายหลักในการเป็นคู่มืออ้างอิงที่เชื่อถือได้แบบครบถ้วนแทนข้อมูลที่กระจัดกระจาย

บทเรียนจากกระบวนการเขียน

• ความพากเพียร เอาชนะความสมบูรณ์แบบได้ ประสบการณ์ที่ถูกยกเลิกการตีพิมพ์ถึงสองครั้งทำให้ได้ข้อสรุปว่าอย่างน้อยการทำให้เสร็จย่อมดีกว่า “ยังไม่เสร็จ”
• การโฟกัสและการตั้งขอบเขต เป็นสิ่งสำคัญ การกันเวลาเขียน การปิดการแจ้งเตือน และการจัดการเวลาอย่างเคร่งครัดคือแหล่งที่มาของความคืบหน้าจริง
• การเปิดเผยงานและรับฟีดแบ็ก คือหัวใจของการยกระดับคุณภาพ การตรวจแก้จากภายนอก กำลังใจ และแรงกระตุ้นอย่างสม่ำเสมอช่วยได้มาก
• การจัดการขอบเขตงาน เป็นสิ่งจำเป็น โดยหัวข้อที่ยากอย่าง Dirty Scheduler และ JIT ถูกเลื่อนไปไว้ในภาคผนวกภายหลัง
• กลยุทธ์ ปล่อยออกมาก่อนแล้วค่อยปรับปรุงซ้ำ มีความสำคัญ เพราะ BEAM เปลี่ยนแปลงทุกปี และการเป็น Git repo ที่มีชีวิตช่วยให้ปรับปรุงต่อเนื่องได้
• การตั้ง เดดไลน์จริง คือแรงขับที่เป็นรูปธรรม เดดไลน์ว่าจะต้องพิมพ์ให้ทันงาน Code Beam Stockholm บังคับให้ต้องคัดเลือกเฉพาะสิ่งที่จำเป็นจริง

นิยามของความสำเร็จ

• ในช่วงที่ได้ ถือหนังสือฉบับพิมพ์จริงอยู่ในมือ เขาจึงรู้สึกได้อย่างแท้จริงว่า “เสร็จสมบูรณ์” แล้ว
• คอมมิตที่กระจัดกระจายได้ถูกรวบรวมเป็นรูปเล่มเดียวที่จับต้องได้ และ ณ ปัจจุบันจึงขอประกาศว่ามันสิ้นสุดลงแล้ว

วิธีมีส่วนร่วม

• The BEAM Book 1.0 สามารถซื้อฉบับปกอ่อนได้แล้วบน Amazon
  • ลิงก์ Amazon
• หากพบ typo หรือจุดที่ควรปรับปรุง หรือหากสนใจโครงสร้างภายใน ก็สามารถใช้ star, fork, issue และ pull request ของ GitHub repo ได้
  • ผู้มีส่วนร่วมจะได้รับการระบุชื่อจริงในคำขอบคุณ
  • GitHub: theBeamBook
• เขายังขอให้ช่วยเขียนรีวิวด้วย เพราะรีวิวจริงมีผลต่ออัลกอริทึมมากกว่า
• นอกจากนี้ยังสามารถจัด เวิร์กช็อป BEAM internals ที่เน้นระบบงานจริงได้ โดยติดต่อทางอีเมลที่ [e-mail]

[GN⁺]

ความคิดเห็นจาก Hacker News

• ดูที่เก็บ git ได้ที่ นี่

• แรงจูงใจของผู้เขียนที่ยังคงขุดลึกลงไปเพราะอยากเข้าใจ BEAM อย่างแท้จริงนั้นน่าประทับใจ คิดว่าความหลงใหลแบบนี้แหละที่สร้างผลงานดีๆ ออกมาได้ เลยตัดสินใจซื้อทันที ถ้าเล่าจากประสบการณ์ของตัวเอง เคยได้รับข้อเสนอให้เขียนหนังสือจากสำนักพิมพ์หลายครั้ง แต่ไม่เคยลงเอยได้เพราะทิศทางที่ต้องการไม่ตรงกัน เช่น ผมไม่อยากเขียนหนังสือ Java เบื้องต้นสำหรับเด็กอายุ 14 ปี ขณะที่สำนักพิมพ์ก็ไม่สนใจหัวข้อที่ผมชอบเจาะลึกจริงๆ (เช่น classloader) เลยสงสัยว่าคนอื่นหาจุดตัดระหว่างความหลงใหลส่วนตัวกับความต้องการของผู้อ่านกันอย่างไร

  • จากประสบการณ์ที่เคยเขียนหนังสือมา 3 เล่ม มันมีอยู่ 2 ทางคือทำ self-publishing หรือไม่ก็เขียนหนังสือตามที่สำนักพิมพ์ต้องการ แต่ละสำนักพิมพ์ก็มีแนวทางของตัวเอง และหลายแห่งเน้นหนังสือเชิงปฏิบัติสำหรับผู้เริ่มต้น ดังนั้นถ้าอยากเขียนหัวข้อที่ไม่แมส ก็ควรเตรียมทำ self-publishing จะสมจริงกว่า โชคดีที่ทุกวันนี้ self-publishing ทำได้ง่ายขึ้นและขายออนไลน์ได้ด้วย กล่าวคือ ถ้าหัวข้อนั้นเจาะตลาดเฉพาะมาก ก็อย่าคาดหวังกับสำนักพิมพ์และต้องรับหน้าที่ตีพิมพ์กับโปรโมตเอง
  • ถ้าคุณเล่าเรื่องที่ตัวเองสนใจจริงๆ สุดท้ายผู้อ่านก็จะหาวิธีทำความเข้าใจมันเอง ตอนต้นอาชีพผมเคยอ่าน “Essential .Net” ของ Don Box และมันก็ไม่ได้ให้ความรู้สึกว่าเขากำลังเล็งผู้อ่านกลุ่มใดกลุ่มหนึ่งโดยเฉพาะ มันเป็นหนังสือที่เจาะลึกภายใน CLR ตรงๆ และกว่าจะเข้าใจทั้งหมดในครั้งแรกก็ต้องอ่านหลายรอบ
  • กำลังคิดอยู่ว่าจำเป็นแค่ไหนที่จะต้องพึ่งสำนักพิมพ์ หรือจริงๆ แล้วจะเขียนหนังสือแบบอิสระเองก็ได้กันแน่ อยากรู้ว่าเป็นเพราะชื่อเสียงของสำนักพิมพ์หรือผลประโยชน์เสริมอื่นๆ หรือเปล่า
  • เห็นด้วยว่าการสอนคือวิธีเรียนรู้ที่ดีที่สุด ตอนมัธยมปลายผมเรียนรู้เรื่องนี้จากการเป็นติวเตอร์คณิต และประสบการณ์การเขียนหนังสือก็คล้ายกัน มันเป็นวิธีที่ดีที่สุดในการทำให้เนื้อหาพื้นฐานกลายเป็นความรู้ของตัวเองอย่างแท้จริง ไม่ใช่แค่เข้าใจผิวเผิน
  • ฟังดูเหมือนคุยโม้หน่อยๆ แต่ผมเองก็ลงลึกกับหนังสือฝึกความแข็งแรงเพื่อการปีนเขาจนสุดท้ายได้เขียนมันขึ้นมา เดิมทีตั้งใจจะทำ self-publishing แต่สุดท้ายก็หาสำนักพิมพ์และปรับให้มันอ่านง่ายขึ้นนิดหน่อย การลองติดต่อสำนักพิมพ์โดยตรงก็เป็นวิธีหนึ่งเหมือนกัน

• ประสบการณ์กับ BEAM และ Erlang/OTP เป็นหนึ่งในประสบการณ์การพัฒนาที่ดีที่สุดของผมในรอบปีที่ผ่านมา ผมใช้หนังสือ “Programming Erlang: Software for a Concurrent World” ของ Joe Armstrong และอยากแนะนำอย่างมากสำหรับผู้เริ่มต้น “Designing for Scalability with Erlang/OTP” ก็ได้รับคำชมดี แต่ผมยังไม่ได้เริ่ม อย่างไรก็ตาม ในแง่ความลึก หนังสือเล่มนี้เหนือกว่ามาก BEAM ให้ความรู้สึกเหมือนเทคโนโลยีต่างดาวที่อารยธรรมโบราณทิ้งไว้ จังหวะที่หนังสือเล่มนี้ออกมาดีมากเลยซื้อทันที และน่าทึ่งที่ Dr. Erik Stenman ทำหนังสือเล่มนี้จนเสร็จได้แม้จะถูกยกเลิกการตีพิมพ์ถึงสองครั้ง

  • อยากรู้ว่าคุณพัฒนาซอฟต์แวร์แบบไหนด้วย BEAM/Erlang/OTP

• Elixir และ BEAM เป็นตัวเลือกอันดับต้นๆ ของผมสำหรับการสร้างระบบที่อิงเครือข่ายหรือมี pipeline จำนวนมาก ผมใช้มันทุกวันใน production มาหลายปี และแม้ในโปรเจ็กต์ล่าสุดจะตัดสินใจเลือกได้ไม่ง่าย แต่ก็ยังติดตามความเคลื่อนไหวอยู่เสมอ ขอบคุณที่หนังสือเล่มนี้ได้ออกมา มันคือหนังสือที่ผมอยากได้มากตอนที่ต้องดีบัก Elixir บน production เมื่อหลายปีก่อน เพราะเอกสารที่มีอยู่เดิมมักยากเกินไปหรือไม่ก็ง่ายเกินไป

• ข้อมูลเกี่ยวกับ BEAM (Erlang virtual machine) ดูได้ที่ลิงก์วิกิพีเดีย

  • อธิบายไว้ดีอยู่แล้วในชื่อหนังสือ

• คิดว่า BEAM เป็นหนึ่งในเทคโนโลยีโอเพนซอร์สที่ถูกประเมินค่าต่ำที่สุด ตัวอย่างเช่น whatsapp เป็นปริศนาว่าทำไม Elixir และ Erlang ถึงไม่เป็นที่นิยมมากกว่านี้ในโปรเจ็กต์ที่มี concurrency สูง

  • ที่ทำงานของผมเป็นบริษัทที่เชี่ยวชาญ Erlang จุดแข็งที่แท้จริงของ Erlang คือทราฟฟิกขนาดใหญ่ระดับหลายล้าน DAU คุณจะรันเว็บไซต์ Elixir ที่มีหลักพัน DAU ก็ได้ แต่แก่นแท้ของ Erlang และ BEAM อยู่ที่สเกลระดับนั้น บริษัทที่ต้องการขนาดแบบนี้ไม่ได้มีมากนัก และปัญหาใหญ่อีกอย่างคือ ecosystem ของ Erlang เองทำงานเหมือนเป็น OS แยกต่างหาก การตั้งค่าสภาพแวดล้อมและองค์ประกอบต่างๆ ค่อนข้างซับซ้อน คุณไม่จำเป็นต้องใช้เทคโนโลยีโครงสร้างพื้นฐานอื่นอย่าง container หรือ k8s ด้วยซ้ำ และยิ่งทำให้มันดูไม่คุ้นเคยเพราะวิธีเฉพาะตัวของ Erlang ถ้าได้ใช้ Erlang ในสถานการณ์ที่เหมาะพอดี ผมคิดว่ามันเหมือนเวทมนตร์ชนิดหนึ่ง เป็นไฮไลต์ในอาชีพของผมเลย
  • ผมคิดว่าท้ายที่สุดเป็นผลจากการตลาด Java, C#, Go มีแรงหนุนมหาศาลจากองค์กร แต่ Erlang กลับเหมือนถูกองค์กรฉุดไว้หรืออย่างน้อยก็ไม่ได้ใส่ใจอะไรมากนอกจากเอกสารเทคนิค Elixir เป็นครั้งแรกที่มีการใช้การตลาดแบบภาษาอื่น (โมเดลแบบ Ruby) แต่ช่วงเวลาที่เข้ามาและบริบทมันต่างออกไป นักพัฒนาน่าจะเชื่อในความยอดเยี่ยมของ BEAM แต่ดูเหมือนจะสื่อสารไปไม่ถึงผู้มีอำนาจตัดสินใจนอกสายนี้
  • ผมคิดว่าความต่างด้านการลงทุนมีผลมาก Rust, Go, Python ฯลฯ ได้รับการลงทุนมหาศาลจากการสนับสนุนขององค์กรในเรื่อง static analysis, type checking, developer experience และอื่นๆ แต่ฝั่ง Erlang ไม่ได้รับความรักแบบนั้นมากพอ และผู้ใช้รายใหญ่ก็ทยอยสร้างทางออกของตัวเองนอก BEAM หรือย้ายออกไปด้วย
  • เราเพิ่งเปลี่ยนเว็บไซต์ Squarespace มาเป็นแอป Phoenix และเป็นประสบการณ์ที่สนุกมาก
  • ในขณะเดียวกันมันก็เป็น ‘secret sauce’ ที่ลับน้อยที่สุดเช่นกัน ช่วงนี้ BBC ก็ย้ายมาใช้ Elixir ด้วย เลยรู้สึกว่ากำลังได้รับความนิยมมากขึ้นเรื่อยๆ

• ชอบคำอธิบายที่ว่า “Erlang Runtime System (ERS)” หมายถึงรันไทม์ Erlang โดยทั่วไป ส่วน “Erlang RunTime System (ERTS)” เป็นคำที่จำกัดเฉพาะ implementation ของ Ericsson

  • ผมว่า definition นั้นไม่ได้งี่เง่าเลย

• ผมซื้อหนังสือทันที ถึงจะอ่านออนไลน์ได้ฟรี แต่ก็อยากสนับสนุนผู้เขียนสักเล็กน้อย

• ผมไม่ได้ทำระบบขนาดใหญ่อย่าง Klarna เลยนึกภาพยากที่ความหน่วง 15ms จะกลายเป็นประเด็นใน postmortem ได้

  • ใน BEAM การตอบสนองระดับไมโครวินาที (μs) เป็นเรื่องปกติ ดังนั้นถ้ากระโดดไปถึงมิลลิวินาที (ms) ก็อาจมีการแจ้งเตือนทันที
  • ในระบบ BEAM เรื่องแบบนี้เกิดขึ้นได้จริง ถ้าคุณสร้าง gen_server เพื่อปกป้อง shared state มันก็เป็นเหมือน mutex ขนาดใหญ่ ถ้า gen_server ใช้เวลา 20us ในการจัดการคำขอหนึ่งครั้ง ความหน่วง 15ms ก็แปลว่ามีข้อความ 750 ข้อความกองอยู่ใน message queue แล้ว ถ้ายังใช้ message queue ด้วยแพตเทิร์นที่ไม่มีประสิทธิภาพ ประสิทธิภาพก็จะตกฮวบ BEAM ปรับแต่งการทำงานของ message queue ให้เฉพาะบางแพตเทิร์นเท่านั้น ส่วนกรณีอื่นเวลาประมวลผลจะเพิ่มตามความยาวของคิว ถ้าในไลบรารีมีการใช้ receive ที่ไม่ปลอดภัย ก็อาจเกิดปัญหาประสิทธิภาพที่คาดไม่ถึงได้ ไม่นานมานี้ BEAM เพิ่มฟีเจอร์ alias เพื่อช่วยบรรเทาปัญหา message queue แต่หลายไลบรารียังไม่ได้ใช้ จุดประสงค์ของ alias คือป้องกันการสูญหายของข้อความ และช่วยไม่ให้คิวปนเปื้อนด้วยข้อความ timeout โดยปกติโปรเซสอายุยืนจะจัดการคิวด้วยการวนลูป
  • ถ้าใครมีลิงก์ postmortem ของเหตุการณ์ที่พูดถึงก็อยากอ่านเหมือนกัน ผมหาออนไลน์ไม่เจอ

• สงสัยว่ามี VM อื่นที่คล้าย BEAM ไหม หรือว่า BEAM ดีมากจนไม่มีคู่แข่ง หรือจริงๆ แล้วแค่สร้างยากมาก

  • ผมมองว่าฟังก์ชันที่โครงสร้างพื้นฐาน Kubernetes สมัยใหม่ให้มานั้นคล้ายกับ BEAM มาก ทุกวันนี้คุณสร้างระบบ self-healing ขนาดใหญ่บนอินฟราแบบนี้ได้ และก็ไม่ติดข้อจำกัดเรื่องภาษา Erlang/Elixir ไม่ใช่ตัวเลือกเดียว ยังมี ecosystem บุคลากร และความสนใจในสายอื่นอีกมาก
  • มี implementation แยกชื่อ AtomVM สำหรับอุปกรณ์ที่มีข้อจำกัดอย่าง IoT ด้วย มีความพยายามมากมายที่จะนำ BEAM หรือ OTP ไปทำใน ecosystem อื่น แต่ส่วนใหญ่ไม่ถึงระดับ VM
  • ในช่วงปลายยุค 90 ถึงต้นยุค 2000 ตอนที่ BEAM ออกมา มันค่อนข้างมีเอกลักษณ์ ทุกวันนี้แม้วิธี implementation จะแตกต่างกัน แต่เราก็แก้ปัญหาแบบเดียวกันได้ดีด้วยภาษาและเครื่องมือหลากหลาย Erlang community เองก็มีท่าทีแบบ “มีแต่แนวทางของ BEAM เท่านั้นที่ถูกต้อง” อยู่บ้าง แต่ในปี 2025 มีตัวเลือกมากมายจริงๆ มี implementation ที่เข้ากันได้กับ BEAM อยู่เช่นกัน แต่ส่วนใหญ่เป็นงานเฉพาะทาง ถ้าไม่จำเป็นต้องเข้าไปรวมกับอินฟรา BEAM เดิม สำหรับโปรเจ็กต์ greenfield ผมคิดว่าโซลูชันสมัยใหม่จาก ecosystem ปัจจุบันเหมาะกว่า ยังมีโปรเจ็กต์เล็กๆ อย่าง ergo ด้วย
  • Dis VM น่าจะใกล้เคียงที่สุด รองลงมาคือ Smalltalk VM จริงๆ แล้วไม่ใช่แค่ BEAM เอง แต่เป็น OTP ที่อยู่ด้านบนซึ่งทำให้ BEAM แสดงศักยภาพเต็มที่
  • ถ้าเอาในทางใช้งานจริง สิ่งที่ใกล้ที่สุดน่าจะเป็น Go BEAM เป็น ecosystem ที่ออกแบบมาสำหรับ “ภาษาแนว Erlang” ดังนั้น Elixir หรือ Gleam ก็มีพฤติกรรมแกนหลักคล้าย Erlang ส่วน Go มอบ primitive ด้าน concurrency แบบ Erlang เช่น goroutine แต่ไม่มีมุมมองที่ชัดเจนต่อโครงสร้างของแอปพลิเคชันแบบ OTP