3 ms·
Both viewpoints make sense; whether Rust is good for prototyping depends on the domain. If it fits the borrow checker well (like in CLI apps, stateless servers
by verdagon 4y ago
Both viewpoints make sense; whether Rust is good for prototyping depends on the domain.
If it fits the borrow checker well (like in CLI apps, stateless servers, data transformation) then the borrow checker fits beautifully and seamlessly.
In other settings (complex turn-based games, some compilers, GUI), the borrow checker can cause some artificial complexity and prototyping slowdowns compared to other paradigms.
- jjnoakes 4y agoI guess it depends on your point of view. For me, having Rust catch issues even when prototyping makes me enjoy prototyping more. I absolutely hate (even when prototyping) when I try to run something, it chugs along for a bit, and then hits a runtime error due to some stupid typo. In fact I like Rust for prototyping precisely because I don't yet have tests, and the extra compiler diligence frees me to focus on the prototype.
- menaerus 4y ago> and then hits a runtime error due to some stupid typo. I don't think that the parent comment implied prototyping in dynamic languages but rather in statically compiled ones. FWIW in C or C++ you don't have to do as much code gymnastics to satisfy the compiler so consequently prototyping is both faster and easier when compared to Rust.
- jjnoakes 4y agoAgain for me personally, I find the opposite true. With C and C++ I'll find that once in a while, quick sloppy coding gets me something that seems to work for a bit and then fails in subtle and hard to debug ways. That's a time sink that just doesn't exist when I whip something together in Rust.