Earlier quoted context omitted.
Why is JS particularly good for agents?
The same reason it’s good for web servers. It excels at even-driven applications.
This is a specious argument. It's event-driven because it has callbacks?
Go is a good fit for agents
101–110 of 183 posts
Re: Go is a good fit for agents
#102Is anyone aware of a good llm orchestration libraries for go like langchain for Python and Typescript?
https://github.com/diveagents/dive
Dive orchestrates multi agent workflows in Go. Take a look and let me know what you think.
Re: Go is a good fit for agents
#103AI 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?
I'd say TypeScript is currently the best choice for agents. For one, MCP tooling is really solid, the language itself is easy, fast to develop in, and not esoteric.
Re: Go is a good fit for agents
#104I'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.
I wouldn’t underestimate the impact of having massive communities around a language. Basically any problem you have has likely already been solved by 10 other people. With AI being as frothy as it is, that’s incredibly valuable.
Take for example something like being able to easily swap models, in Python it’s trivial with litellm. In niche languages you’re lucky to even have an official, well mantained SDK.
Re: Go is a good fit for agents
#105Agents 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.
What diffing/patching/merging library are you working with? Or are you building your own?
Re: Go is a good fit for agents
#106For 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 actually working on an agent library in golang and this is exactly the thought process I've come up with. If we have comprehensive logging we can actual reconstruct the agents state at any position. Allowing for replays etc. You just need the timestamp(endpoint) and the parent run and you can build children/branched runs after that. Through the use of both a map that holds a context tree and a database we can purge…
Just a drive-by thought, but: What you're describing sounds a lot like Temporal.io. I guess the difference is the "workflow" of an agent might take different paths depending on what it was asked to accomplish and the approach it ends up taking to get there, and that's what you're interested in persisting, replaying, etc. Whereas a Temporal workflow is typically a more rigid thing, akin to writing a state machine that models a business process -- but all the challenges around persistence, replay, etc, sound similar.
Edit: Heh, I noticed after writing this that some sibling comments also mention Temporal.
Re: Go is a good fit for agents
#107Earlier quoted context omitted.
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.
It's not so perplexing when you understand that Python has long had the best ecosystem of libraries for data science and ML, from which the current wave of AI stuff was born. There are plenty of reasons to dunk on Python, but the reality is lots of people were getting real work done with it in the run up to where we are today.
Re: Go is a good fit for agents
#108Earlier quoted context omitted.
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?
Anything at this point.
Re: Go is a good fit for agents
#109Go isn't horrible for this stuff. But I don't think it's notably better than a lot of other languages either.
Frankly, anything that has a compiler and supports doing asynchronous stuff decently probably does the job. Which of course describes a wide range of languages. And since agents inherently involve a lot (some would say mostly) prompt engineering, it helps if the language is good at things like multi line strings, templated strings, and just generally manipulating strings.
As for the async stuff, it's nice if a language can do async things. But is that enough? Agentic systems essentially reach out to other systems over the network. Some of the tasks may be long lived. Minutes, hours, or even days. A lot can happen in such long time. IMHO the model of some system keeping all that state in a long running process is probably not ideal. We might want something more robust and long running and less dependent on a some stateful process running somewhere for days on end.
There is an argument to be made for externalizing related state from the language and maybe using some middleware optimized for this sort of thing. I've seen a few things that go in that direction but not a lot yet. It seems that people are still busy reinventing wheels and not fully realizing yet that a lot of those wheels don't need reinventing. There's a lot of middleware out there that is really great at async job scheduling, processing, fan out, and all the other stuff that people eventually will figure out is needed here.
Re: Go is a good fit for agents
#110For 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…
What are the main differences between temporal and hatchet?