Funny, the Python guys say Python is the best general-purpose language for AI and the Go guys say Go is the best general-purpose language for AI etc etc
Funny, the Python guys say Python is the best general-purpose language for AI and the Go guys say Go is the best general-purpose language for AI etc etc
But on the other hand, the compile time of Rust is really counterproductive. On large, established projects, most prompts I write now spend more time compiling on my machine than they spend outputting tokens. In a way this is great because the tokens are the expensive part, but it does mean that when faster LLMs will come, they will not meaningfully improve iteration speed for me.
I wonder how much of the compile time of Rust is inherent to the type system. There might be room for a language with slower runtime speed (GC?), but as good of a type system as Rust, so long as compile times are much faster. Switching languages has never been easier, anyone have any suggestions? IMO hard requirements are algebraic types and error handling based on them.
But you can speed things up a lot by organizing your project into separate crates (which are compiled in parallel) and tweaking compiler flags. I speed up a large project by 7x this way.
Also, if you’re using fat LTO in release builds, switch to thin. It’s almost as fast at runtime and much much faster to compile.
There is OCaml which compiles very fast in debug mode.
Since it's going to be mostly cargo check and incremental builds, I don't think it matters in practice.
The big difference to Rust is the availability of interpreters, REPL, which can equally load compiled code, and full blown AOT for release builds.
Rust's problem isn't type system, rather lack of tools.
@dataclass @final class CaseA[T]:
field: T
type MyEnum[T] = CaseA[T] | CaseB
This also gets exhaustiveness checking in `match` statements (depending on the type checker). Overall, enums have a similar style to Scala and Java >=21 (mixing OO + ADT). I guess syntactically it can be slightly verbose depending on the exact situation...
I wouldn't call them second class, but yeah, not a lot of existing libraries use this style.Typed dicts (with the latest PEPs) are an improvement over any other language besides TypeScript. Yes, in TS, certainly `Partial` / `Pick` / `Omit` and intersection types make modeling the web API swamp easier, and that's one place TS is superior to anything else.
Python does have the Type Manipulation PEP 827 [1] out to give it similar powers to TS, but I feel that's unlikely to be implemented soon / as-is.
Having an effect system for exceptions would be nice indeed. That's actually something I'm looking into (having an "allowed exceptions" annotation for functions and then checking it at test-time via failure injection and possibly in type checkers).
I realized all the Rust code produced meant squat if it couldnt be audited well afterwards.
With or without AI - doesn't matter. Only at that point you gain understanding of the limitations both of LLMs and of dynamic languages.
edit: Forgot about "Nightmare" difficulty - try enjoying dynamic languages and LLMs when your legacy codebase is earning tens of thousands $ per second.
The question is where the "enough confidence" border lies - and in the worse case the only way to do some reliable investigatios would be printf debugging or its alikes.
Your legacy codebase generates ~300 billion a year?
1. Python has a lot of training data
2. Go runs with the philosophy of one same way to do stuff even further than Python. It’s also typed
3. Rust’s type system and strict compiler is what helps keep AI on guardrails
1. Humans writing code: here the usability, readability, accessibility of the language matters - strictness can be a hurdle depending on how a language is designed, so ultimately it's a trade-off.
2. Humans reviewing AI-authored code: here the requirements of (1) still apply to the code reviewer
3. Autonomous agents writing code: above requirements no longer apply so having a strictly-defined language with tight guardrails is the primary consideration.
I think most people are operating workflows in category (2), but it seems uncontroversial to say Rust is more suited to category (3) than python or golang. Typescript, Haskell, Elm, Ocaml could be considerations but you'll find Rust hard to beat here. Certainly neither python nor golang are in the running at all.
There aren’t many comparative benchmarks, and obviously the design of such a benchmark is difficult, but, e.g. https://arxiv.org/abs/2508.09101
In this benchmark, models can correctly solve Rust problems 61% on first pass — A far cry from other languages such as C# (88%) or Elixir (97%, no static typing whatsoever).
Having to tweak code and compile more often makes things slower, but strict compilers also help you find bugs faster and navigate the codebase. I think the two effects balance out and leave you with safer code in the end. And that's not counting the performance benefits of a compiled language.