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

Go is a good fit for agents

docs.hatchet.run

Post reply on HN
Print view View original

31–40 of 183 posts

Re: Go is a good fit for agents

#31

Post by tptacek »

_QrE wrote: post #27

I'm not sure how valid most of these points are. A lot of the latency in an agentic system is going to be the calls to the LLM(s). From the article: """ Agents typically have a number of shared characteristics when they start to scale (read: have actual users): They are long-running — anywhere from seconds to minutes to hours. Each execution is expensive — not just the LLM calls, but the nature of the agent is to rep…

That's true from a performance perspective but, in building an agent in Go, I was thankful that I had extremely well-worn patterns to manage concurrency, backlogs, and backpressure given that most interactions will involve one or more transactions with a remote service that takes several seconds to respond.

(I think you can effectively write an agent in any language and I think Javascript is probably the most popular choice. Now, generating code, regardless of whether it's an agent or a CLI tool or a server --- there, I think Go and LLM have a particularly nice chemistry.)

Re: Go is a good fit for agents

#32

Post by abelanger »

skybrian wrote: post #20

For long-running, expensive processes that do a lot of waiting, a downside is that if you kill the process running the goroutine, you lose all your work. It might be better to serialize state to a database while waiting? But this adds a lot of complexity and I don’t know any languages that make it easy to write this sort of checkpoint-based state machine.

OP here - this type of "checkpoint-based state machine" is exactly what platforms which offer durable execution primitives like Hatchet (https://hatchet.run/) and Temporal (https://temporal.io/) are offering. Disclaimer: am a founder of Hatchet.

These platforms store an event history of the functions which have run as part of the same workflow, and automatically replay those when your function gets interrupted.

I imagine synchronizing memory contents at the language level would be much more overhead than synchronizing at the output level.

Re: Go is a good fit for agents

#34

Post by npalli »

Agents to do what? Take ML/AI, all the infra and tools are Python/C++ so what exactly is the Agent going to help you with Go? Many such domains- gaming, HFT, HPC, Scientific Computing, Systems, UX, Enterprise etc. etc. Seems it really helps Go's sweet spot - CLI's and Networking services.

Re: Go is a good fit for agents

#35

Post by tptacek »

npalli wrote: post #34

Agents to do what? Take ML/AI, all the infra and tools are Python/C++ so what exactly is the Agent going to help you with Go? Many such domains- gaming, HFT, HPC, Scientific Computing, Systems, UX, Enterprise etc. etc. Seems it really helps Go's sweet spot - CLI's and Networking services.

Agents mostly don't run ML/AI code; they're a structured loop around LLM calls and exist mostly to give an LLM access to local tools in some application domain; think "reading my email for me" rather than "driving ML systems".

Re: Go is a good fit for agents

#36

Post by tptacek »

abelanger wrote: post #32
skybrian wrote: post #20

For long-running, expensive processes that do a lot of waiting, a downside is that if you kill the process running the goroutine, you lose all your work. It might be better to serialize state to a database while waiting? But this adds a lot of complexity and I don’t know any languages that make it easy to write this sort of checkpoint-based state machine.

OP here - this type of "checkpoint-based state machine" is exactly what platforms which offer durable execution primitives like Hatchet ( https://hatchet.run/ ) and Temporal ( https://temporal.io/ ) are offering. Disclaimer: am a founder of Hatchet. These platforms store an event history of the functions which have run as part of the same workflow, and automatically replay those when your function gets interrupted. I…

This is also how our orchestrator (written in Go) is structured. JP describes it pretty well here (it's a durable log implemented with BoltDB).

https://fly.io/blog/the-exit-interview-jp/

Re: Go is a good fit for agents

#37

Post by philwelch »

_QrE wrote: post #27

I'm not sure how valid most of these points are. A lot of the latency in an agentic system is going to be the calls to the LLM(s). From the article: """ Agents typically have a number of shared characteristics when they start to scale (read: have actual users): They are long-running — anywhere from seconds to minutes to hours. Each execution is expensive — not just the LLM calls, but the nature of the agent is to rep…

Go still has a much better concurrency story. It’s also much less of a headache to deploy since all you need to deploy is a static binary and not a whole bespoke Python runtime with every pip dependency.

Re: Go is a good fit for agents

#38

Post by eikenberry »

kamikaz1k wrote: post #11

> High concurrency > Share memory by communicating > Centralized cancellation mechanism with context.Context > Expansive standard library > Profiling > Bonus: LLMs are good at writing Go code I think profiling is probably the lowest value good here, but would be willing to hear out stories of AI middleware applications that found value in that. Cancelling tasks is probably the highest value good here, but I think the…

> Bonus: LLMs are good at writing Go code

Good at writing bad code. But most of the code in the wild is written by mid-level devs, without guidance and on short timelines.. i.e bad code. But this is a problem with all languages, not just Go.

Re: Go is a good fit for agents

#39

Post by TypingOutBugs »

philwelch wrote: post #37
_QrE wrote: post #27

I'm not sure how valid most of these points are. A lot of the latency in an agentic system is going to be the calls to the LLM(s). From the article: """ Agents typically have a number of shared characteristics when they start to scale (read: have actual users): They are long-running — anywhere from seconds to minutes to hours. Each execution is expensive — not just the LLM calls, but the nature of the agent is to rep…

Go still has a much better concurrency story. It’s also much less of a headache to deploy since all you need to deploy is a static binary and not a whole bespoke Python runtime with every pip dependency.

Go is definitely better, but with uv you can install all dependencies including python with only curl

Re: Go is a good fit for agents

#40

Post by guywithahat »

regularfry wrote: post #15
guywithahat wrote: post #9

Earlier quoted context omitted.

Well elixir doesn't produce goroutines (managed threads), they produce "lightweight processes" which have isolated memory. These are more expensive to grow and aren't as easy to share data between one another, although they're much more fault tolerant as a result. It could be better however the underlying concurrency model in Elixir is relatively unique

It's been a while since I was in the weeds on this, but if I remember correctly they're strictly speaking mostly isolated. Binaries above a certain size share storage between processes, so moving big blobs between processes is cheap.

They also have their own system to share data between processes, although I haven't used it. Generally though it's a unique tool that's not always interchangeable with Go
Post reply on HN