Oh wow, I never knew Klarna uses BEAM. I always thought BEAM is vastly underrated and it's even hard for me to convince clients of showing how powerful it (Elixir/BEAM) really is, especially when they're already on something like NodeJS. This will be a nice reference to use in conversations with future prospects.
To add on to your statement that the BEAM is vastly underrated, it's the only runtime that I know of that has enabled multiple small sub 50 people teams to scale to millions of daily active users.
There will be winners in this new AI age, and they will be the ones that are technically better, rather than the most popular or convenient for software engineers
I use Elixir (BEAM-based), with LLMs daily, on a fast growing site (current pace is 5 billion HTTP queries per year on a single front node).
Elixir is well handled by LLMs at this point, and we keep the “easy to scale and maintain” aspect (operational characteristics of the runtime are very good).
I can safely say that total cost of ownership is excellent.
Fair enough! That’s how we track growth, it’s easier to communicate to state sponsors.
Roughly 14M per day, but growing 2.5 to 3 on a YoY basis.
My point stands though: much more serenity in ops with that growth, and LLMs do work nicely, especially when most of the code is stateless by language design.
~160 req/s on average, higher peaks. Not trying to impress anyone though, my point was that LLMs work perfectly fine on an Elixir codebase, and that we get future-proof ops on a single node with zero issues. In my experience, it has been easier than with any other stack I've tried.
To be fair, Erlang runtime semantics (cooperative "async threads") never needed changing to tackle C10k problem, they got that right as part of the early designs before C10k was even on the tasble.
Everyone else just moved towards the same kind of cooperative thread runtime semantics (even if the lingo differs, async in C#, callbacks first, then async in NodeJS, virtual threads in Java, async in C++ and so on).
I think an interesting historical tidbit is that Java actually had M:N threading in early versions (1.1, 1.2, 1.3?) that got ripped out because it was deemed complex and error-prone since people back then often did native bindings naively (And perhaps file/socket API's were less complete?) only for them to reintroduce it again in Java 20 I think it was under the virtual threads name?
The important metrics is peak requests per second. 14M / day sounds impressive, but it’s only a sustained 160 per second which literally any language and framework can handle on the lowest end hardware.
Sure, peaks are much higher. But a good part of it is reverse proxying with in-memory caching and locking, which I've implemented in several stacks over the years, and many struggle with it (I have been paid to do comprehensive benchmarks on the topic). On the BEAM it's a non-event.
> I have done several experiments where, the only difference are a couple of paragraphs describing the technology stack for the AI tools.
The differences emerge as the project goes on. Comparing feature velocity and defect count is difficult unless your experiment is to build the same project over a long timeframe across several languages. Then winners would indeed emerge, but then that's only in the context of whatever domain said project is tackling. For instance, if concurrency or infrastructure isn't a large part of the complexity, BEAM languages might not confer much benefit.
neya | 10 hours ago
worthless-trash | 6 hours ago
jurgemaister | 3 hours ago
troupo | an hour ago
vmg12 | 27 minutes ago
oivaksef | 6 hours ago
thibaut_barrere | 5 hours ago
Elixir is well handled by LLMs at this point, and we keep the “easy to scale and maintain” aspect (operational characteristics of the runtime are very good).
I can safely say that total cost of ownership is excellent.
valzam | 5 hours ago
thibaut_barrere | 4 hours ago
Roughly 14M per day, but growing 2.5 to 3 on a YoY basis.
My point stands though: much more serenity in ops with that growth, and LLMs do work nicely, especially when most of the code is stateless by language design.
shakna | 3 hours ago
thibaut_barrere | 3 hours ago
whizzter | 38 minutes ago
Everyone else just moved towards the same kind of cooperative thread runtime semantics (even if the lingo differs, async in C#, callbacks first, then async in NodeJS, virtual threads in Java, async in C++ and so on).
I think an interesting historical tidbit is that Java actually had M:N threading in early versions (1.1, 1.2, 1.3?) that got ripped out because it was deemed complex and error-prone since people back then often did native bindings naively (And perhaps file/socket API's were less complete?) only for them to reintroduce it again in Java 20 I think it was under the virtual threads name?
Zanfa | 3 hours ago
thibaut_barrere | 3 hours ago
kryptiskt | 15 minutes ago
te_chris | 3 hours ago
pjmlp | 2 hours ago
I have done several experiments where, the only difference are a couple of paragraphs describing the technology stack for the AI tools.
Hardly any different than changing the target CPU architecture on a compiler output.
Quite sad, as now the fun of why language X instead of Y is gone.
aeonfox | 2 hours ago
The differences emerge as the project goes on. Comparing feature velocity and defect count is difficult unless your experiment is to build the same project over a long timeframe across several languages. Then winners would indeed emerge, but then that's only in the context of whatever domain said project is tackling. For instance, if concurrency or infrastructure isn't a large part of the complexity, BEAM languages might not confer much benefit.
ValtteriL | 5 hours ago
sharts | 3 hours ago
bpbp-mango | 2 hours ago