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

91–100 of 183 posts

Re: Go is a good fit for agents

#91

Post by arthurcolle »

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?

It doesn't feel different enough to merit a difference. Elixir is just a set of Erlang macros that turn one syntax into .beam that otherwise wouldn't turn into .beam

Elixir is way more productive to write/deal with (Phoenix vs. Erlang templating) maybe if you're a web dev, but at the end of the day you're dealing with the same exact same underlying architecture. If you're a prolog programmer, Erlang will feel nicer than if you're a ruby programmer.

I have many packages published as Mix packages, and some published as rebar packages.

Overall, ergonomics definitely feel nicer with Elixir, but I feel like by having it be portrayed as "so different" from Erlang, people don't pull open the Erlang/OTP docs, and don't look at the dozens of behaviors that already exist that usually solve your problem.

Like, why is there a gen stage in Elixir but not in Erlang?

If you wanna use the BEAM, you can use it. If they were more in sync, and provided OOTB in the same distribution, I'd always lean towards Elixir.

Just feels weird that Elixir gets a bunch of street cred for what are fundamentally Erlang/OTP capabilities

Re: Go is a good fit for agents

#92

Post by [deleted] »

koakuma-chan wrote: post #79
rednafi wrote: post #74

Earlier 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?

[deleted]

Re: Go is a good fit for agents

#94

Post by bewestphal »

If you’re not using Python or Typescripts ecosystem then you spend a lot of time as a framework dev. This has a high opportunity cost when you can easily slap together agents and have products quickly nowadays.

Re: Go is a good fit for agents

#95

Post by myzie »

+1 to the article.

Along these lines, I'm building Dive:

https://github.com/diveagents/dive

When building a SaaS with a Go backend, it's nice to be able to have the option of the agents and workflows being in the same process. And being confident in the ability of that to scale well.

While it's true that Go lacks good ML libraries, for some this isn't too consequential if your app is primarily using Anthropic or OpenAI and a database that offers semantic or hybrid search for RAG. The ML is done elsewhere. Plus it could be that you can leverage MCP servers and at that point you're language agnostic.

Regarding the concurrency model approach with Go and agents, I initially baked a message based approach (a la the Actor model, with one goroutine per agent) into Dive Agents, but eventually found that this would be better implemented as another layer. So currently in Dive it's the user's choice on how to implement concurrency and whether to use messaging. But I anticipate building that back in as an optional layer.

Re: Go is a good fit for agents

#97

Post by oxidant »

arthurcolle wrote: post #91
guywithahat wrote: post #82

Earlier quoted context omitted.

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

It doesn't feel different enough to merit a difference. Elixir is just a set of Erlang macros that turn one syntax into .beam that otherwise wouldn't turn into .beam Elixir is way more productive to write/deal with (Phoenix vs. Erlang templating) maybe if you're a web dev, but at the end of the day you're dealing with the same exact same underlying architecture. If you're a prolog programmer, Erlang will feel nicer t…

Elixir has a better developer experience, or at least it's more approachable. Better code splitting with modules, easier to use variables (no var, var1, var2), loops that look like loops but easy enough to fall back to recursion, and an easier to read syntax.

gen_stage is just a library. One could write it in Erlang. It's like asking why Broadway is only for Elixir and not Erlang.

It was hard to approach the Erlang docs when I started in Elixir. However, they've moved to an ex_doc format (is it ex_docs?) as a standard and it's so much easier to grok.

Re: Go is a good fit for agents

#98

Post by mountainriver »

rednafi wrote: post #72
mountainriver wrote: post #70

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

There is wayyyyy more ML activity in Rust than Go. Rust is actually becoming quite viable in the ML space.

Agents that don’t do machine learning rarely ever work, that’s the sad truth of the ecosystem.

Re: Go is a good fit for agents

#99

Post by arthurcolle »

oxidant wrote: post #97
arthurcolle wrote: post #91

Earlier quoted context omitted.

It doesn't feel different enough to merit a difference. Elixir is just a set of Erlang macros that turn one syntax into .beam that otherwise wouldn't turn into .beam Elixir is way more productive to write/deal with (Phoenix vs. Erlang templating) maybe if you're a web dev, but at the end of the day you're dealing with the same exact same underlying architecture. If you're a prolog programmer, Erlang will feel nicer t…

Elixir has a better developer experience, or at least it's more approachable. Better code splitting with modules, easier to use variables (no var, var1, var2), loops that look like loops but easy enough to fall back to recursion, and an easier to read syntax. gen_stage is just a library. One could write it in Erlang. It's like asking why Broadway is only for Elixir and not Erlang. It was hard to approach the Erlang d…

Yeah, I didn't think of that at the time I initially posted, but that's very true - I think pipes are definitely a key advantage of Elixir.

I couldn't imagine trying to implement this DSPy library in Erlang, for example

https://hexdocs.pm/dspy/0.1.0/api-reference.html

Re: Go is a good fit for agents

#100

Post by odyssey7 »

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?

The same reason it’s good for web servers. It excels at even-driven applications.
Post reply on HN