[flagged]
Go is a good fit for agents
161–170 of 183 posts
Re: Go is a good fit for agents
#162I'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?
Re: Go is a good fit for agents
#163Go's quite horrendous and limited type system makes it a poor fit for everything. The worst thing about Go is, in fact, the language. Everything except the language redeems it.
To be fair, it is unlikely that Go would have a static type system at all if they had figured out how to achieve the performance expectations without. It was made abundantly clear that it is intended to be like a dynamically-typed language, but faster. Thinking of it as being a statically-typed language is a bit flawed, and shows a gross misunderstanding of what the language was created for.
While you could try to argue that dynamically-typed languages in general are a poor fit for everything, the reality is that people there are typically using Python instead – and the best alternative suggestions beyond Go are Erlang and Elixer, which are also dynamically typed, so that idea doesn't work. Dynamic typing is what clearly fits the problem domain.
Re: Go is a good fit for agents
#164Earlier quoted context omitted.
There are choices at multiple levels. Yes, today’s ML engineer has practically no choice but to use Python, in a variety of settings, if they want to be able to work with others, access the labor market without it being an uphill battle, and most especially if they want to study AI / ML at a university. But there were also the choices to initially build out that ecosystem in Python and to always teach AI / ML in Pyth…
How good is JS interop with C/C++/BLAS? That's the basic stepping stone, I think. If you cannot make something in JavaScript that can compete with numpy there's little chance that things will change anytime soon.
I don’t know the details as specifically, since I haven’t been able to justify investing my efforts in the non-flagship ecosystem within the TensorFlow project after it previously added its Swift version to the Google Graveyard, but TensorFlow.js is doing something in this direction for the Node.js version. This info is at: https://www.tensorflow.org/js/guide/nodejs
“Like the CPU package, the module is accelerated by the TensorFlow C binary. But the GPU package runs tensor operations on the GPU with CUDA.”
They note that these operations are synchronous, so using them will sacrifice some of JavaScript’s effectiveness at asynchronous event processing. This is not different from Python when you are training or serving a model. JavaScript’s strengths would shine brighter when coordinating agents / building systems that coordinate models.
Re: Go is a good fit for agents
#165Earlier quoted context omitted.
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.
And I wouldn't overestimate a language's popularity. It's mostly a social phenomenon and rarely has anything to do with technical prowess.
I agree that integration with the separate LLMs / agents can and does accelerate initial development. But once you write the integration tooling in your language of choice -- likely a few weeks worth of work -- then it will all come down to competing on good orchestration.
Your parent poster is right: languages like Erlang / Elixir or Golang (or maybe Rust as well) are better-equipped.
Re: Go is a good fit for agents
#166This reminds me of a talk named - Modern Data Science in Go. That line of thinking went nowhere and many arguments in that talk were misleading.
Re: Go is a good fit for agents
#167AI 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.
> Python, Ruby
It's 2025, Node.js has been around since 2009, yet these languages' still use C-based interpreters by default, and their non-standard JIT alternatives are still much worse than V8.
Re: Go is a good fit for agents
#168Earlier quoted context omitted.
#[repr(u8)] enum Discriminant { Disc0 = 0, Disc1 = 1, … }
Funny enough, manually defining the discriminant disables the enumerator: enum Discriminant1 { Disc0, Disc1, } #[repr(u8)] enum Discriminant2 { Disc0 = 10, Disc1 = 20 } fn main() { let d1 = Discriminant1::Disc1; let d2 = Discriminant2::Disc1; println!("{:?}", std::mem::discriminant(&d1)); // Value by enumerator. println!("{:?}", std::mem::discriminant(&d2)); // Value by constant. } Which makes the use of the enum key…
What's that have to do with Rust though? Rust takes it straight from C: https://godbolt.org/z/Ysb6M66h4
And because it has been used like that in C for decades, the dictionary definition takes a backseat to the now de-facto C-based definition (at least for popular systems languages, which Rust is trying to share as much syntax with).
Re: Go is a good fit for agents
#169Earlier quoted context omitted.
If you want to know only about the type system, nowadays it's mostly the lack of basic enums, a clear divide in basic features of the language and of the libraries (and modern generics support) leading to things like `len(..)` vs `.Len()`. Those actually end up playing a bigger role than it seems imho, but even just the rest is death by a thousand cuts. You can find many articles on the internet about it, but in my e…
> Companies started to use it as an alternative to C and C++, while in reality it's an alternative to python. Just like in python a lot of the work and warnings are tied into the linter as a clear workaround. Our linter config has something like 70+ linters classes enabled, and we are a very small team. I thought the main "let's migrate our codebase to Go" crowd had always been from the Java folks, especially the ent…
Well, there's a difference between "our program is written in C++ because we correctly chose it for its performance" and "our program happens to be written in C++ because some programmer 10 years ago really liked C++".
There's a lot of software out there that either was written before good modern options existed, or uses very outdated patterns, or its language wasn't chosen with much thought.
Re: Go is a good fit for agents
#170Earlier quoted context omitted.
Funny enough, manually defining the discriminant disables the enumerator: enum Discriminant1 { Disc0, Disc1, } #[repr(u8)] enum Discriminant2 { Disc0 = 10, Disc1 = 20 } fn main() { let d1 = Discriminant1::Disc1; let d2 = Discriminant2::Disc1; println!("{:?}", std::mem::discriminant(&d1)); // Value by enumerator. println!("{:?}", std::mem::discriminant(&d2)); // Value by constant. } Which makes the use of the enum key…
What's that have to do with Rust though? Rust takes it straight from C: https://godbolt.org/z/Ysb6M66h4 And because it has been used like that in C for decades, the dictionary definition takes a backseat to the now de-facto C-based definition (at least for popular systems languages, which Rust is trying to share as much syntax with).
> Rust takes it straight from C
Meaning the keyword? Sure, C has the same inconsistency if you disable the enumerator with manual constant values. C is not exactly the paragon of thoughtful design. But whataboutism is a dumb path to go down.
> the dictionary definition takes a backseat to the now de-facto C-based definition
That's clearly not the case, though, as the functionality offered by the Rust enum keyword is very different. It puts absolutely no effort into being anything like C. Instead, it uses enum as the keyword for defining sum types. The C enum keyword, on the other hand, does nothing but define constants, and is functionally identical to what Go has. There is an enum involved in both cases, as demonstrated earlier, so the terminology isn't strictly wrong (in the usual case) but the reason for it existing shares little commonality.
But maybe you've moved onto the concept of enums rather than syntax and I didn't notice? You are right that the dictionary definition is in line with the intent of the C keyword, which speaks to the implementation, and is how C, Rust, Go, and every other language out there use the terminology. In another comment I even linked to the implementation in both Go and Rust and you can see that the implementation is conceptually the same in both cases: https://news.ycombinator.com/item?id=44236666