"Not necessarily Rust — Go, Zig, and anything else with a real type system and compile-time checks gets the same tailwind. Rust just happens to have the strictest compiler and the most to gain when “strict” stops being a cost. "
You either have a strict compiler for your language or you have to write more tests for your code.
Last month I wrote a dynamic malware analysis tool in Rust. About 20,000 lines of it. Process management, threading, memory management, the whole stack. I don’t know Rust
If you really cared about that, you wouldn't have picked Rust. Nim or Haskell are terser languages.
> Every language we’ve built defaults to sequential execution with parallelism bolted on.
False and misleading statement. Array languages have been around for a long time, but you didn't care to learn them.
> Formal verifiability. Move beyond type checking to compile-time proofs.
Good luck with your tokens budget for proof providing. LLMs won't solve that for you. If you believe that proofs are as simple as matching API calling inerfaces you're wrong.
> Declared effects. Every function explicitly states what it reads, writes, and depends on, machine-enforced.
Good functions are pure functions that have no effects. Good design tries to minimize the number of effects needed and maximize the footprint of pure functions mapped over inputs and outputs. If you insist that every function needs an explicit effect annotation, you don't know the topic and you haven't worked with effect systems much.
While rust protects against passing and assigning the wrong types and leaving dangling pointers, it does not protect against writing inefficient garbage.
> With Rust, the actual compiler did the babysitting. The agent could be sloppy and the language wouldn’t let the sloppiness ship.
If you really don't know Rust or its best design patterns (which the authors says they dont), your agent can absolutely write garbage code that still fails. Rust doesnt make writing bad code impossible or is some magical solution to computer languages. What a nonsense article
reply