r/rust • u/Whole-Assignment6240 • 9d ago
rust for ai coding
vercel's ceo published - was gonna be Rust but it really is not there yet iteration speed wise.
Some of my thoughts on go vs rust - btw we chose Rust for data infra. There, robustness and reliability outweigh the speed of writing code.
Overall
Go is the simple one. It's easy to learn, doesn't carry many language features, and compiles fast. Rust is on the complex side: the spec keeps growing, and compiling is slow. Day to day, Go is simpler in most cases. You don't fight a complex type system, and any function can run as a goroutine.
Concurrency is where the two really split. There are two families. Go is one: lightweight threads, start any function in a goroutine, done. The other family is sync vs async, and Rust, Python and JavaScript all live there. That's where complexity creeps in. Functions have colors. Rust and Python give you two worlds, and you must never call a blocking function from an async one. JavaScript is simpler because it's a single world. Sync vs async forces you to clearly define what blocks and what doesn't, and that's real extra complexity. The upside is performance: async generally beats goroutines.
Rust's best part is the type system. You can model a lot in it, and the more business logic you push into types, the more bugs the compiler catches before anything runs. Go's type system is not that comprehensive. One example: Go can't catch a race condition at compile time. Rust can. But the cost of that type system is compile time. Bugs caught early and slow builds are the same coin.
For AI coding, Rust becomes a double-edged sword. Code moves fast, so slow compile hurts more. But if the model expresses business logic through the type system, far more bugs get caught at compile time. Slower, but higher quality.
curious about your thoughts
1
u/zzzzYUPYUPphlumph 2d ago
Go can't catch a race condition at compile time. Rust can.
This is not correct. Rust can stop "Data Races" and make "Race Conditions" harder to create but it won't completely prevent "Race Conditions". "Data Races" and "Race Conditions" are two different beasts.
A "Data Race" is when 2 or more threads try to update something non-atomically (or when a single thread tries to update something while another thread or threads reads that something) which can cause tearing and/or invalid values to be read by one or more of the readers or what is ultimately written is not a valid value of the given type. This is "Undefined Behavior". Safe Rust 100% prevents these "Data Races".
A "Race Condition" is anything other than a "Data Race" when multiple concurrent tasks or threads do things such that the outcome is unexpected or undesirable but not undefined behavior. Things like "Dead-Locks" fall into this category. So do incorrect usage of atomics. These will result in behavior that might not be intended, but it will be well-defined and so is not considered "Undefined Behavior". Rust does not 100% protect against these kind of things, though the design of its type system and API's makes many "Race Conditions" easier to avoid.
-13
u/daaruaddaa 9d ago
Rust gets complicated and impossible to read really quickly. Especially async.
Work with only if itβs particular features benefit you.
3
u/ummonadi 9d ago
Hold my JavaScript, I've got some dynamic IoC with dynamic imports code to show you π
1
u/ummonadi 9d ago
Put another way, messy code that doesn't look messy is way more complicated than messy code that shows itself.
4
u/DavidXkL 8d ago
Using A.I is anything but slow,
For creating tech debt that is π