131–140 of 310 posts
Earlier quoted context omitted.
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.
[flagged]
I've been saying this for maybe nine months vis-à-vis my consulting work keeps proving it. Go is an excellent language for LLM code generation. There exists a large stable training corpus, one way to write it, one build system, one formatter, static typing, CSP concurrency that doesn't have C++ footguns. The language hasn't had a breaking version in over a decade. There's minimal framework churn. When I advise teams…
Most of these reasons apply to Java as much, if not more. It's an even more popular language with even more training data and also has a better type system so more validation on LLM output, etc.
Yeah, I don't care for go but I expect it to win here. Its performance is good enough for most use cases, it has a huge ecosystem of libraries, lots of training data, and deploys as a binary so users don't need to install anything else. I expect rust to gain some market share since it's safe and fast, with a better type system, but complex enough that many developers would struggle by themselves. But IME AI also stru…
> But for whatever reason it never became that mainstream Syntax. Syntax is the reason. It's too foreign to be picked up quickly by the mass of developers that already know a C style language. I would also argue that it's not only foreign, it's too clunky.
I've been saying this for maybe nine months vis-à-vis my consulting work keeps proving it. Go is an excellent language for LLM code generation. There exists a large stable training corpus, one way to write it, one build system, one formatter, static typing, CSP concurrency that doesn't have C++ footguns. The language hasn't had a breaking version in over a decade. There's minimal framework churn. When I advise teams…
Most of these reasons apply to Java as much, if not more. It's an even more popular language with even more training data and also has a better type system so more validation on LLM output, etc.
Earlier quoted context omitted.
> But LLMs don't care about expressiveness, they care about predictability. I think this is true, but it misses a very key point. Go does an impressively bad job at designing APIs that are difficult to misuse, so LLMs will misuse them and will require also writing unit tests to walk through it, just to validate it used the libraries correctly. This isn't always possible (or is awkward/cumbersome) for certain scenario…
Rust is unstable and slow to compile. I think these two features make it bad for LLMs and everything else.
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.
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.
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.
Earlier quoted context omitted.
> But LLMs don't care about expressiveness, they care about predictability. I think this is true, but it misses a very key point. Go does an impressively bad job at designing APIs that are difficult to misuse, so LLMs will misuse them and will require also writing unit tests to walk through it, just to validate it used the libraries correctly. This isn't always possible (or is awkward/cumbersome) for certain scenario…
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.
Earlier quoted context omitted.
[flagged]
I’m not sure they’re saying rust is king of types, they’re saying it’s king of llm targets.
Not to mention it's one of the slowest compilation of recent languages if not the slowest (maybe Kotlin).
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 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'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.