upvote

points

by jolt428 hours ago |
comments
upvoteby EduardoBautista3 hours ago|
next
[-]
I think a lower amount of training data for Haskell might be a reason.
reply
upvoteby hu35 hours ago|
prev|
next
[-]
For core system functionality maybe. But for most applications Rust slow compiler iteration speed becomes a bottleneck when the likes of TypeScript (with Bun) and Go have sub second iteration times.

Plus AI is also good at catching, in other languages, errors that Rust tooling enforces. Like race conditions, use after free, buffer overflows, lifetimes, etc.

So maybe AI will become to ultimate "rust checker" for any language.

reply
upvoteby tnova4 hours ago|
parent|
[-]
In my experience developing different types of applications in Rust, the claims of a "slow compiler" are overstated. Sub second iteration times are definitely a thing in Rust as well, unless you're adding a new dependency for the first time or building fresh.
reply
upvoteby hu32 hours ago|
parent|
[-]
Our experiences clearly differ then. And for others as well since it's a common complain.

Countless time I have seen other people complain as well. There are articles about it even. Can't find the YouTube link now but recently a gamedev abandoned Rust due to compilation speed alone because iteration speed was paramount to their creative process.

Handwaving isn't going to make it any better. And thinking Go/TS compilation speed are comparable to Rust is, a handwave and a half to say the least.

Cargo check and friends are subpar for AI because they actually need to run the thing and unit tests for efficient agentic loops.

A single loop might recompile and rerun the application/unit tests enough times that slow compilers like Rust and Scala become detrimental.

reply
upvoteby tayo427 hours ago|
prev|
[-]
The way Haskell handles memory is weird and can be unpredictable.
reply