Why I wrote the BEAM book

https://happihacking.com/blog/posts/2025/why_I_wrote_theBEAMBook/

by lawik • 1 year ago

613 151 1 year ago

asib• 1 year ago

I guess I've never worked on something of Klarna's scale, but 15ms seems like a very small amount of time to cause a post-mortem-worthy event!

__jonas• 1 year ago

I am also curious about the mentioned incident, does anyone have a link to the postmortem the post talks about? Couldn't find anything online.

lawik2• 1 year ago

I would assume it was an internal post-mortem. Far from all are public affairs.

abrookewood• 1 year ago

Yes, it does seem small, but the BEAM often has response times in microseconds (μs). If you are used to that and something 'blows out' to milliseconds, then I can see why alarms might get triggered.

regularfry• 1 year ago

If it's millions of calls and it's 15 additional milliseconds per call, that's going to spectacularly gum up a system that's tuned in microseconds. Even if there's no additional load, the queues all just got several thousand times longer.

benmmurphy2• 1 year ago

this can easily happen in a BEAM system. say you have some shared state you want to access. you create a gen_server to protect this shared state. a gen_server is basically a huge mutex. the gen_server is just a normal beam process that handles requests sent to its message queue and then sends a reply message back. lets say it can process a request normally in 20us. so a 15ms pause would stack up 750 messages in its message queue. now maybe this is not enough to generate a huge outage on its own but maybe as part of your handling you are using the message queue in an unsafe way. so when you check the message queue for a message the BEAM will just search the whole message queue for a message that matches. there are certain patterns the BEAM is able to optimize to prevent the whole message queue being searched (i think almost every pattern is unsafe and the BEAM only optimizes the gen rpc style message patterns) . but if you are using an unsafe pattern when you have a message queue backlog it will destroy the throughput in the system because the time taken to process a message is a function of the message queue length and the message queue length becomes a function of how long it takes to process a message.

Also, the great thing is you might not even have an explicit `receive` statement in your gen_server code. You might just be using a library that is using a `receive` somewhere that is unsafe with a large message queue and now you are burned. The BEAM also added some alternative message queue thing so you are able to use this instead of the main message queue of a process which should be a lot safer but I think a lot of libraries still do not use this. This alternative is 'alias' (https://www.erlang.org/doc/system/ref_man_processes.html#pro...) which does something slightly different from what I thought which is to protect the queue from 'lost' messages. Without aliases 'timeouts' can end up causing the process message queue to be polluted with messages that are no longer being waited on. This can lead to the same problems with large message queues causing throughput of a process to drop. However, usually long lived processes will have a loop that handles messages in the queue.

valenterry• 1 year ago

lets say it can process a request normally in 20us.

Then what if the OS/thread hangs? Or maybe a hardware issue even. Seems a bit weird to have critical path be blocked by a single mutex. That's a recipe for problems or am I missing something?

davidw2• 1 year ago

this can easily happen in a BEAM system

Wait... I thought all you had to do is write it in Erlang and it scales magically!

nilirl2• 1 year ago

Books ask for a lot of organization in general. And books on an evolving subject never stop asking.

I don't use Erlang, but for 13 years in the making, I'm getting a copy.

Thank you.

p.s if the author sees this: Kindle edition too, please.

ErikStenman2• 1 year ago

OK. It is currently under review by Amazon. Remember, a PDF is free on GitHub; the Kindle thingy will cost some money. - Happi

ErikStenman2• 1 year ago

It is now available. https://www.amazon.com/dp/B0FBX7YWB1

cmoski• 1 year ago

Thank you very much!

graboid• 1 year ago

Are there any other VM's like the BEAM? I never heard of any (admittedly I know little of this subject), and I wondered, is it because there is no need for another one because the BEAM is just so good, or is it because the amount of work and skill required to get another BEAM-like runtime with comparable quality is too demanding?

lawik2• 1 year ago

There is a separate implementation for really constrained device use, called AtomVM.

There are many dead efforts to implement something like the BEAM or OTP within other ecosystems. Usually not as a VM.

reddit_clone• 1 year ago

I have seen attempts at actor systems like erlang/beam's. Scala/Akka seems to have been a success?

Share nothing, green-thread/coroutines also seem popular now a days.

jerf4• 1 year ago

At the time that BEAM was invented in the late 1990s, and in the early 2000s, it was a fairly unique proposition.

Nowadays there isn't anywhere near as much stuff that it does uniquely. That's probably why there isn't another one. All of the compiled languages off-the-shelf can solve the same problems that BEAM does now, and often with other advantages to boot.

There's something about the Erlang community that convinces people in it that if it isn't solve the exact same way that BEAM does, then it must ipso facto not be as good as BEAM, but that's not true. If you ask the question can I solve the same problems, even if it's in a different way?, you've got a zoo of options in 2025, whereas your options in 2000 were much much weaker.

And yes, being BEAM-compatible is harder than meets the eye. There are projects like https://github.com/ergo-services/ergo that can do it, and I believe there are some in other languages. It's a pretty niche need in my opinion, though. If you don't need to hook up to some existing BEAM infrastructure, I don't consider it a very good solution for a greenfield project. You're better off with more modern tooling and solutions that are more native to your chosen dev environment.

prophesi2• 1 year ago

I'm not sure if it's about the implementation rather than the vast reduction of complexity/boilerplate to attain fault-tolerant distributed systems compared to other solutions.

giraffe_lady2• 1 year ago

I agree with what I think is your overall point, that there are other solutions that adequately solve the problems BEAM does but in different ways.

I really strongly disagree with the idea that there's no modern use for BEAM because of these other solutions. It's not simply that we've convinced ourselves that "if it isn't solve the exact same way that BEAM does, then it must ipso facto not be as good as BEAM" though I understand how you could see it that way.

Frankly what it is is that BEAM has an exceptionally well chosen position among the possible tradeoffs of solving these problems, which you are otherwise on your own to figure out and which are in themselves some of the most difficult practical considerations of systems design.

So again it's not that only BEAM can possibly do it right, but it's that BEAM does do it right. Having seen so many other attempts to do it better fail, at tremendous expense, it's an easy choice for me for systems that are expected to encounter these problems.

cianuro_• 1 year ago

Can you map the BEAM features against the zoo of options you mentioned so readers understand what exactly are these other options and how they compare to BEAM?

mustermannBB• 1 year ago

Correct me if I'm wrong but a big part of the value proposition these days for Erlang/Elixir would be that it comes build in with a lot of the tools that other runtimes would require. For example a message bus is kinda integrated in the BEAM runtime or Erlang, while most other runtimes would have to use something like Kafka or AWS SQS etc. Or caching and some other things. Of course I'm not sure how good all the inbuilt solutions are compared to dedicated tools, overall or usually IMHO I prefer dedicated tools as opposed to all in one as the dedicated tools/services usually are more flexible. On the other hand of course it is also much overhead.

url00• 1 year ago

The reality is modern Kubernetes infrastructure looks a lot like BEAM, at least in the capabilities it offers. That's the far more common way of deploying highly scalable, self-healing systems in the current year. Plus, with k8s you're not constricted to a single language (there are a few more than Erlang/Elixir, but nothing popular) with limited developer resources and interest.

MarceColl3• 1 year ago

So now you need several servers, an orchestrator, tons of YAML, arcane and terrible error messages and a devops team to kind of match the BEAM? That's... not a good look

rkangel• 1 year ago

I think the closest in wide use is probably Go.

The BEAM is set up for "Erlang like languages" (or maybe it's the other way around). Writing Elixir, still feels a lot like Erlang because of the underlying semantics of how it operates. Even Gleam is closer to Erlang than anything else once you get past the types.

Go also has goroutines/green threads/Erlang-like processes as a core primitive for its parallelism. it doesn't have the same "opinion" about how to structure a concurrent application that you get from OTP though.

johnnyjeans• 1 year ago

Dis is probably the closest, followed by the smalltalk VMs. It depends on what you mean by "like the BEAM". The VM itself isn't that special, it's really the whole OTP on top of BEAM that makes Erlang good at what it does.

k__2• 1 year ago

"We will try to use the term Erlang Runtime System to refer to the general idea of any Erlang Runtime System as opposed to the specific implementation by Ericsson which we call the Erlang RunTime System or usually just ERTS."

Love it.

justin66• 1 year ago

That is... not dumb?

techpression2• 1 year ago

Bought it instantly, even if it’s available online for free I guess this way supports the author a little bit

elric2• 1 year ago

I kept going because I wanted to understand the BEAM properly. There’s value in following the real logic, not just the surface explanations.

This resonates with me. That's the kind of drive that results in great output. Buying it just for that.

I've been approached by publishers several times throughout my career. Each time the process was similar: they had an idea, I had an idea, we tried to come to common ground, and then the deal fell through because we couldn't find any. E.g. I didn't want to write a Java book aimed at 14 year olds. They didn't want me to write about classloaders (or whatever niche subject I was diving into at the time).

Would love to learn how people find (non-empty) intersections of their passions & what readers want.

the_arun2• 1 year ago

Do we need to depend on Publishers? Can’t we write books independently? Or is it because of the “Brand” and other perks that come with Publishers?

elric2• 1 year ago

Self publishing is easier than ever. But even shitty publishers like Packt still have a huge networking/marketing machine. My skillset does not include marketing, or checking whether a target audience exists.

If I want to write for just myself, I can just journal or blog. A book is a significant undertaking, writing one which no one reads would just be depressing.

spelunker2• 1 year ago

I mean in the blog post the author literally open sourced and then self-published his book after being dropped by multiple publishers for taking too long.

drob5184• 1 year ago

Publishers add the following:

1. marketing and reach

2. financial risk on paper copies

3. Production services (e.g. editing and artwork)

If you don’t need those or can get them some other way (e.g. hire an independent editor), then you are better off self publishing and not giving the publisher a cut.

dangoor• 1 year ago

I don't know if publishers manage to get better deals from Amazon, but Amazon's Kindle Direct Publishing has an annoying aspect that the ebook royalty rate falls from 70% to 30% after $9.99, which gets very awkward for a tech book you'd like to sell for, say, $19.99.

Also, piracy is rampant and Amazon doesn't do much about it. Publishers have more resources to stay on top of it, I suspect.

crystal_revenge• 1 year ago

Personally my favorite part of working with real publishers is editors. Having a development editor, technical editor, and a team of copy editors really helps making sure the book comes out polished. Additionally, I don't want to deal with all the layout work and the details of printing.

And, depending on the book, yes the distributor the publisher has can be very helpful for sales. It's nice to be able to grab your book off the shelf at Barnes and Noble (and, does lend a bit more credibility to your work).

All that said, if you're writing for purely economic reasons (which I would caution against regardless), you're probably going to make roughly the same if you self-publish for a small audience vs go with a traditional publisher for a larger audience, and if you can get a larger audience self-publishing then there will be no comparison.

drob5184• 1 year ago

Having written three books, what I found was that you either self publish or you write books that publishers want. Some of that is choosing publishers that specialize in certain types of books. Some publishers want “Learn AI in 21 Minutes with Python,” while others want “Deep Dark Secrets of Java Class Loaders.” O’Reilly is the best for niche technical stuff. Most of the rest of the industry wants beginner stuff because that’s where the volume is. Fortunately, self-publishing is easier than ever and various sites make it easy to sell copies online, so you don’t necessarily have to just give it away for free. But yea, there’s no magic formula here. If you really want to write something niche, don’t expect that a publisher will be interested in. Expect that you’ll have to self publish and promote it yourself.

asplake2• 1 year ago

That’s my experience too. My most recent book (my fifth) was closer to one publisher’s stated mission than 95% of its catalog, but they all but admitted that they had given up on it. After that rejection I didn’t have the energy to approach anyone else and did it myself instead. LeanPub first, then Amazon (print and kindle), Apple, Kobo, and Google.

turkeygizzard3• 1 year ago

Shameless self promotion but this is exactly how I ended up writing a book on strength training for climbing, just pursuing every rabbit hole I could.

I was ready to self publish but found a publisher who was interested. I had to make some changes to make it more readable, but you might have luck approaching publishers yourself

Intermernet2• 1 year ago

To justify your self promotion, can you tell me the name of your book? I've been climbing for over 30 years and seen the entire progression of training practices and would love to read a comprehensive book on the subject.

aalbuquerque• 1 year ago

Can you share your book (by dm or replying here) plz? Thank you!

tarunkotia• 1 year ago

If you have something interesting to say then people will figure a way to understand it. Early in my career I remember coming across “Essential .Net” by Don Box and I don’t think Don Box had a particular audience in mind. He just unwrapped what’s under the hood in Common Language Runtime (CLR). It took me multiple times to really understand “essential .net”.

ww520• 1 year ago

I kept going because I wanted to understand the BEAM properly. There’s value in following the real logic, not just the surface explanations.

Teaching is the best way to learn. I found that out when I started tutoring classmates for math in high school.

Same thing with writing a book. Something about learning a subject and turning around to speak/write out about it that really crystallizes the in-depth understanding beneath the surface.

snackbroken• 1 year ago

It is easy to fool oneself into thinking one knows how something works, when in reality one only has a surface level understanding without really knowing about the internals. The serialization process exposes all the dangling pointers.

Your average person "knows" how a toilet works; water is pumped in to fill the cistern, released into the bowl when you pull the plunger, and flushes out the drain. Ask them to explain in detail how that happens, and most realize that they don't actually know how the cistern doesn't just keep filling until it overflows, or how it's not constantly leaking water into the bowl, or how the bowl can be flushed while neither overflowing nor draining completely.

lurkshark• 1 year ago

This is also one of the most undersold benefits to hiring interns and entry-level developers.

ralphc• 1 year ago

Don Knuth finally sells out

https://nerocam.com/DrFun/Dave/Dr-Fun/df200002/df20000210.jp...

the_arun2• 1 year ago

Here is the link to the git repo - https://github.com/happi/theBeamBook

spelunker2• 1 year ago

Plenty of documentation can be found about the JVM, but BEAM has always seemed like a bit of a mystery to me. This is great!

lamuswawir5• 1 year ago

The official documentation explains things a little, but only a little.

toast05• 1 year ago

The BEAM isn't that big. When you have questions the documentation doesn't answer, the source might. (I've not read this book, but I did order it, I'd expect it to have some answers too)

tra3• 1 year ago

I’ve been watching erlang from afar for a few years. Here’s to hoping to actually get to work with it one day.

fridder• 1 year ago

Elixir is a pretty great alternative

k__2• 1 year ago

Gleam also seems to be a bit more approachable.

bigbuppo• 1 year ago

Erlang is one of those languages that will make you a better programmer in other languages.

lamuswawir5• 1 year ago

Fullstops.

macintux• 1 year ago

Yes, but after using Erlang, I found it very painful to switch. Easy to get spoiled by immutability & pattern matching.

game_the0ry• 1 year ago

The BEAM might be the most under-rated tech in all of open source.

Example -- whatsapp.

Why Elixir + Erlang are not more popular for high concurrency projects is a mystery to me.

honkycat• 1 year ago

everyone is trying to hire the best, but caters to the lowest common denominator.

"But what if we hire an engineer to stupid to learn a new language in a few weeks???" and on and on and on

paradox460• 1 year ago

I believe it's purely marketing

Other languages (Java, C#, Go) are supported by massive corporate backers, who have vested interest in seeing them succeed. Erlang's own corporate owner tried to strangle it in the crib, and even since then they've been standoffishness towards anything apart from technical resources.

We didn't really see much marketing like material arise until things like Elixir came about, and even that is more following the ruby model, which is very dev oriented. And the world to which Elixir emerged in 2014 is very different than the world rails sprung into in 2004.

Devs can usually be convinced about how good BEAMlangs are, but without the glossy, you have a harder time convincing the MBA set

bmitc3• 1 year ago

Erlang wasn't open sourced until the late 90s. Erlang was never really marketed. Elixir arose fairly quickly.

Erlang and Elixir are nice because concurrency isn't tacked onto the language like those other languages.

sargun• 1 year ago

Investment gap is what I'd say too. While Rust, Go, Python, etc... have had massive backers that have managed to invest a ton more into things like static analysis, type checking, and developer ergonomics, the Erlang ecosystem hasn't necessarily had the same love, and instead the major users have typically chosen to pivot, or build something outside of the BEAM.

bsder• 1 year ago

Why Elixir + Erlang are not more popular for high concurrency projects is a mystery to me.

1) Because the amount of "high concurrency" you can handle with a single machine with "standard" languages keeps moving up every year.

2) Because you had a single, nigh undocumented, very impenetrable to port implementation of BEAM for the longest time.

3) Because "Erlang" isn't the magic. OTP is the magic. And that requires that you shift your mindset dramatically. And you can do the OTP abstractions in other languages!

4) I think Scala sucked up a lot of Erlang's oxygen for a long time. Erlang is helping with that.

d3ckard3• 1 year ago

1. Fair, but at the same time - OTP is the only sane concurrency framework. To the point I still struggle to comprehend why it wasn't copied. 2. Fair. 3. I am not aware of a single language doing OTP abstractions, especially implementing preemptive scheduler for green threads. 4. Possibly, but I haven't seen a single instance of a company choosing between the two.

I think marketing is a way better explanation to be honest. Jose lives in Poland, was very active and a lot of Ruby shops moved to Elixir.

agos2• 1 year ago

OTP is the magic but the ability of the Beam to handle that many processes gracefully is part of the magic

shaklee3• 1 year ago

C++ and its libraries can do everything erlang does with concurrency, and faster. erlang remains niche mainly for that reason.

schonfinkel3• 1 year ago

And now with Gleam moving past version 1.0 last year, the BEAM also boasts a decent amount of "flavors" of functional programming. You can go with Erlang/OTP (the alien tech that has been battle tested for almost 30 years), Elixir for it's great webdev ecosystem, Gleam if you like an ML-like programming language on the BEAM. LFE is also another great option if need a BEAM-native LISP.

agos2• 1 year ago

How I wish that Gleam had OTP!

Elixir is also getting some tooling love in the form of a new language server and some very much appreciated type checking

d3ckard3• 1 year ago

At the same time, the least secret "secret sauce" out there. BBC moved to Elixir (quite recent news), so I guess traction is there.

franticgecko3• 1 year ago

Why Elixir + Erlang are not more popular for high concurrency projects is a mystery to me.

I work at an Erlang shop.

For Erlang to be useful you need to have massive scale, millions of DAU. Yes Elixir might run your website serving thousands of DAU but Erlang and the BEAM was not invented for you. Few companies have the scale that makes Erlang a reasonable choice.

More pressing these days I believe is that the Erlang ecosystem is all or nothing, the BEAM is like its own little operating system and has extremely (IMHO) complicated setup and configuration with many moving parts: ERTS, epmd, Rebar,... You don't need or shouldn't use container tech and k8s with Erlang because it's already doing that stuff in its own Erlang way - but it's the Erlang way it's extremely unique and unfamiliar to most.

When you have the right use case for Erlang and you see it in action it is truly like black magic, it's been a highlight of my career to work with it.

borromakot• 1 year ago

Elixir has been quite easy to set up, configure and deploy, at least for the last 5-6 years. I can't speak for Erlang though.

throwawaymaths2• 1 year ago

elixir softens a whole ton of the sharp edges around getting started and there are only a handful of "gotchas" coming from other hlls (like all terms being immutable when you pass to a function -- but thats honestly almost a problem with the "mainstream" languages).

HappMacDonald• 1 year ago

When we tried to use Elixir Liveview we found that containerizing it (docker compose) was necessary just because of how demanding the runtime environment is regarding keeping modules up to date and synced, and what that requires of the host operating system.

We'll run prod on one server and dev on 3-4 workstations and nothing will match between any of them without a docker container to give this Elixir app a cleanroom environment to work from.

The project we were trying this on eventually ran out of funding before it got off the ground, and we lost access to our main guy who understood Elixir setup really well, so nowadays the rest of us can't even manage to stand up the service to demo it because of all of the moving parts that get angry about not having their environment set up just right.

I've basically found it the only language more difficult than python to set up an environment for. (Well.. the more I think about it, Gradle and every other mobile development stack I have yet seen is literally Satan's armpit..)

With python (though I rarely code in that either) I can stand up almost anything on almost any machine with miniconda and venv and not have to drag Docker into things.

Node/NPM is a prima donna and a PITA but IME as long as you whack it with a wrench long enough following up on each of its complaints then you'll eventually get things running.

My experience still revolves around PHP or Perl or C on the backend, Raw Javascript or sometimes Elm on the front end, and those all seem to be a lot easier to maintain over a timescale of decades as servers update and browsers gobble up new and different features.

---

What I can say in favor of Elixir Liveview is that we built a smooth as hell SPA using that. It was incredibly user friendly to work with and aesthetically amazing, but the maintenance right down at the foundation was the biggest challenge.

michaelcampbell2• 1 year ago

Few companies have the scale that makes Erlang a reasonable choice.

This is a reality that I wish more people would embrace, for so many things.

evnu• 1 year ago

We found Erlang to be the right choice at small scale. Namely, we used it in iot applications, where the self-healing property of proper supervision trees resulted in a very stable implementation. We also saw the same benefits in the cloud part of our application. No complicated k8s setup, just simple supervisor trees.

ludicity• 1 year ago

We swapped our Squarespace website out for a Phoenix application yesterday and it was such a delightful experience.

Thaxll2• 1 year ago

Because it's a single stack that leaks too many things in my opinion, it's not just code but it's also handling infra, process restart, cache, queue, db ect ... And it only works with Erlang, so it's an all or nothing setup which imo is very restrictive.

Kubernetes does a lot of things that Beam does but better and completely language neutral. Then you have builtin queues and db in Erlang but they are inferior to industry standard and again only work with Erlang.

zbentley• 1 year ago

Honestly, that mixing of concerns is the biggest benefit, at least for me.

While Erlang clearly lost the popularity war, using it (well, Elixir in my case) feels like going to an alternate timeline where it wasn’t a given that a good application used separately developed tools for frontend, backend, database, cache, service discovery, load balancing, containerization, orchestration, and so on. We really could have been on a platform that incorporated all of those things into a single runtime.

The way I explain Erlang to folks is: “it’s not a competitor to Python running Django in Gunicorn; it’s a competitor for Python+Django+Gunicorn in Docker on Kubernetes on Linux, talking via a service mesh and storing data in disk-persisted Redis.” In many ways, swapping out only the top of that stack with Erlang is going to leave you worse off than you were before.

Sadly, the Erlang renaissance was years late to the boom of containerization+orchestration+distributed systems, so we’ll never know how good (or bad) things could have been. Ah well, c’est la vie.

schonfinkel3• 1 year ago

Learning to work on the BEAM with Erlang/OTP has been one of the best experiences I had in the past year, I used Joe Armstrong's "Programming Erlang: Software for a Concurrent World" book (and highly recommend it to beginners), I also heard good things about "Designing for Scalability with Erlang/OTP" (but didn't start this one yet), but nothing comes close to this in terms of depth.

The BEAM really feels like alien tech left from a highly advanced civilization and this book dropped in a such a great timing! Bought it right away, kudos to Dr. Erik Stenman for keeping it up after two cancellations!

da022• 1 year ago

What kind of software applications do you develop with BEAM/Erlang/OTP?

schonfinkel3• 1 year ago

Right now they've been mostly toy projects, the more complex one being the back-end of an (WIP) MMO game (https://github.com/Dr-Nekoma/lyceum) and a couple handy libraries that I wrote myself (like https://github.com/dont-rely-on-nulls/migraterl).

fennecfoxy• 1 year ago

Oh I thought this was gonna be about BEAM as in https://smfr.org/robots/ ha ha.

einpoklum• 1 year ago

I've not used Erlang before (and naturally have not read the BEAM book); I mostly live in the world of C++ (and CUDA/OpenCL) these days. Would this be of interest to me?

sgarland• 1 year ago

TIL that Klarna runs on Erlang.

bicx• 1 year ago

Elixir and BEAM are my all-time favorite choice for building networked or pipeline-heavy systems. I used it every day in production for several years, and while it’s a hard sell for recent projects (and generally the wrong call), I enjoy keeping up with it as much as I can.

Thank you for writing this book! I really wanted this a few years ago as I was debugging production Elixir, but existing learning sources were pretty dense and dry (or too simple and shallow).

rconti2• 1 year ago

Best guess:

https://en.wikipedia.org/wiki/BEAM_(Erlang_virtual_machine)

bmitc3• 1 year ago

Yes, that's explained in the book's title.

rconti2• 1 year ago

The book's title, "Understanding the Erlang Runtime System", contains 25% of the words represented in the BEAM acronym, "Bogdan's Erlang Abstract Machine".

maerch• 1 year ago

Issue #113 - “Please continue being awesome.” That emoji-laced drive-by encouragement (August 2018) still pops into my head whenever motivation dips.

This warms my heart. While the internet is infamous for its negativity and how it makes people miserable, even small positive moments like this can make a lasting difference and remain memorable years later.

jillesvangurp• 1 year ago

It's something you can apply in your own life. If you think someone did something nice or good, just tell them. Don't make a big thing out of it; but just make sure to let them know when you get the opportunity. Most people will really appreciate that and might get motivated by that. This sounds simple but a lot of people don't do this or are a bit shy about it. Of course the value of your compliments decreases with the frequency you give them so it helps being a bit genuine about it and to not overdue it. Something simple as using the star button in github, adding a little thumbs up to an issue in an issue tracker, or upvoting a comment on HN is what keeps the good stuff going.

A lot of stuff that people do for free is rather thankless work except for the occasional appreciation. I've been maintaining some only modestly popular OSS projects on Github. They won't change the world and I mostly do it because it serves my own needs. But getting the occasional outreach from people that used some of my code is always a highlight in my day.

pyuser583• 1 year ago

I keep hearing my marvelous promises about the BEAM, but the adoption is still so low. Why?

heeton• 1 year ago

I understand it’s poorly promoted by the biggest users. But more of the web and world infrastructure runs on it than you realise.

Here’s an old post with some examples - https://www.erlang-solutions.com/blog/which-companies-are-us...

rdtsc• 1 year ago

It's not being promoted much. There are no BEAM commercials during the Super Bowl. That is to say that there is no big company promoting it. Sun pushed Java hard, Google pushed Go, Mozilla pushed Rust and so on.

But those who know, know. I mean it's on the front page of HN pretty often.

cgopalan• 1 year ago

This looks amazing purely from an engineer's perspective that wants to level up on something they have worked on for a while with enough understanding to build working systems with it. Just confirming, this is more useful for developers that have worked with Erlang/Beam correct? Not so useful for a Beam newcomer?

Why I wrote the BEAM book

Related Stories