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

171–180 of 183 posts

Re: Go is a good fit for agents

#171

Post by dpe82 »

crabmusket wrote: post #120
dpe82 wrote: post #24

Earlier quoted context omitted.

As a highly-literate developer with almost 30 years of experience, I can also confirm that LLMs are very good at writing Go.

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." – Rob Pike This f…

That's my assumption too: it's a simple language with very good tooling that's used by reasonably serious projects with good code quality. As a result the LLMs have both high quality training data and the output is easier to get right.

Re: Go is a good fit for agents

#172

Post by TypingOutBugs »

Hasnep wrote: post #123
ashwinsundar wrote: post #61

Earlier quoted context omitted.

Is that what uv sync does under the hood, just curl’s over all dependencies and the python version defined in .python-version?

I think they meant you can use curl to install uv and then you don't need to (manually) install anything else

Yeah that’s what I meant, apologies if unclear

Re: Go is a good fit for agents

#174

Post by dpe82 »

dpkirchner wrote: post #87
dpe82 wrote: post #23

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

Oh yeah. Personally I also try to avoid Python but as the rest of this thread covers it's pretty deeply rooted in ML/AI so I think we're stuck with it - at least for a while.

Re: Go is a good fit for agents

#175

Post by prats226 »

Reminded my of this article: https://ampcode.com/how-to-build-an-agent

Some of the things are just more natural in python being a dynamic language. Eg decorator to quickly convert methods into tool calls, iterating over tool functions to create list of tools, packages to quickly convert them into json schema etc.

Consuming many incoming triggers, eg from user input as well as incoming emails from gmail, or messages from slack which would trigger new agent run was lot more natural in go with channels and switch for loop vs in python where had to create many queues and threading etc

Re: Go is a good fit for agents

#176

Post by rednafi »

koakuma-chan wrote: post #173
rednafi wrote: post #108

Earlier quoted context omitted.

Anything at this point.

Python is terrible in the age of LLMs because type checking doesn't work properly.

Python is basically the only language that’s used to train the models.

Sure, the libs are mostly written in C/C++, but all of them have first-class support for Python and oftentimes Python only. Serving the model is a different story and you can use whatever language to do so.

As someone who has worked in the DS realm for an extended period of time, I can tell you Python has practically zero competition when it comes to data wrangling and training models. There are plenty of contenders when it comes to serving the models or building “agents.”

As for type checking, yeah, it sucks big time. TS is a much better type system than the bolted-on hints in Python. But it’s still JS at the end of the day. All the power of V8, a zillion other runtimes, and TS gets marred by a terribly designed language.

Re: Go is a good fit for agents

#177

Post by dragochat »

Bgd1 wrote: post #135
dragochat wrote: post #129

...could we just get Go's GREAT concurrency model and decent standard lib, but in a language that is less horrible than Go (like with decent type system, enums, expressions based grammar, pattern matching etc etc)? pretty please :P we all yearn for a good static language, and most of us would kill for "something like Rust (good type system, syntax, tools) but without ownership / linear-typing - just a good GC, all-on…

Scala?

good point, might be worth a revisit

Re: Go is a good fit for agents

#178

Post by pantsforbirds »

alberth wrote: post #162
pantsforbirds wrote: post #47

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…

Any reason for SQLite use, instead of the BEAMs built-in mnesia data store? https://www.erlang.org/doc/apps/mnesia/mnesia.html

I'm still in the exploration/experimentation stage of the project, but I'm currently using a mixture of SQLite, PostgreSQL, S3, and DuckDB.

My original thought was to spin up SQLite databases as needed because they are super lightweight, well-tested, and supported by almost every programming language. If you want to set up an agent in another programming language via MCP, but you still want to be able to access the agent memory directly, you can use the same schema in a SQLite database.

I may end up using mnesia for more metadata or system-oriented data storage though. It's very well designed imo.

But one of the biggest reasons has just been the really nice integration with DuckDB. I can query all of the SQLite databases persisted in a directory and aggregate some metadata really easily.

Re: Go is a good fit for agents

#179

Post by pantsforbirds »

nilslice wrote: post #71
pantsforbirds wrote: post #47

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

That's a really interesting idea. My original thought was to use MCP as the way to define other agents, but I'll have to do some more research into extism!

Re: Go is a good fit for agents

#180

Post by williamsss »

dpkirchner wrote: post #87
dpe82 wrote: post #23

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

JavaScript has known issues with math. It should be avoided for that reason alone, no?
Post reply on HN