Live data from Hacker News

Go is a good fit for agents

docs.hatchet.run

71–80 of 183 posts

Re: Go is a good fit for agents

#71

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…

you should check out the Extism[0] project and the Elixir SDK[1]. This would allow you to write the core services, routing, message passing, etc in Elixir, and leverage all the BEAM/OTP have to offer, and then embed "agents" written in other languages which are small Wasm modules that act like in-process plugins.

[0]: https://github.com/extism/extism [1]: https://github.com/extism/elixir-sdk

Re: Go is a good fit for agents

#72

Rust is a way better option, not sure why it isn't being mentioned. The issue with Go, is as soon as you need to do actual machine learning it falls down. The issue with Python is that you often want concurrency in agents. Although this may be solved with Pythons new threading. Why is Rust great? It interops very well with Python, so you can write any concurrent pieces into that and simply import it into py, without…

Not every post about Go needs to mention Rust. Rust has its niche and so does Go. Both kind of suck at AI.

LLM researchers care about neither since Rust comes with its own headache: learning curve, slow compilation, weak stdlib, and Go’s FFI story is just sad. It’s still Python or GTFO.

That said, Go is great to whip up “agents” since it’s a nicer language to write networking and glue code, which is what agents are. Other than a few niche groups, I’ve seen a lot more agents written in Go than in Rust.

Re: Go is a good fit for agents

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

Re: Go is a good fit for agents

#74
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.

Re: Go is a good fit for agents

#75
post #69

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…

I came here to say that too. It already does well coordinating IoT networks. It's probably one of the most underestimated systems. The Elixir community has been working hard to be able to run models directly within BEAM, and recently, have added the capability for running Python directly.

Haha I wrote https://github.com/stochastic-thread/snek.ex 10 yrs ago

What are they doing with Python on the BEAM these days? I'm OOTL

Re: Go is a good fit for agents

#76

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.

Re: Go is a good fit for agents

#77
post #69

Earlier quoted context omitted.

I came here to say that too. It already does well coordinating IoT networks. It's probably one of the most underestimated systems. The Elixir community has been working hard to be able to run models directly within BEAM, and recently, have added the capability for running Python directly.

Haha I wrote https://github.com/stochastic-thread/snek.ex 10 yrs ago What are they doing with Python on the BEAM these days? I'm OOTL

https://github.com/livebook-dev/pythonx

Re: Go is a good fit for agents

#79
post #74
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.

You think Python is a better language than TS?

Re: Go is a good fit for agents

#80
post #19

Earlier quoted context omitted.

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?

I was wondering if there was something particular about AI, but that's just the standard reason people give to use JS for anything.
Post reply on HN