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

41–50 of 183 posts

Re: Go is a good fit for agents

#41

Post by skybrian »

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…

Yep, though I haven’t used them, I’m vaguely aware that such things exist. I think they have a long way to go to become mainstream, though? Typical Go code isn’t written to be replayable like that.

Re: Go is a good fit for agents

#42

Post by achileas »

tptacek wrote: post #35
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".

That doesn't negate what OP was saying at all, the better support in Python isn't for "running ML/AI code" but in things like agent frameworks, observability tools, SDKs, etc. None of which directly run AI code but are still helpful/necessary and for the most part better represented (and supported) in the Python world, although that seems like it's slowly changing.

Re: Go is a good fit for agents

#43

Post by achileas »

awinter-py wrote: post #21

oh my god these things run on a gpu don't they? they have nothing to do with golang? to the extent they run on a cpu they're heavy; we're not like solving the c10k problem with agents

Agents don't typically, and any LLM they're calling is likely hosted remotely.

Re: Go is a good fit for agents

#44

Post by InTheArena »

I don't think I agree with the Go is good in LLMs.

But outside of that - ML in go is basically impossible. Trying to integrate with the outside ecosystem of go is really difficult - and my experience has been that Claude Code is far less effective with Go then it is with Python, or even Swift.

I ditched a project I was writing in Go and replaced it with Swift (this was mostly prompt based anyways). It was remarkably how much better the first pass of the code generation was.

Re: Go is a good fit for agents

#45

Post by achileas »

behnamoh wrote: post #2

> concurrency by that logic Elixir is even better for agents. also the link at the bottom of the page is pretty much why I ditched Go: https://go.dev/blog/error-syntax The AI landscape moves so fast, and this conservative, backwards looking mindset of the new Go dev team doesn't match the forward looking LLM engineering mindset.

This makes me want to build agents in Elixir now

Re: Go is a good fit for agents

#46

Post by abelanger »

skybrian wrote: post #41
abelanger wrote: post #32

Earlier quoted context omitted.

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…

Yep, though I haven’t used them, I’m vaguely aware that such things exist. I think they have a long way to go to become mainstream, though? Typical Go code isn’t written to be replayable like that.

I think there's a gap between people familiar with durable execution and those who use it in practice; it comes with a lot of overhead.

Adding a durable boundary (via a task queue) in between steps is typically the first step, because you at least get persistence and retries, and for a lot of apps that's enough. It's usually where we recommend people start with Hatchet, since it's just a matter of adding a simple wrapper or declaration on top of the existing code.

Durable execution is often the third evolution of your system (after the first pass with no durability, then adding a durable boundary).

Re: Go is a good fit for agents

#47

Post by pantsforbirds »

I've been messing around with an Elixir + BEAM based agent framework. I think a mixture of BEAM + SQLite is about as good as you can get for agents right now.

You can safely swap out agents without redeploying the application, the concurrency is way below the scale BEAM was built for, and creating stateful or ephemeral agents is incredibly easy.

My plan is to set up a base agent in Python, Typescript, and Rust using MCP servers to allow users to write more complex agents in their preferred programming language too.

Re: Go is a good fit for agents

#48

Post by abelanger »

tptacek wrote: post #36
abelanger wrote: post #32

Earlier quoted context omitted.

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/

Nice! It makes a lot of sense for orchestrating infra deployments -- we also started exploring Temporal at my previous startup for many of the same reasons, though at one level higher to orchestrate deployment into cloud providers.

Re: Go is a good fit for agents

#49

Post by tptacek »

achileas wrote: post #42
tptacek wrote: post #35

Earlier quoted context omitted.

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

That doesn't negate what OP was saying at all, the better support in Python isn't for "running ML/AI code" but in things like agent frameworks, observability tools, SDKs, etc. None of which directly run AI code but are still helpful/necessary and for the most part better represented (and supported) in the Python world, although that seems like it's slowly changing.

There are agent frameworks in most languages at this point so the question just comes down to "can you invoke tools for the problem you want to solve in that language". Yes, Python is really great at that. So is Go and Javascript.

I think I'd condense this out to "this is not a really important deciding factor in what language you choose for your agent". If you know you need something you can only get in Python, you'll write the agent in Python.

Post reply on HN