Go is a good fit for agents

Go’s perceived strengths for agents

• Many see agents as orchestration-heavy: coordinating HTTP calls, streams, timeouts, retries, backpressure, and cancellation. This is described as “bread and butter” for Go’s goroutines, channels, context.Context, and strong standard library.
• Static binaries and simple deployment are cited as advantages over Python’s virtualenv/pip complexity for production agents.
• Some report good experience building real agentic tools/CLIs in Go, and say LLMs generate Go code reliably because the language is small, consistent, and has high‑quality training data.

Elixir/Erlang and the BEAM alternative

• Several argue that, by the same concurrency logic, Elixir/Erlang (BEAM) are even better for agents: lightweight isolated processes, built‑in distribution, fault tolerance, hot code upgrades.
• BEAM + durable storage (SQLite/Postgres/S3/DuckDB or mnesia) is proposed as an ideal combo for stateful agents and orchestrators, with examples of job/workflow systems and IoT‑style networks.
• Some note BEAM’s VM and performance ceiling as drawbacks versus a compiled language like Go.

JavaScript/TypeScript and Python ecosystems

• There’s strong defense of JS/TS for agents: native JSON handling, event-driven style, npm ecosystem, browser + Node deployment, sandboxing in the browser, and mature MCP tooling.
• Python is defended as the de facto ML/AI language with unmatched libraries, tooling, and community; many agent frameworks, observability tools, and SDKs appear there first.
• Others dislike JS/TS or Python on language-design grounds but concede that ecosystem gravity matters in AI more than runtime performance.

Durable execution, task queues, and state

• Long‑running agents raise concerns about losing in‑memory state on process death. Multiple comments argue you must break work into resumable chunks and persist state in a DB or durable log.
• Temporal, Hatchet, task queues, and similar durable-execution systems are discussed as language-agnostic solutions that replay workflows from event history.
• Some Go users are hand‑rolling checkpointed agents using logs, context trees, and databases, but note the complexity overhead.

Performance and bottlenecks

• Many point out agents spend most of their time waiting on LLM calls and external I/O; runtime speed rarely dominates.
• JSON (de)serialization and conflict‑resolution (diff/patch/merge on shared state) are mentioned as the main non‑LLM hotspots; language choice only marginally affects these.

Go’s language and ecosystem criticisms

• Critics argue Go’s type system (enums, generics ergonomics), error handling verbosity, and channel footguns hurt general productivity, not just for agents.
• Others counter that the simplicity, interfaces, and tooling outweigh these issues and reduce long‑term maintenance risk.
• Several note that Go’s ML and agent‑orchestration library ecosystem lags far behind Python and TS; you often end up writing your own middleware (logging, tracing, retries, DSLs, SDKs).

“Agents are just software” / language neutrality

• A recurring view: everything described as “an agent” is standard async/distributed programming—loops, branching, queues, workflows.
• From that perspective, “best language for agents” largely reflects developer preference; any language with decent async and libraries can work, and language choice rarely determines success.