{"slug": "beam", "name": "BEAM", "category": "infra", "category_name": "Infrastructure and DevOps", "description": "", "recommenders": 14, "commenters": 22, "warners": 2, "score": 11.76, "rising": -1.93, "first": "2025-11-02", "latest": "2026-10-05", "why": "its true strength lies in the BEAM, an incredibly well-architected piece of software", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 14, "neutral": 4, "compare": 2, "warn": 2}, "spark": [3, 3, 0, 0, 1, 0, 1, 3, 1, 0, 2, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "its true strength lies in the BEAM, an incredibly well-architected piece of software", "kind": "", "icon": true, "domain": "erlang.org", "github_repo": null, "official_url": "https://www.erlang.org", "pricing": "", "aliases": ["BEAM", "Beam"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 794730049, "item_id": 49670628, "url": "https://news.ycombinator.com/item?id=49670628", "by": "spinningslate", "date": "2026-09-12", "version": null, "stance": "recommend", "quote": "I'm continuously grateful for the BEAM's support for fine-grained processes", "excerpt": "> Yes, golang managed to create dynamic stacks, but this required major support from compiler and so unlikely to appear in existing languages That's true but I'm puzzled by the decision rationale. It's undeniably a major undertaking to add first class, fine-grained processes to a language and its runtime. But time invested there gets the multiplicative upside that all language users benefit from the investment. Inste", "context": "", "use_case": "", "switched_from": "", "story": "A Design Space Exploration of Async/Await"}, {"id": 794337952, "item_id": 49646122, "url": "https://news.ycombinator.com/item?id=49646122", "by": "rramadass", "date": "2026-09-10", "version": null, "stance": "recommend", "quote": "The underlying C-based infrastructure is so good", "excerpt": "Security Standards/Frameworks like \"TCB\" (https://en.wikipedia.org/wiki/Trusted_computing_base), \"Common Criteria\" (https://en.wikipedia.org/wiki/Common_Criteria) etc. are not what i am talking about here. I am pointing to the fact that there is a large piece of industrial-strength C code (i.e. BEAM/ERTS) whose architecture/complexity/techniques are manifested as the \"features\" of another higher-level language (i.e. ", "context": "", "use_case": "Erlang runtime VM", "switched_from": "", "story": "C*: Unifying Programming and Verification in C (2025)"}, {"id": 784636800, "item_id": 49039800, "url": "https://news.ycombinator.com/item?id=49039800", "by": "theflyinghorse", "date": "2026-07-24", "version": null, "stance": "recommend", "quote": "The big ones for me are the actor processes sending each other messages", "excerpt": "The big ones for me are the actor processes sending each other messages, distributed processes where you can connect several nodes to each other very seamlessly and the processes within them communicate seemlessly! I\u2019m not looking to rebuild OTP, I\u2019m simply exploring ideas I couldn\u2019t before", "context": "", "use_case": "actor model and distributed processes", "switched_from": "", "story": "Ask HN: How much software do you build for yourself these days?"}, {"id": 776413666, "item_id": 48525854, "url": "https://news.ycombinator.com/item?id=48525854", "by": "OhSoHumble", "date": "2026-06-14", "version": null, "stance": "recommend", "quote": "A lot is built into the BEAM by default", "excerpt": "I'm pretty smitten with Phoenix as a framework. A lot is built into the BEAM by default and the Elixir ecosystem is quite lovely. I've been building an Etsy-lite replacement in my free time with it: https://plukio.com/ It's pretty enjoyable. I also like using Ash for data modeling and business logic expression. It's also quite lovely.", "context": "", "use_case": "", "switched_from": "", "story": "Phoenix LiveView 1.2 Released"}, {"id": 774281952, "item_id": 48392622, "url": "https://news.ycombinator.com/item?id=48392622", "by": "recroad", "date": "2026-06-03", "version": null, "stance": "recommend", "quote": "I use Elixir not because of typed/untyped, but because of BEAM and OTP.", "excerpt": "I use Elixir not because of typed/untyped, but because of BEAM and OTP.", "context": "", "use_case": "Concurrent runtime", "switched_from": "", "story": "Elixir v1.20 released: now a gradually typed language"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 799509984, "item_id": 49969374, "url": "https://news.ycombinator.com/item?id=49969374", "by": "Ariarule", "date": "2026-10-05", "version": null, "stance": "warn", "quote": "\"puzzle is a few days old\" is incorrect", "excerpt": "Always glad to see more open-weight models, but this caption on the 2nd demo image had me do a double-take: \"Land or Water Generalization Experiment: We recreated the viral X puzzle by asking Beam to create a fixed 180\u00d790 grid for longitudes -179\u00b0 to 179\u00b0 and latitudes -89\u00b0 to 89\u00b0, with 16,200 points. This puzzle is a few days old, so could not appear in the training data, thus testing the model\u2019s generalization. Bea", "context": "", "use_case": "", "switched_from": "", "story": "Beam: Reflection's 501B open-weight model"}, {"id": 760391026, "item_id": 47524439, "url": "https://news.ycombinator.com/item?id=47524439", "by": "subhamkts", "date": "2026-03-25", "version": null, "stance": "warn", "quote": "the overhead from beamvm causes a 3s delay", "excerpt": "cursor released their fast regex search impl called instant grep (a questionable implementation that takes a while to build indexes for, but an implementation regardless) i built an implementation in Elixir based on their spec and published it on Homebrew for people to install and use: ``` brew tap GrowlyX/instantgrep brew install instantgrep ``` feel free to contribute and improve on Cursor's original design on my g", "context": "", "use_case": "", "switched_from": "", "story": "Instant Grep CLI Implementation"}]}], "who": [{"by": "cyberpunk", "context": "runs BEAM in production for about 8 years", "url": "https://news.ycombinator.com/item?id=48078772", "date": "2026-05-09"}, {"by": "Setas", "context": "Runs an 8-agent system on BEAM", "url": "https://news.ycombinator.com/item?id=47368944", "date": "2026-03-13"}, {"by": "asa400", "context": "Years using the BEAM", "url": "https://news.ycombinator.com/item?id=46130957", "date": "2025-12-02"}, {"by": "abeltensor", "context": "has used Elixir in production for years", "url": "https://news.ycombinator.com/item?id=46129967", "date": "2025-12-02"}], "tags": [], "use_cases": ["erlang runtime vm", "actor model and distributed processes", "concurrent runtime", "production runtime", "fault-tolerant multi-agent systems", "production backend systems"], "compared": [{"slug": "erlang-otp", "name": "Erlang/OTP", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "otp", "name": "OTP", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=48524293", "title": "Phoenix LiveView 1.2 Released", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=46110836", "title": "Response to \"Ruby Is Not a Serious Programming Language\"", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=49969183", "title": "Beam: Reflection's 501B open-weight model", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49626718", "title": "A Design Space Exploration of Async/Await", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49612191", "title": "C*: Unifying Programming and Verification in C (2025)", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49035758", "title": "Ask HN: How much software do you build for yourself these days?", "mentions": 1}], "sentiment_by_month": {"2025-11": {"recommend": 3, "neutral": 1, "compare": 1}, "2025-12": {"recommend": 3}, "2026-01": {}, "2026-02": {"compare": 1}, "2026-03": {"recommend": 1, "warn": 1}, "2026-04": {}, "2026-05": {"neutral": 1, "recommend": 1}, "2026-06": {"recommend": 3, "neutral": 2}, "2026-07": {"recommend": 1}, "2026-08": {}, "2026-09": {"recommend": 2}, "2026-10": {"warn": 1}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 799509984, "item_id": 49969374, "url": "https://news.ycombinator.com/item?id=49969374", "by": "Ariarule", "date": "2026-10-05", "version": null, "stance": "warn", "quote": "\"puzzle is a few days old\" is incorrect", "excerpt": "Always glad to see more open-weight models, but this caption on the 2nd demo image had me do a double-take: \"Land or Water Generalization Experiment: We recreated the viral X puzzle by asking Beam to create a fixed 180\u00d790 grid for longitudes -179\u00b0 to 179\u00b0 and latitudes -89\u00b0 to 89\u00b0, with 16,200 points. This puzzle is a few days old, so could not appear in the training data, thus testing the model\u2019s generalization. Bea", "context": "", "use_case": "", "switched_from": "", "story": "Beam: Reflection's 501B open-weight model"}, {"id": 794730049, "item_id": 49670628, "url": "https://news.ycombinator.com/item?id=49670628", "by": "spinningslate", "date": "2026-09-12", "version": null, "stance": "recommend", "quote": "I'm continuously grateful for the BEAM's support for fine-grained processes", "excerpt": "> Yes, golang managed to create dynamic stacks, but this required major support from compiler and so unlikely to appear in existing languages That's true but I'm puzzled by the decision rationale. It's undeniably a major undertaking to add first class, fine-grained processes to a language and its runtime. But time invested there gets the multiplicative upside that all language users benefit from the investment. Inste", "context": "", "use_case": "", "switched_from": "", "story": "A Design Space Exploration of Async/Await"}, {"id": 794337952, "item_id": 49646122, "url": "https://news.ycombinator.com/item?id=49646122", "by": "rramadass", "date": "2026-09-10", "version": null, "stance": "recommend", "quote": "The underlying C-based infrastructure is so good", "excerpt": "Security Standards/Frameworks like \"TCB\" (https://en.wikipedia.org/wiki/Trusted_computing_base), \"Common Criteria\" (https://en.wikipedia.org/wiki/Common_Criteria) etc. are not what i am talking about here. I am pointing to the fact that there is a large piece of industrial-strength C code (i.e. BEAM/ERTS) whose architecture/complexity/techniques are manifested as the \"features\" of another higher-level language (i.e. ", "context": "", "use_case": "Erlang runtime VM", "switched_from": "", "story": "C*: Unifying Programming and Verification in C (2025)"}, {"id": 784636800, "item_id": 49039800, "url": "https://news.ycombinator.com/item?id=49039800", "by": "theflyinghorse", "date": "2026-07-24", "version": null, "stance": "recommend", "quote": "The big ones for me are the actor processes sending each other messages", "excerpt": "The big ones for me are the actor processes sending each other messages, distributed processes where you can connect several nodes to each other very seamlessly and the processes within them communicate seemlessly! I\u2019m not looking to rebuild OTP, I\u2019m simply exploring ideas I couldn\u2019t before", "context": "", "use_case": "actor model and distributed processes", "switched_from": "", "story": "Ask HN: How much software do you build for yourself these days?"}, {"id": 776413666, "item_id": 48525854, "url": "https://news.ycombinator.com/item?id=48525854", "by": "OhSoHumble", "date": "2026-06-14", "version": null, "stance": "recommend", "quote": "A lot is built into the BEAM by default", "excerpt": "I'm pretty smitten with Phoenix as a framework. A lot is built into the BEAM by default and the Elixir ecosystem is quite lovely. I've been building an Etsy-lite replacement in my free time with it: https://plukio.com/ It's pretty enjoyable. I also like using Ash for data modeling and business logic expression. It's also quite lovely.", "context": "", "use_case": "", "switched_from": "", "story": "Phoenix LiveView 1.2 Released"}, {"id": 776402160, "item_id": 48525135, "url": "https://news.ycombinator.com/item?id=48525135", "by": "arcanemachiner", "date": "2026-06-14", "version": null, "stance": "neutral", "quote": "I believe BEAM bytecode is now JIT-ed.", "excerpt": "I believe BEAM bytecode is now JIT-ed. EDIT: It is, since OTP 24 was released in 2021: https://www.erlang.org/downloads/24 > The BeamAsm JIT-compiler has been added to Erlang/OTP and will give a significant performance boost for many applications. The JIT-compiler is enabled by default on most x86 64-bit platforms that have a C++ compiler that can compile C++17.", "context": "", "use_case": "", "switched_from": "", "story": "Phoenix LiveView 1.2 Released"}, {"id": 776402128, "item_id": 48525133, "url": "https://news.ycombinator.com/item?id=48525133", "by": "conradfr", "date": "2026-06-14", "version": null, "stance": "neutral", "quote": "What about https://www.erlang.org/doc/apps/erts/beamasm.html", "excerpt": "What about https://www.erlang.org/doc/apps/erts/beamasm.html", "context": "", "use_case": "", "switched_from": "", "story": "Phoenix LiveView 1.2 Released"}, {"id": 774281952, "item_id": 48392622, "url": "https://news.ycombinator.com/item?id=48392622", "by": "recroad", "date": "2026-06-03", "version": null, "stance": "recommend", "quote": "I use Elixir not because of typed/untyped, but because of BEAM and OTP.", "excerpt": "I use Elixir not because of typed/untyped, but because of BEAM and OTP.", "context": "", "use_case": "Concurrent runtime", "switched_from": "", "story": "Elixir v1.20 released: now a gradually typed language"}, {"id": 774153952, "item_id": 48384622, "url": "https://news.ycombinator.com/item?id=48384622", "by": "pdimitar", "date": "2026-06-03", "version": null, "stance": "recommend", "quote": "Even if the BEAM VM is slower and has a few annoying sharp edges, its strengths nullify its weaknesses", "excerpt": "> that would be the reason why syntax does matter, wouldn't it? nobody wants leaky abstractions! Well I thought we were describing our current reality, not our _desired_ one? Yes nobody wants leaky abstractions and yes they are everywhere. Syntax matters insofar as to discourage bad habits, is what I'd refine from my previous statements. Most programmers go for the default so defaults and syntax that steers you the r", "context": "", "use_case": "", "switched_from": "", "story": "My thoughts after using Clojure for about a month"}, {"id": 772668960, "item_id": 48291810, "url": "https://news.ycombinator.com/item?id=48291810", "by": "ramchip", "date": "2026-05-27", "version": null, "stance": "recommend", "quote": "I love the BEAM", "excerpt": "I love the BEAM and programmed on it for many years, but it really does not provide anything like durable objects. 1) It's very difficult to ensure globally serialized ownership with strong consistency in a distributed Erlang cluster when nodes are allowed to fail. Stuff like Horde will let you do some rough \"run an instance of this process somewhere in the cluster\", but it's eventually consistent (you may have multi", "context": "", "use_case": "", "switched_from": "", "story": "What I've Learned (So Far) Building Online Mini Games with Elixir and Swift"}, {"id": 769260352, "item_id": 48078772, "url": "https://news.ycombinator.com/item?id=48078772", "by": "cyberpunk", "date": "2026-05-09", "version": null, "stance": "neutral", "quote": "I'm running BEAM in production for almost 8 years", "excerpt": "I'm running BEAM in production for almost 8 years and not once have I used hot code reloading. Why is that critical?", "context": "runs BEAM in production for about 8 years", "use_case": "Production runtime", "switched_from": "", "story": "A Couple Million Lines of Haskell: Production Engineering at Mercury"}, {"id": 760391026, "item_id": 47524439, "url": "https://news.ycombinator.com/item?id=47524439", "by": "subhamkts", "date": "2026-03-25", "version": null, "stance": "warn", "quote": "the overhead from beamvm causes a 3s delay", "excerpt": "cursor released their fast regex search impl called instant grep (a questionable implementation that takes a while to build indexes for, but an implementation regardless) i built an implementation in Elixir based on their spec and published it on Homebrew for people to install and use: ``` brew tap GrowlyX/instantgrep brew install instantgrep ``` feel free to contribute and improve on Cursor's original design on my g", "context": "", "use_case": "", "switched_from": "", "story": "Instant Grep CLI Implementation"}, {"id": 757903104, "item_id": 47368944, "url": "https://news.ycombinator.com/item?id=47368944", "by": "Setas", "date": "2026-03-13", "version": null, "stance": "recommend", "quote": "The BEAM was designed for exactly this", "excerpt": "Different scale (I run 8, not 69) but the same fundamental challenge: what happens when one of those agents fails mid-task? I hit this with my multi-agent system \u2014 8 agents sharing a JSONL knowledge graph. Parallel writes caused a race condition: two agents read the same file state, both write back the full graph plus their additions, second write silently obliterates the first. Sometimes the file ends up with a half", "context": "Runs an 8-agent system on BEAM", "use_case": "Fault-tolerant multi-agent systems", "switched_from": "", "story": "Every minute you aren't running 69 agents, you are falling behind"}, {"id": 751404417, "item_id": 46962776, "url": "https://news.ycombinator.com/item?id=46962776", "by": "sieep", "date": "2026-02-10", "version": null, "stance": "compare", "quote": "I feel like it matches Go or BEAM performance now", "excerpt": "Sure. They really knocked it out of the park with performance in .NET 10. I feel like it matches Go or BEAM performance now but with a lot more tools at your disposal. I use the 'code-first approach' most the time which really leans into the performance improvements. I can write C# data models that automatically update the database schemas on the SQL side. This is obviously possible in other languages/runtimes, .NET ", "context": "", "use_case": "", "switched_from": "", "story": "F# 10"}, {"id": 741760529, "item_id": 46360033, "url": "https://news.ycombinator.com/item?id=46360033", "by": "schultzer", "date": "2025-12-22", "version": null, "stance": "recommend", "quote": "the BEAM can give you superpowers that no other platform can", "excerpt": "SQL is great, but what is even better is a SOTA client. https://github.com/elixir-dbvisor/sql the BEAM can give you superpowers that no other platform can, handle massive concurrency with the performance that rivals bare metal and c https://erlangforums.com/t/elixir-dbvisor-sql-needs-a-sota-pool-and-i-want-to-hear-your-ideas/5145/9?u=schultzer", "context": "", "use_case": "", "switched_from": "", "story": "The Rise of SQL:the second programming language everyone needs to know"}, {"id": 738095312, "item_id": 46130957, "url": "https://news.ycombinator.com/item?id=46130957", "by": "asa400", "date": "2025-12-02", "version": null, "stance": "recommend", "quote": "Having done it for some years now, the BEAM kinda has", "excerpt": "> what's the perception re: current blockers for widespread adoption? Years ago, it was nothing more or less than third-party libs and frameworks. That must be better by now, or there's a short-list of what's missing? It's complicated. The library/framework situation is much better than it used to be. There isn't much that's glaringly missing anymore. Some things have lighter maintenance than one might like, but most", "context": "Years using the BEAM", "use_case": "", "switched_from": "", "story": "Response to \"Ruby Is Not a Serious Programming Language\""}, {"id": 738079472, "item_id": 46129967, "url": "https://news.ycombinator.com/item?id=46129967", "by": "abeltensor", "date": "2025-12-02", "version": null, "stance": "recommend", "quote": "its true strength lies in the BEAM, an incredibly well-architected piece of software", "excerpt": "The article significantly misses the mark by treating Ruby as nothing more than Rails \u2014 a perspective that currently detracts from the language. The author clearly hasn't explored the strong features of Ruby 3. Not to mention, it's a very nice language to learn as an entry point into programming. Ruby is incredibly versatile: NASA has used it for simulation, it's a popular choice for scripting, DevOps automation, and", "context": "has used Elixir in production for years", "use_case": "production backend systems", "switched_from": "", "story": "Response to \"Ruby Is Not a Serious Programming Language\""}, {"id": 737628432, "item_id": 46101777, "url": "https://news.ycombinator.com/item?id=46101777", "by": "rdtsc", "date": "2025-11-30", "version": null, "stance": "recommend", "quote": "the BEAM is already ahead with nano-services", "excerpt": "Yup, good point on the BEAM. The joke we used when microservices were hot was that the BEAM is already ahead with nano-services: a gen_server is a nice lightweight, isolated process. You can define a callback API wrapper for it and deploy millions of them on a cluster.", "context": "", "use_case": "", "switched_from": "", "story": "You want microservices, but do you need them?"}, {"id": 736462144, "item_id": 46028884, "url": "https://news.ycombinator.com/item?id=46028884", "by": "aw1621107", "date": "2025-11-23", "version": null, "stance": "compare", "quote": "Or compare it to BEAM that can have processes crash all day long and still continue to work.", "excerpt": "> Rust cannot recover. catch_unwind exists for a reason. > e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`. You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though. > Do note that C did not have such a flaw built into language", "context": "", "use_case": "", "switched_from": "", "story": "Several core problems with Rust"}, {"id": 734697472, "item_id": 45918592, "url": "https://news.ycombinator.com/item?id=45918592", "by": "xpe", "date": "2025-11-13", "version": null, "stance": "recommend", "quote": "BEAM (Erlang, Elixir) provides hot-swappable code and lots more", "excerpt": "> Code by mass live committee. Yikes. Let's lean into the chaos and see what it might give us. Imagine a production application deployed directly from a non-version-controlled directory. Anyone on the team can edit the files, at any time. Insane? Probably. The disadvantages are easy to see. But the positives are really compelling: 1. make small, granular testable changes; 2. use feature toggles; 3. refactor intensely", "context": "", "use_case": "", "switched_from": "", "story": "Zed is our office"}, {"id": 734168128, "item_id": 45885508, "url": "https://news.ycombinator.com/item?id=45885508", "by": "lpil", "date": "2025-11-11", "version": null, "stance": "neutral", "quote": "one can statically compile the BEAM for Linux exactly the same as the JVM", "excerpt": "> The BEAM hooks into so many system libraries, you must compile it on every flavor of linux instead of just unpacking a tarball. This isn't true, one can statically compile the BEAM for Linux exactly the same as the JVM. Here's an example: https://github.com/yoshi-monster/static_erlang/", "context": "", "use_case": "", "switched_from": "", "story": "Writing your own BEAM"}, {"id": 732694768, "item_id": 45793423, "url": "https://news.ycombinator.com/item?id=45793423", "by": "Yoric", "date": "2025-11-02", "version": null, "stance": "recommend", "quote": "BEAM builds into it a number of the features for which we use orchestration, observability, just simpler and (generally) more flexible.", "excerpt": "There are a few very large features that BEAM offers that, as far as I can tell, no other industrial language/VM implements. In particular, BEAM is meant for distributed computation. You can spawn new processes, communicate between processes (which don't have to be on the same computer), sending any kind of data between them including closures. BEAM also has an error model designed to handle concurrent and distribute", "context": "", "use_case": "", "switched_from": "", "story": "A Few Words About Async"}]}