I started learning Erlang recently and, honestly, I was expecting a dumpster fire based on negative comments I have seen online. To my surprise, I am really enjoying the language. As a person who loves Haskell, I expected the dynamic typing to be abhorrent, but this is not the case. Erlang is clearly a language and runtime in which you can be productive and get things done without many obstacles.

Two thumbs up from me. I am going to keep going on this journey.

I talked with a Bleacher Report developer, and it was said that the team there has happily moved on from OTP (my guess, some Phoenix) from their stack. I was surprised to hear this. But it does seem to happen (Facebook chat comes to mind). Anyone care to chime in on this who knows more? Did Rubyists cobble infrastructure together with no regard to OTP over there? I, for one, have seen crappy OTP codebases that certainly doesn't help a fast-moving company -- I know a company's codebase is only as good as the company's technical talent and leadership.

N.B. I have no idea when this happened over at BR. Or to what extent. I believe they have more-or-less removed OTP from their stack from what I was told.

Some might like to read it :)

https://boragonul.com/post/falling-in-love-with-erlang

Although many posts here garner zero comments, whether they refer to a blog post or a vlog post or are just "I did a cool thing," I learn something from every one of you, so please keep up the good work, and Thank You!

Last month, our colleague Lukas Larson launched the JIT compiler for the BEAM VM. The JIT compiler offers a performance boost of anything from 30% to 130% increase in the number of iterations per second. In our latest blog, Lukas demonstrates the performance testing of the JIT Read more at https://www2.erlang-solutions.com/jitblog2

Ok the Erlang 28 RC release note made me laugh.

Erlang/OTP 28.0 Release Candidate 1 - Erlang/OTP

The size of an atom in the Erlang source code was limited to 255 bytes in previous releases, meaning that an atom containing only emojis could contain only 63 emojis. While atoms are still only allowed to contain 255 characters, the number of bytes is no longer limited.

Wouldn't 63 Emojs be more than enough to give an atom a unique name?

I was in the Golang subreddit speaking about my new business and they got mad because I told them that the BEAM is better than Golang in certain problem sets. I built a Golang SDK just for them so they could get the reliability the BEAM could offer in serverless, and they downvoted my post. So I was curious what you guys think. I'm open to all criticism and feedback, but I truly cannot imagine any design coming close. I may have learned the BEAM with AI after getting laid off, but I feel like my years of operations work with Java, Golang, and Python stacks in serverless make me more pissed off than you all. Lol JK, I just wanted to get you excited for the design. I promise I'm humble.

If you have no idea what the internet was like before TCP — to send a file over the internet you had to know C. It was a huge pain in the ass. If you missed a chunk of data you had to rewrite the program. Every developer had their own custom retry logic. Everyone just sent packets as fast as possible with no appreciation for pacing. Then a small team — Vint Cerf and Bob Kahn — wrote TCP and it became the most foundational algorithm of the entire internet. We built the modern web, APIs, and databases on top of that algorithm. Sending email became trivial.

One more story that is important before my design: before Ericsson, in order to make a call there was a human switch operator. If the switch was full, the caller would be rejected. It didn't matter if the caller had an emergency — the model was first come, first served. Ericsson built the runtime to deal with concurrent processes with isolation boundaries that would make sure telecom systems were resilient to crashes.

Now on to my design. Agent retry storms are coming for everyone's APIs. A human being might visit 10–30 websites and call APIs maybe 20 times. The Cloudflare CEO said it plainly at SXSW this year: "Your agent will often go to a thousand times the number of sites a human would — it might go to 5,000 sites. And that's real traffic, and that's real load." Those agents will call APIs as fast as possible. The APIs will throw 429s, which inspires the servers to send more requests. The servers of the API will slow down, which will inspire clients to send more until it crashes. The fleet of machines that was over capacity at N machines will find only a ticking time bomb before N-1 machines handle the same capacity. The autoscalers will provision new machines and warm up — but crash before the entire fleet is down.

Enter EZThrottle. The same way Ericsson absorbs bursts of call requests and routes them to the best switch, EZThrottle queues, paces, and reroutes API calls past partial outages — in both directions. It protects the APIs you call and the API you run. It solves the noisy neighbor problem by giving each user their own queue. When it receives a 500, it uses the Fly.io network to send directly to another region to see if it works over there. It's what Cloudflare is for inbound traffic, but for your outbound API calls. Stripe, Google, OpenAI, and your gateway server could all be having partial outages and EZThrottle will fight to get each call through. No cold starts. No performance choking on retry storms. No spiky traffic — just smooth, predictable requests sent at the pace the API can actually handle. The resilience of the BEAM in your non-BEAM services.

I've linked the actual writeups below, but tell me — have you ever seen a more elegant architecture on the BEAM?

https://ezthrottle.network/blog/making-failure-boring-again
https://ezthrottle.network/blog/serverless-2-rip-operations
https://ezthrottle.network/blog/a-queue-per-user-at-scale

Open source version

https://github.com/rjpruitt16/ezthrottle-local

I don't know much about Erlang, I am not an Erlang programmer. I do most of my stuff in C,Python or Lua. Ever since I read about how cool Erlang's microprocesses are, I've been wanting to do a very tiny VM in C that I can plug into Lua to get true parallelism into it, most current Lua libraries for that are kind of inefficient.

However for the most part, every time I try to Google for a meaningful resource on how they were written, all I get is articles about how Erlang microprocesses are the new hot cakes of programming, but nothing meaningful to my query. So I would like to ask the nice people of the Erlang community of Reddit, who ought to know more about Erlang's innards than I do, a couple of things:

• Are there any good articles dissecting the implementation of microprocesses in Erlang's VM, and how they are abstracting it from the OS's threading model?

• How are the microprocesses spawned/killed/talked-to/interacted-with in Erlang, from a syntax standpoint.

Thanks!