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

11–20 of 183 posts

Re: Go is a good fit for agents

#11

Post by kamikaz1k »

> 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 contending runtimes (TS/Python) all prefer using 3P libraries to handle this kind of stuff, so probably not the biggest deal.

Being able to write good Go code is pretty cool though; I don't write enough to make a judgement there.

Re: Go is a good fit for agents

#12

Post by bheadmaster »

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.

> also the link at the bottom of the page is pretty much why I ditched Go: https://go.dev/blog/error-syntax

Funnily, it's also one of the reasons I stay with Go.

Error handling is the most contraversial Go topic, with half the people saying it's terrible and needs a new syntax, and half saying it's perfect and adding any more syntax will ruin it.

Re: Go is a good fit for agents

#13

Post by jasonthorsness »

Go is great for command-line tools because of library support and fast-starting single-binaries. While most of the benefits in the article are also shared with JavaScript, I wonder if the CLI advantage will help and whether command-line agents will become a thing ("grepllm"?)

The language of agents doesn't matter much in the long run as it's just a thin shell of tool definitions and API calls to the backing LLM.

Re: Go is a good fit for agents

#14

Post by sorentwo »

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.

Absolutely!

Elixir's lightweight processes and distribution story make it ideal for orchestration, and that includes orchestrating LLMs.

Shameless plug, but that's what many people have been using Oban Pro's Workflows for recently, and something we demonstrated in our "Cascading Workflows" article: https://oban.pro/articles/weaving-stories-with-cascading-wor...

Unlike hatchet, it actually runs locally, in your own application as well.

Re: Go is a good fit for agents

#15

Post by regularfry »

guywithahat wrote: post #9
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.

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.

Re: Go is a good fit for agents

#17

Post by jerf »

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.

If it had a larger learning base, quite possibly.

Erlang possibly even more so. The argument that pure code is generally safer to vibe code is compelling to me. (Elixir's purity is rather complicated to describe, Erlang's much more obvious and clear.) It's easier to analyze that this bit of code doesn't reach out and break something else along the way.

Though it would be nice to have a language popular enough for the LLMs to work well on, that was pure, but that was also fast. At the moment writing in pure code means taking a fairly substantial performance hit, and I'm not talking about the O(n log n) algorithm slowdowns, I mean just normal performance.

Re: Go is a good fit for agents

#18

Post by tptacek »

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.

Elixir is great for agents.

Re: Go is a good fit for agents

#19

Post by EGreg »

kweingar wrote: post #16
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.

Why is JS particularly good for agents?

Because it integrates great with browsers and people know the language already for node.js and the packages in npm can work for both?

Re: Go is a good fit for agents

#20

Post by skybrian »

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.
Post reply on HN