141–150 of 310 posts
Earlier quoted context omitted.
Rust is harder for the bot to get "wrong" in the sense of running-but-does-the-wrong-thing, but it's far less stable than Go and LLMs frequently output Rust that straight up doesn't compile.
If you use the stable version of Rust, it's stable. There's a very strong commitment from the Rust folks on that specific point.
I actually spent some time trying to get to the bottom of what a logical extension of this would be. An entirely made up language spec for an idealized language it never saw ever, and therefore had no bad examples of it. Go is likely the closest for the many reasons people call it boring.
As long as python runs all the models, the best language for agents is likely Python as it allows e.g. auto-fine-tuning of (local) LLMs for self-improving agents without the need to change the programming language. Use Pydantic if you care about type/runtime errors.
Earlier quoted context omitted.
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…
Unit tests in the same file wastes context and makes the whole thing hard to navigate for humans and machines alike.
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.
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 st…
Huh? Lifetime analysis is a local analysis, same as any other kind of type checking. The semantics may have global implications, but exposing them locally is the whole point of having dedicated syntax for it.
Earlier quoted context omitted.
> 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…
> if you have to have a compiler check your code it's already too late If you're running good agentic AI it can read the compile errors just like a human and work to fix them until the build goes through.
Earlier quoted context omitted.
> 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…
> if you have to have a compiler check your code it's already too late If you're running good agentic AI it can read the compile errors just like a human and work to fix them until the build goes through.
Earlier quoted context omitted.
You can write in it like in imperative languages. I did it when I first encountered it long time ago, and I didn’t know how to write, or why I should write code in a functional way. It’s like how you can write in an object oriented way in simple C. It’s possible, and it’s a good thought experiment, but it’s not recommended. So, it’s definitely not “enforced” in a strict sense.
Isn’t code in Haskell pure by default and you have to use special keywords to have code with side effects?
Any side effect has to be performed inside `IO` type, which means impure functions need to be marked as `IO` return. And any function that tries to "execute" `IO` side effect has to mark itself as returning `IO` as well.
Intuitively I expect this. Go is a language designed by Rob Pike to keep legions of high IQ Google engineers constrained down a simple path. There's generally one way to do it in Go. As a human programmer with creative and aesthetic urges as well as being lazy and having an ego, I love expressive languages that let me describe what I want in a parsimonious fashion. ie As few lines of code as possible and no boilerpla…
But for how long will it matter? I do wonder if programming languages as we know them today will lose relevance as all this evolves.
C.f., from 25d ago: “Why Elixir is the best language for AI” https://news.ycombinator.com/item?id=46900241 - for comparison of the arguments made - features a bit more actual data than “intuitions” compared to OP - interesting to think about in an agent context specifically is runtime introspection afforded by the BEAM (which, out of how it developed, has always been very important in that world) - the blog post has…