logoalt Hacker News

0x3fyesterday at 7:07 PM17 repliesview on HN

I think the more you can shift to compile time the better when it comes to agents. Go is therefore 'ok', but the type system isn't as useful as other options.

I would say Rust is quite good for just letting something churn through compiler errors until it works, and then you're unlikely to get runtime errors.

I haven't tried Haskell, but I assume that's even better.


Replies

g947oyesterday at 7:21 PM

I think Rust is great for agents, for a reason that is rarely mentioned: unit tests are in the same file. This means that agents just "know" they should update the tests along with the source.

With other languages, whether it's TypeScript/Go/Python, even if you explicitly ask agents to write/run tests, after a while agents just forget to do that, unless they cause build failures. You have to constantly remind them to do that as the session goes. Never happens with Rust in my experience.

show 3 replies
jaggederestyesterday at 7:18 PM

Haskell is great, for what it's worth, but as with any language you have to reign in the AI's use of excessive verbosity. It will stack abstractions to the moon even for simple projects, and haskell's strengths for humans in this regard are weaknesses for AI - different weaknesses than other languages, but still, TANSTAAFL

I am trying out building a toy language hosted on Haskell and it's been a nice combo - the toy language uses dependent typing for even more strictness, but simple regular syntax which is nicer for LLMs to use, and under the hood if you get into the interpreter you can use the full richness of Haskell with less safety guardrails of dependent typing. A bit like safe/unsafe Rust.

show 1 reply
siliconc0wyesterday at 7:27 PM

+1 to Rust - if we're offloading the coding to the clankers, might as well front-load more complexity cost to offload operational cost. Sure, it isn't a particularly ergonomic or simple language but we're not the ones who have to use it.

headcanonyesterday at 8:00 PM

I've been cruising on rust too, not just because it works great for LLMs but also the great interop:

- I can build SPAs with typescript and offload expensive operations to a rust implementation that targets wasm

- I can build a multi-platform bundled app with Tauri that uses TS for the frontend, rust for the main parts of the backend, and it can load a python sidecar for anything I need python for (ML stuff mainly)

- Haven't dived too much into games but bevy seems promising for making performant games without the overhead of using one of the big engines (first-class ECS is a big plus too)

It ended up solving the problem of wanting to use the best parts of all of these different languages without being stuck with the worst parts.

show 2 replies
jnpnjyesterday at 7:32 PM

Was asking on mastodon if people tried leveraging very concise and high level languages like haskell, prolog with 2025 llms.. I'm really really curious.

show 2 replies
sockaddryesterday at 7:14 PM

Exactly. Here's my experience using LLMs to produce code:

- Rust: nearly universally compiles and runs without fault.

- Python,JS: very often will run for some time and then crash

The reason I think is type safety and the richness of the compiler errors and warnings. Rust is absolutely king here.

show 2 replies
dnauticsyesterday at 9:14 PM

> I think the more you can shift to compile time the better when it comes to agents

not born out by evidence. rust is bottom-mid tier on autocoderbenchmark. typescript is marginally bettee than js

shifting to compile time is not necessarily great, because the llm has to vibe its way through code in situ. if you have to have a compiler check your code it's already too late, and the llm does not havs your codebase in its weights, a fetch to read the types of your functions is context expensive since it's nonlocal.

show 1 reply
squeegmeisteryesterday at 7:15 PM

Have also wondered how Haskell would be. From my limited understanding it’s one of the few languages whose compiler enforces functional purity. I’ve always liked that idea in theory but never tried the language

show 2 replies
gf000yesterday at 9:08 PM

I absolutely love Rust, but due to the space it occupies there is simply more to specify in code, and more things to get wrong for a stochastic LLM.

Lifetimes are a global property and LLMs are not particularly good at reasoning about them compared to local ones.

Most applications don't need low level memory control, so this complexity is better pushed to runtime.

There are lots of managed languages with good/even stronger type systems than Rust, paired with a good modern GC.

show 1 reply
bensyversonyesterday at 7:10 PM

I built an agent with Go for the exact reasons laid out in the article, but did consider Rust. I would prefer it to be Rust actually. But the #1 reason I chose Go is token efficiency. My intuitive sense was that the LLM would have to spent a lot of time reasoning about lifetimes, interpreting and fixing compiler warnings, etc.

show 5 replies
michaelbartonyesterday at 10:19 PM

I wonder if then Idris would be even better than that since it has even more typing

loklyesterday at 7:40 PM

What about SPARK? Not enough training data?

chrismanningyesterday at 7:35 PM

Haskell works pretty well with agents, particularly when the agent is LSP-capable and you set up haskell-language-server. Even less capable models do well with this combo. Without LSP works fine but the fast feedback loop after each edit really accelerates agents while the intent is still fresh in context

solomonbyesterday at 7:23 PM

I've been using LLMs (Opus) heavily for writing Haskell, both at work and on personal projects and its shockingly effective.

I wouldn't use it for the galaxy brain libraries or explorations I like to do for my blog but for production Haskell Opus 4.5+ is really good. No other models have been effective for me.

cortesoftyesterday at 7:22 PM

I am guessing there is a balance between a language that has a lot of soundness checks (like Rust) and a language that has a ton of example code to train on (like Python). How much more valuable each aspect is I am not sure.

show 1 reply
nesarkvechnepyesterday at 8:20 PM

Idris would be even better.

thot_experimentyesterday at 7:27 PM

Of my friend group the two people I think of as standout in terms of getting useful velocity out of AI workflows in non-trivial domains (as opposed to SaaS plumbing or framework slop) primarily use Haskell with massive contexts and tight integration with the dev env to ground the model.