Go is a good fit for agents • Hacker News Board

Re: Go is a good fit for agents

#131

Post by eru » Tue, Jun 10, 2025, 11:38 AM UTC

Teifion wrote: post #118

eru wrote: post #88

Earlier quoted context omitted.

Erlang has better syntax than Elixir. But otherwise they are mostly the same: Elixir is just an Erlang reskin. So pretty much wherever you can use one, you can use the other.

An anecdote which may be of interest. Speaking to Elixir and Erlang developers I found those who started with Erlang preferred its syntax while those who started with Elixir or didn't know either preferred the Elixir syntax.

I agree that either way, Elixir is mostly just a reskin.

I would have like it more, if they had reskinned it to look more like Haskell. But that's just my preference.

Re: Go is a good fit for agents

#132

Post by Luker88 » Tue, Jun 10, 2025, 12:03 PM UTC

flanked-evergl wrote: post #112

Go'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.

I have been programming in Go for several years now and I agree, though I am not that sure even the rest of the ecosystem redeems it that much.

On the other hand, the programming languages used by LLM people seem to be python and javascript mainly.

So while I argue that they all should really move on to modern languages, I think go is still better than the I-can't-even-install-this mess of python and javascript imports without even a Dockerfile that seem to be so prevalent in LLM projects.

Re: Go is a good fit for agents

#133

Post by lou1306 » Tue, Jun 10, 2025, 12:18 PM UTC

odyssey7 wrote: post #130

jpk wrote: post #107

Earlier quoted context omitted.

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.

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.

Re: Go is a good fit for agents

#134

Post by 9rx » Tue, Jun 10, 2025, 12:50 PM UTC

LtdJorge wrote: post #127

9rx wrote: post #121

Earlier quoted context omitted.

> enums are just sad. There isn't much more you can do with them. Literally all an enum can produce is a number. In increasingly common use in a number of languages, enums are being coupled with discriminated unions, using the enum value as the discriminant. This is probably what you're really thinking of, noticing Go's lack of unions. But where you might use a discriminated union if it were available, you would curr…

#[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 keyword particularly bizarre given that there is no longer even an enumerator involved, but I suppose bizarre inconsistencies are par for the course in Rust.

Re: Go is a good fit for agents

#135

Post by Bgd1 » Tue, Jun 10, 2025, 12:56 PM UTC

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?

Re: Go is a good fit for agents

#136

Post by throwawaymaths » Tue, Jun 10, 2025, 12:57 PM UTC

samuell wrote: post #119

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…

While I think there is some truth to that regarding the programming paradigm, I always felt the EVM have two big drawbacks, compared to something like Go: 1. Requiring a VM, making deployment more complex. 2. Not being natively compiled, or always having this performance roof for the inner loops. After considering both Erlang/Elixir and Go a lot for my scientific workflow manager, I finally went with Go for these exa…

releases give you a tar.gz with everything bundled.

Re: Go is a good fit for agents

#137

Post by Luker88 » Tue, Jun 10, 2025, 1:00 PM UTC

giik wrote: post #113

flanked-evergl wrote: post #112

Go'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.

Can you elaborate a bit on how does "Go's quite horrendous and limited type system" get in the way of crafting agents? Honest question, I am genuinely interested in what cannot be done easily or at all due to limitations of the Go type system.

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 experience I would summarize it in:

It looks like it's made to have a simple compiler, not to simplify the programmer's life.

Initially its simplicity is wonderful. Then you start to notice how verbose things are. Channels are another looks-nice-but-maybe-don't feature. nil vs nil-interface. Lack of proper enums is hurting so much I can't describe it. I personally hate automatic type conversions, and there are so many inconsistencies in the standard and most used libraries that you really start to wonder why some things where even done. validators that validate nothing, half-done tagging systems for structs, tons of similar-but-not-quite interfaces and methods.

It's like the language has learning wheels that you can't shake off or work around. You end up wanting to leave for a better one.

People had to beg for years for basic generics and small features. If google is not interested in it, you'd better not be interested in it and it shows after a while.

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.

C can be described as a relatively simple language (with caveats), C++ has grown to a blob that does and has everything, and while they have lots of footguns I did not find the same level of frustration as with go. You always end up fighting a lot of corner cases everywhere.

Wanted to say even more, but I think I ranted enough.

Re: Go is a good fit for agents

#138

Post by abelanger » Tue, Jun 10, 2025, 1:03 PM UTC

lifty wrote: post #110

abelanger wrote: post #32

Earlier quoted context omitted.

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?

The primary difference is that Hatchet is an all-purpose platform for async jobs, so while durable execution is a pattern that we support, we have a lot of other features like concurrency and fairness control, event ingestion, custom queues, dynamic rate limiting, streaming from a background job, monitoring, alerting, DAG-based executions, etc. There's a bit more on this/our architecture here: https://news.ycombinator.com/item?id=43572733.

The reason I started working on Hatchet was because I'm a huge advocate of durable execution, but didn't enjoy using Temporal. So we try to make the development experience as good as possible.

On the underlying durable execution layer, it's the exact same core feature set.

Re: Go is a good fit for agents

#139

Post by [deleted] » Tue, Jun 10, 2025, 1:08 PM UTC

Luker88 wrote: post #137

giik wrote: post #113

Earlier quoted context omitted.

Can you elaborate a bit on how does "Go's quite horrendous and limited type system" get in the way of crafting agents? Honest question, I am genuinely interested in what cannot be done easily or at all due to limitations of the Go type system.

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…

[deleted]

Re: Go is a good fit for agents

#140

Post by kbolino » Tue, Jun 10, 2025, 1:31 PM UTC

9rx wrote: post #121

bbkane wrote: post #114

Earlier quoted context omitted.

I agree- multiple return values don't compose; errors are better than exceptions, but still super verbose; channels have a lot of foot guns; enums are just sad. But despite all of that the language has some really good qualities too- interfaces works far better than it feels like they should; the packaging fits together really well (I'm learning Rust right now and the file structure is far more complicated); and peop…

> enums are just sad. There isn't much more you can do with them. Literally all an enum can produce is a number. In increasingly common use in a number of languages, enums are being coupled with discriminated unions, using the enum value as the discriminant. This is probably what you're really thinking of, noticing Go's lack of unions. But where you might use a discriminated union if it were available, you would curr…

Java has true enums that are neither fancy integers nor discriminated unions. The following is not a list of integers:

    public enum Day {
        SUNDAY, MONDAY, TUESDAY, WEDNESDAY,
        THURSDAY, FRIDAY, SATURDAY 
    }

To use this enum, you typically declare a variable of type Day, which is a subclass of Enum, itself a subclass of Object, which cannot be cast to or from int. If a variable is typed as Day, then it can only take one of these variants (or null). Even though the Day class does have an ordinal() method, and you can look up the variants by ordinal, you cannot represent Day(7) or Day(-1) in any way, shape, or form. This sealed set of variants is guaranteed by the language and runtime (*). Each variant, like SUNDAY, is an instance of class Day, and not a mere integer. You can attach additional methods to the Day class, and those methods do not need to anticipate any other variants than the ones you define. Indeed, enums are sometimes used with a single variant, typically called INSTANCE, to make true singletons.

* = There is a caveat here, which is that the sealed set of variants can differ between compile-time (what's in a .java file) and runtime (what's in a .class file) but this only happens when you mismatch your dependency versions. Rather importantly, the resolution of enum variants by the classloader is based on their name and not their ordinal, so even if the runtime class differs from the compile-time source, Day.MONDAY will never be turned into a differently named variant.