A thing I've read in a couple places: "I like Rust, but it limits my speed of prototyping, either because of it's strict borrow semantics, static type system, etc. so I prototype in Go/Python/blah" There's sortof two questions that pop up for me.
- Why shouldn't Rust have a quick_n_dirty (or non_strict, if you're feeling serious) attribute, like this thread from a couple months ago mused over?
(Sub question as to what quick_n_dirty actually means, but I think a loosening of some invariants around the borrow checker and trait requirements wouldn't be insane)
This other thread explored some ideas for what prototyping could be like. Tossing everything on the heap, assuming clones, and auto-unwrapping results stood out to me. Developing guidelines for prototyping with Rust
- Most of the code I write is in the "must be correct, security and performance matter" bucket. I'm not sure I'd actually use a "quick_n_dirty" prototype mode if it existed. My brief experience using Golang suggests that it sortof approximates what I'd want in a prototyping mode in quick-compiling and simplicity, but is so restricted in language features that I'd just as rather start in Rust. I can see the argument for dynamically typed language prototyping more clearly, but Rust's never going to want to do that. So TLDR on that: If you prototype in another language and port to Rust, I'd love to know what that language does for your prototyping process.