Live data from Hacker News

What years of production-grade concurrency teaches us about building AI agents

georgeguimaraes.com

11–20 of 53 posts

Re: What years of production-grade concurrency teaches us about building AI agents

#11
post #7

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.

Interesting take. I’m an Elixir fanboy because I find LiveView to be very slim. You’re just sending state diffs over WebSocket and updating the DOM with MorphDOM. The simplicity is incomparable to state of the art with JavaScript frameworks in my humble opinion.

Re: What years of production-grade concurrency teaches us about building AI agents

#13
post #2

Broadly 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…

> Even if you use heavyweight OS threads, I just don't believe this matters.

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

#16

I 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.

100% agreed

Re: What years of production-grade concurrency teaches us about building AI agents

#17

Surely they mean Erlang not Elixir

Sounds to me like they mean “BEAM” rather than a specific language. But BEAM means Elixir for most newcomers.

Which is a real shame as if you actually spend some time with both you’ll probably eventually realise erlang is the nicer language.

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

#18

Surely they mean Erlang not Elixir

addressed at the very top of the article

   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

#19
post #7

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.

I'm not sure I agree with the "bloated" description, but I will say that I really like Elixir, and really dislike LiveView. Which is a shame, because the latter is pretty inescapable in Elixir world these days.

Re: What years of production-grade concurrency teaches us about building AI agents

#20

I 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.

I ran into this question when thinking about the approach for a recent project. Yes CLI coding tools are good agents for interactive use, but if you are building a product then you do need an agent abstraction.

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)

Post reply on HN