I feel sorry for the Ruby/Rails community that this is (was) their main ambassador and in charge of their main conference. Aside from his racism, xenophobia, and other questionable political views, he acts like a complete blowhard and doubles down when he's wrong.

Here he's just outright spreading misinformation just so he can wishcast programming languages and having to think about code away.

I'm glad those in Elixir community like Jose, Zach, and others took the basic effort of challenging the results put out by DHH and what was uncovered was a) Rust version was heavily optimized over several days, 4 contributors, 1 of those contributors being a Rust programmer, and 300+ commits. Meanwhile Elixir/Go were done all by DHH (meat proxy for Claude) as one-shots in 2-3 commits.

Again, as someone currently working as a Rails dev, but use Elixir on side projects, I really feel for the Ruby/Rails community.

https://github.com/elixir-lang/expert

Hi everyone,

I am livestreaming contributions to several Elixir open source projects (sometimes even Elixir itelf) on twitch.tv/josevalim. This is happening at 22:00 CET / 16:00 ET / 13:00 PT from Monday to Thursday.

This has been going for a week and, since I plan to keep on going for now, I thought I would advertise it more strongly. :) So far, we have contributed to Livebook, Elixir, and we are now working on Explorer, going through a variety of languages such as Elixir, JavaScript, C, and Rust.

If you are interested, join us. Have fun and be nice!

EDIT: If you can't attend, video recordings are available for 7 days.

Happy to announce that the 3rd edition of Elixir in Action is now in print 🎉🥳🎊

This edition addresses various deprecations and mistakes that have accumulated over the past 5 years. It also includes a few additions, such as a brief treatment of packaging the release into a Docker container. Finally, the book has received a lovely foreword by Francesco Cesarini (🙏).

You can grab it at 45% off using code pbjuric3 (valid until Feb 27) at https://www.manning.com/books/elixir-in-action-third-edition.

Enjoy the read!

Hey! Just wanted to share (because I’m really happy) that I managed to get a new job (full-time Elixir developer) after 8 years working with JavaScript (Node, React, Vue, etc.). Elixir has always been my hobby language, and I decided to pursue this since I really like investing time in studying it.

I got tired of those “omg it’s so much easier to do this in Elixir than in Node…” moments — all the time at work I was like: “fuck, in Elixir this would be sooo much more efficient to do…” So yes, I decided to apply only for Elixir positions, no matter what (even the ones that required experience). Got ignored in a lot of them, but there’s always one, right? I managed to go through the whole process and got it.

I’m really happy that I will work full-time with Elixir. Hopefully I’ll learn a lot of new skills. But yeah…if I did it, anyone can do it.

Popcorn is a library that lets you run Elixir in the browser using WebAssembly.
It uses tiny Erlang VM – AtomVM – for runtime. This allows it to run your code with minimal changes. Popcorn also gives you APIs for calling JS from Elixir side and the other way around.

It's still in early stages but you can already build some cool things with it – see examples here.

Here is a blogpost detailing what Popcorn is and why we made it: https://blog.swmansion.com/popcorn-bringing-elixir-to-the-browser-8993a58a00be

We would love to hear about your ideas, use-cases, and any bugs you encountered. Feel free to let us know what you think here, on our Discord, or on Github.

Happy popping 🍿

I've been building Stampede, a load tester for Phoenix that speaks Channels and LiveView, and I wanted to see how far one server could go with realistic traffic. Last time I got to 600,000 users on a 4-core server, so this time I scaled up.

Setup:

- One AWS r7g.4xlarge (16 cores, 128 GB) running a fresh Phoenix app, with only its connection limits raised

- Eight r7g.xlarge machines running Stampede

- Every user acts like the Phoenix JS client: joins a channel, sends a heartbeat every 30 seconds and a message every 30 to 60

- The load went up 250,000 users at a time, each step held for a minute, and a step only passed with joins and messages under 1 second at p95 and 0 errors

Results:

- 1,000,000 users: held, server at 37-48% CPU, 52 GB memory

- 1,500,000 users: held, 54-60% CPU, 77 GB

- 2,000,000 users: held, 78-84% CPU, 103 GB

- 2,250,000 users: the CPU ran out

The first error came at 2.07M, so 2M is the number. Memory worked out to about 51 KB per user, and CPU was what ran out, since 2 million users send well over 100,000 heartbeats and messages a second.

For comparison, the Phoenix team held 2M idle connections on a 40-core machine back in 2015. This was 16 cores with every user active, which says a lot about how far the BEAM has come.

Everything to rerun it, plus the logs from this run, is in the repo: https://github.com/mandar1045/stampede

Happy to answer questions about the setup. Getting past the ~64k ports per client address took a few tricks.