151–160 of 310 posts
Earlier quoted context omitted.
> 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.
Which is slow and heavy in Rust. All languages have that but faster (and simpler due to no lifetimes).
Earlier quoted context omitted.
Rust is unstable and slow to compile. I think these two features make it bad for LLMs and everything else.
Why do you say it's unstable?
With Go, async code written in Go 1.0 compiles and runs the same in Go 1.26, and there is no fragmentation or necessity to reach for third party components.
Earlier quoted context omitted.
> 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.
Which is slow and heavy in Rust. All languages have that but faster (and simpler due to no lifetimes).
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'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…
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.
If code is now free, why does the language matter at all?
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?
You basically compose a description of the side effects and pass this value representing those to the main handler which is special in that it can execute the side effects.
For the rest of the codebase this is simply an ordinary value you can pass on/store etc.
Earlier quoted context omitted.
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.
Java has decade(s) of cruft and breaking changes which LLMs were trained on. It's hard to compare. Plus Go compilation speed/test running provides quick iteration for LLMs.
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.
Setting aside the problems of wrong but compiling code. Wrong and non-compiling code is also much easier to deal with. For training an LLM, you have an objective fitness function to detect compilation errors.
For using an LLM, you can embed the LLM itself in a larger system that checks it's output and either re-rolls on errors, or invokes something to fix the errors.