This is all well and good but Elixir with Phoenix and Liveview is super bloated and you have to have a real reason to buy into such a monster that you couldn't do with a simpler stack.
What years of production-grade concurrency teaches us about building AI agents
11–20 of 53 posts
Re: What years of production-grade concurrency teaches us about building AI agents
#12Re: What years of production-grade concurrency teaches us about building AI agents
#13Broadly agree with the author's points, except for this one: > TypeScript/Node.js: Better concurrency story thanks to the event loop, but still fundamentally single-threaded. Worker threads exist but they're heavyweight OS threads, not 2KB processes. There's no preemptive scheduling: one CPU-bound operation blocks everything. This cannot be a real protest: 100% of the time spent in agent frameworks is spent ... waiti…
It matters a lot. How many OS threads can you run on 1 machine? With Elixir you can easily run thousands without breaking a sweat. But even if you need only a few agents on one machine, OS thread management is a headache if you have any shared state whatsoever (locks, mutexes, etc.). On Unix you can't even reliably kill dependent processes[1]. All those problems just disappear with Elixir.
[1] https://matklad.github.io/2023/10/11/unix-structured-concurr...
Re: What years of production-grade concurrency teaches us about building AI agents
#14Surely they mean Erlang not Elixir
Re: What years of production-grade concurrency teaches us about building AI agents
#15Re: What years of production-grade concurrency teaches us about building AI agents
#16I don’t see the point of agent frameworks. Other than durability and checkpoints how does it help me? Claude code already works as an agent that calls tools when necessary so it’s not clear how an abstraction helps here. I have been really confused by langchain and related tech because they seem so bloated without offering me any advantages? I genuinely would like to know what I’m missing.
Re: What years of production-grade concurrency teaches us about building AI agents
#17Surely they mean Erlang not Elixir
Sounds to me like they mean “BEAM” rather than a specific language. But BEAM means Elixir for most newcomers.
Elixir just feels… Like it’s a load of pre-compile macros. There’s not even a debugger.
Re: What years of production-grade concurrency teaches us about building AI agents
#18Surely they mean Erlang not Elixir
A note on terminology: Throughout this post I refer to "the BEAM." BEAM is
the virtual machine that runs both Erlang and Elixir code, similar to how the
JVM runs both Java and Kotlin. Erlang (1986) created the VM and the
concurrency model. Elixir (2012) is a modern language built on top of it with
better ergonomics. When I say "BEAM," I mean the runtime and its properties.
When I say "Elixir," I mean the language we write.Re: What years of production-grade concurrency teaches us about building AI agents
#19This is all well and good but Elixir with Phoenix and Liveview is super bloated and you have to have a real reason to buy into such a monster that you couldn't do with a simpler stack.
Re: What years of production-grade concurrency teaches us about building AI agents
#20I don’t see the point of agent frameworks. Other than durability and checkpoints how does it help me? Claude code already works as an agent that calls tools when necessary so it’s not clear how an abstraction helps here. I have been really confused by langchain and related tech because they seem so bloated without offering me any advantages? I genuinely would like to know what I’m missing.
You could package Claude Code into the product (via agents-sdk or Claude -p) and have it use the API key (with metered billing) but in my case I didn’t find it ergonomic enough for my needs, so I ended up using my own agent framework Langroid for this.
https://github.com/langroid/langroid
(No it’s not based on that similarly named other framework, it’s a clean, minimal, extensible framework with good dx)