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

81–90 of 183 posts

Re: Go is a good fit for agents

#81

Post by autogn0me »

fritzo wrote: post #76
lunarcave wrote: post #73

Agents easily spend >90% of their time waiting for LLMs to reply and optionally executing API calls in other services (HTTP APIs and DBs). In my experience the performance of the language runtime rarely matters. If there ever was a language feature that matters for agent performance and scale, it's actually the performance of JSON serialization and deserialization.

In my experience, the 2nd most costly function in agents (after LLM calls) is diffing/patching/merging asynchronous edits to resolve conflicts. Those conflict resolution operations can call out to low-level libraries, but they are still quite expensive optimization problems, compared to serialization etc.

can you be more specific about this?

Re: Go is a good fit for agents

#82

Post by guywithahat »

arthurcolle wrote: post #64

Erlang is a way better fit for a distributed agent orchestration layer. You have a ton of dependencies, over network and maybe in userspace, you have a lot of inter-operability and reliability constraints, you want to hotswap code and capabilities at runtime, without degrading the overall system performance. And you get networking/distribution/async message passing for free https://github.com/arthurcolle/agents.erl I…

If you don't mind me asking why would one use Erlang over Elixir?

Re: Go is a good fit for agents

#84

Post by ramesh31 »

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

Agents are the orchestration layer, i.e. a perfect fit for Go (or Erlang, or Node). You don't need a "mountain of AI-related libraries" for them, particularly given the fact that what we call an agent now has only existed for less than 2 years. Anything doing serious IO should be abstracted behind a tool interface that can (and should) be implemented in whatever domain specific tooling is required.

Re: Go is a good fit for agents

#85

Post by trevinhofmann »

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.

I've been considering good ways to use a task queue for this, and might just settle for a rudimentary one in a Postgres table.

The upside is that agent subtasks can be load balanced among servers, tasks won't be dropped if the process is killed, and better observability comes along with it.

The downside is definitely complexity. I'm having a hard time planning out an architecture that doesn't significantly increase the complexity of my agent code.

Re: Go is a good fit for agents

#86

Post by trevinhofmann »

rednafi wrote: post #74
odyssey7 wrote: post #8

AI engineers will literally invent a new universe before they touch JavaScript. The death knell for variety in AI languages was when Google rug-pulled TensorFlow for Swift.

This is the way. JS is a terrible language to begin with, and bringing it to the backend was a mistake. TS doesn’t change the fact that the underlying language is still a pile of crap. So, like many, I’ll write anything—Go, Rust, Python, Ruby, Elixir, F#—before touching JS or TS with a ten-foot pole.

This doesn't contribute much to the discussion.

Use whatever language works well for you and the task at hand, but many enjoy fullstack JS/TS.

Re: Go is a good fit for agents

#87

Post by dpkirchner »

dpe82 wrote: post #23
odyssey7 wrote: post #8

AI engineers will literally invent a new universe before they touch JavaScript. The death knell for variety in AI languages was when Google rug-pulled TensorFlow for Swift.

Avoiding JavaScript like the plague that it is, is not unique to AI engineers. -Someone who has written a ton of JS over the past... almost 30 years now.

Choosing Python over JavaScript is one of the more perplexing decisions I've seen.

Re: Go is a good fit for agents

#88

Post by eru »

guywithahat wrote: post #82
arthurcolle wrote: post #64

Erlang is a way better fit for a distributed agent orchestration layer. You have a ton of dependencies, over network and maybe in userspace, you have a lot of inter-operability and reliability constraints, you want to hotswap code and capabilities at runtime, without degrading the overall system performance. And you get networking/distribution/async message passing for free https://github.com/arthurcolle/agents.erl I…

If you don't mind me asking why would one use Erlang over Elixir?

Erlang has better syntax than Elixir.

But otherwise they are mostly the same: Elixir is just an Erlang reskin.

So pretty much wherever you can use one, you can use the other.

Re: Go is a good fit for agents

#90

Post by fixprix »

lunarcave wrote: post #73

Agents easily spend >90% of their time waiting for LLMs to reply and optionally executing API calls in other services (HTTP APIs and DBs). In my experience the performance of the language runtime rarely matters. If there ever was a language feature that matters for agent performance and scale, it's actually the performance of JSON serialization and deserialization.

Yep exactly, might as well use a language that works with JSON natively like TypeScript; which has arguably far more powerful type system than Go.
Post reply on HN