Live data from Hacker News

Go is a good fit for agents

docs.hatchet.run

121–130 of 183 posts

Re: Go is a good fit for agents

#121
post #114

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 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 currently use an interface, where the type name, rather than an enum, is what differentiates the different types. If Go were to gain something like a discriminated union, it is likely it would want to extend upon that idea. Most especially given that generics already introduced syntax that would lend itself fairly well to it:

    type Foo interface {
        Bar | Baz
    }
Where enums are used to act as a discriminant in other languages, that is largely just an implementation detail that nobody really cares about. In fact, since you mentioned Rust, there are only 8,000 results on Github for `std::mem::discriminant` in Rust code, which is basically nothing. That is quite indicative that wanting to use an enum (in Rust, at least) is a rare edge case. Funny, given how concerned Rust users seem to be about enums. Talk is cheap, I suppose.

Re: Go is a good fit for agents

#122
post #113

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.

I think the point was that "Go's quite horrendous and limited type system" gets in the way of everything (programming in general), nothing specific to crafting agents.

There's a lot of discussions on the internet about the bad design decisions of Golang (for example around channels, enums, error handling, redeclarations, interfaces, zero values, nilability... at least generics aren't so much a subject anymore)

Re: Go is a good fit for agents

#123

Earlier quoted context omitted.

Go is definitely better, but with uv you can install all dependencies including python with only curl

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

Re: Go is a good fit for agents

#124
post #90

Earlier quoted context omitted.

Yep exactly, might as well use a language that works with JSON natively like TypeScript; which has arguably far more powerful type system than Go.

> like TypeScript; which has arguably far more powerful type system than Go. "arguably". Typescript is just a thin wrapper over javascript who doesnt have these types at all.

And yet its types are turning complete

Re: Go is a good fit for agents

#125
Go has few advantages for this kind of workload - most of the time it'll just be waiting on io. And you suffer from the language itself; many type system features that you get for free in modern langauges require workarounds in Go.

I've found that TypeScript is an excellent glue language for all kinds of AI. Python, followed by TS enjoy broad library support from vendors. I personally prefer it over Python because the type system is much more expressive and mature. Python is rapidly improving though.

> It turns out, cancelling long-running work in Node.js and Python is incredibly difficult for multiple reasons:

Evidence is lacking for this claim. Almost all tools out there support cancellations, and they're mostly either Python or JS.

Re: Go is a good fit for agents

#127
post #121
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…

#[repr(u8)]

enum Discriminant {

Disc0 = 0,

Disc1 = 1,

}

Re: Go is a good fit for agents

#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-the-heap and a dash of nice immutable datastructs"...

Re: Go is a good fit for agents

#130
post #107

Earlier quoted context omitted.

Choosing Python over JavaScript is one of the more perplexing decisions I've seen.

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 Python. They made sense logistically, since universities largely only teach Python, so it was a lowest-common-denominator language that allowed the universities to give AI / ML research opportunities to everyone, with absolutely no gatekeeping and with a steadfast spirit of friendly inclusion (sorry, couldn’t resist the sarcastic tangent). I can’t blame them for working with what they had.

But now that the techniques have grown up and graduated to form multibillion-dollar companies, I’m hopeful that industry will take up the mantle to develop an ecosystem that’s better suited for production and for modern software engineering.

Post reply on HN