I'm not sold on Rust being a great language to use with AI unless the reason to use it is a lot more than just Rust being fashionable.
If the LLM gives you safe code you know there are entire classes of things you don't have to review for.
That said, I agree with you. My experience is that LLMs are great if you are highly competent in the domain in which you let them work. And it's probably easier to be competent in Go than in Rust.
The process of designing a program like that itself catches a lot of "badly designed code". And such a design also naturally exposes many kinds of intentional backdoors, because security properties can quite easily be statically checked. For example, IDORs can be made literally impossible in such a design.
In discussions like this, I'm reminded of the William Gibson quote, "the future is already here, it's just unevenly distributed."
Relative to C/C++? That'll be very interesting. Do you have some evidence that LLMs can create memory-safe code in C/C++? It'll be truly amazing if true, but given that they apparently struggle to create/maintain big codebases in already-memory-safe languages I seriously doubt it.
Writing code so that impossible states are impossible is one of the hardest parts of software, so a good type system means that the code compiling means that the software is validated to be unable to represent certain states which is a very high bar of validation.
I suppose in your mind you were thinking of more trivial errors like typos, accessing variables that aren't available in scope, and such.
This is the main reason I use Rust over Go these days. The simplicity of Go was great for when I had to hold everything in my head and write everything myself. Rust makes more sense to me in the LLM era where I can offload more modeling/assumptions/invariants to the type system without having to be a Rust veteran.
The pinned invariants in my plan/spec become first-class invariants in the type system. It's great.
For me, one of the bigger complaints is that Rust isn't pedantic enough. Panic free Rust isn't taken seriously enough as an idea.
I wish it would catch even more things, since it works so well.
Go is too verbose and the type system isn't expressive enough. Rust code is littered with little memory management details and it requires tons of third party libraries.
I think coding agents will eventually be able to get the low level details right on their own. Reviewers should be able to focus on architecture, design and logic mistakes.
I also think we need a high level formal specification language to tell agents what we expect them to do.
Let’s make that specification Turing complete while at it.
Jokes aside, IMO it will be a good natural progression. Specify the problem statement in LLM specification, generate the code in Go/Rust whatever is the language of your choice and review the generated code to make sure it adheres to the architecture/design principles that you have set.
It doesn't have to be a new language. I'm sure some existing language can be used to create a DSL that serves this purpose.
It can obviously never be complete. Some parts of the spec will always have to be natural language if we want to make the best use of LLMs.
Aah, I am sure the chickens of vibe coded origin, will never come to roost.
The usual reaction or opinion from e.g. good C++ programmers switching to Rust is that the added guardrails and expressivity are great and make things easier.
The verbose error handling diluting the interesting parts is one thing, but the main issue is the weak type system. Having to read the callee's code to check if it deviates from `res xor err`, or if it mutates its arguments. Figuring out which interface that `func (o *Obj) ()` is implementing, if any. Dealing with documentation that is a wall of 100 disappointing oneliners all repeating the function name.
Rust is information-dense and takes longer to master, but it's not inherently cryptic, there's a finite amount of things to know. Memory management sometimes take a bit of thought to write, but it's straightforward to review, you can trust it's correct if it compiles, you just keep an eye out for optimizations.
In my opinion these problems originate in architectural style. Much of the open source written today is designed to impress the audience instead of focusing on the problem.
Compared to Rust, Go as a language requires a lot more effort to review. You have to be on the lookout for basic gotchas like not checking if a pointer is nil, placing `defer` in the wrong place, using a result when err isn't nil, and so on. Plus, diffs are messier because unused variables are a compilation error, and _, err := can change into _, err = solely due to new lines above.
Absolutely insane syntax choice in a language where everything returns 2 values. At least do var:, err: =
