Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

georgeguimaraes.com

Post reply on HN
Print view View original

51–53 of 53 posts

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

#51

Post by hugobarauna »

mackross wrote: post #23

I’m a huge elixir fan, but imho it doesn’t solve durable execution out of the box which is a major problem that often gets swept under the rug by BEAM fanboys. Because ETS and supervision trees don’t play well with deployment via restart, you’ve got to write some level of execution state to relational database or files. You can choose persistent ETS, mnesia, etc, (which have their own tradeoffs and come with some kin…

Regarding adding persistence, people in the community are already building solutions, like: https://github.com/ChristianAlexander/durable_object

The good thing about those, IMO, is that they’re leveraging everything that’s already in BEAM/OTP, so there’s no need to reinvent the harder parts. They “only” add some extra features (like persistence of processes/GenServers between restarts) and higher-level abstraction APIs.

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

#52

Post by NortySpock »

quadruple wrote: post #39
asa400 wrote: post #37

Earlier quoted context omitted.

You can (and should) always handle whatever errors you actually want to and are able handle, so if that means catching a lot of them and forwarding them to a model, that's not a problem. The benefit comes mainly from what happens when you encounter unknown errors or errors that you can't handle or errors that would get you into an invalid state. It's normal in BEAM languages to handle the errors you want to/can handl…

It doesn't sound strange, it actually sounds sane and what everyone should be doing. At the same time, I can't imagine the last time I had a random exception I didn't think about in prod, but I guess that's the whole point of the BEAM, just don't think about it at all. I might take a stab at Elixir, the concepts seem interesting and the syntax looks to be up my alley.

Here was my recent pitch on why I like Elixir: https://news.ycombinator.com/item?id=45896313

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

#53

Post by mackross »

hugobarauna wrote: post #51
mackross wrote: post #23

I’m a huge elixir fan, but imho it doesn’t solve durable execution out of the box which is a major problem that often gets swept under the rug by BEAM fanboys. Because ETS and supervision trees don’t play well with deployment via restart, you’ve got to write some level of execution state to relational database or files. You can choose persistent ETS, mnesia, etc, (which have their own tradeoffs and come with some kin…

Regarding adding persistence, people in the community are already building solutions, like: https://github.com/ChristianAlexander/durable_object The good thing about those, IMO, is that they’re leveraging everything that’s already in BEAM/OTP, so there’s no need to reinvent the harder parts. They “only” add some extra features (like persistence of processes/GenServers between restarts) and higher-level abstraction AP…

Durable objects looks interesting! Thanks for the link
Post reply on HN