Would anybody suggest Rust for prototyping?
Rust can do both, about two years ago at work we wrote a ~300LOC middleware to handle redirects.
Then proceeded to put that in front of the full request traffic of the company. This was our first Rust project, but a massive success: it took a reasonable amount of time to put the tool into production, the compiler said no a couple of times, but rightly so. The memory/cpu usage of the middleware were ridiculously low, even though it dealt with millions of redirects. Integrating cuckoo hashing, a LRU cache, and a database backend was easy. Zero production problems afterwards, because this thing just worked once it compiled.
Ok, so 300 LOC is not exactly complex, but that’s not the point. This middleware was a part of a surreally complex project and that’s how prototypes should work: you identify part of a complex project, cordon it off and then prototype and implement it. Parallelize and iterate with everything and your complex project ends up being viable. Rust allowed us to get in, solve a problem, operate it in production and have it work reliably with a low maintenance overhead.
I would say yes, because Rust-without-lifetimes* hits a sweet spot of letting you focus on structure without getting distracted by (as many) runtime bugs.
*Writing fresh code, you can get away with cloning everything and having &mut self being the only borrow-y part.
Lots of clone() and unwrap() and coding is quick, I suppose. Those can be easily searched for to clean it up once the design is stable. This clean up will surely be painful but you just pay off the technical debt accumulated to finish the prototype quickly.
I prototyped some code in Rust that used lots of clone and had an overabundance of Rc. Once I had it correct and a full suite of tests proving it’s behavior the compiler guided me on the refactoring. Just removing the Rc usage got me a 6x speedup on benchmarks.
I don’t think using Rust obviates the truism “First make it correct. Then make it fast”. Instead it allows you to use the compiler and the types to guide your make it fast refactoring and know that you didn’t break the code in non-obvious harder to test ways.
That’s basically what I do. It’s actually not too difficult in my experience ’cause the compiler is so good at guiding you. The hard part happens before that, when you structure things correctly.
Rust without lifetimes is OCaml (or ReasonML for those offended by OCaml’s syntax) :)
I wonder if there would be a market for a simpler, runtime-checked, GC, lang that’s a subset of rust syntax that you could use on a per-module basis for prototyping, but still keeps the non-safety-related structures and idioms that real rust code uses, to aid porting to “safe mode” later if you want to keep it?
Sort of like the anti-typescript, but instead of adding some type safety, you keep the types but lose the borrow checker, and you pay for it with performance. But not by writing different code where you fill it with calls to cells and ref counts and such, rather you leave those annotations outand they just get added in during compilation / interpretation.
If you could do it without perverting the syntax much, it’d surely be easier to port from than if you say, just wrote your PoC in Python or JS.
Really depends on what and how much you think you’ll have to refactor. Rewrites that challenge bigger architectural decisions are more costly in my experience with hobby (!) rust projects.
But if your protocol / API is stable, I’d go with rust from the start.
I prototype with python, and gradually improve reliability with static typing (i.e. mypy) and unittests. Rust is great, but it’s correctness guarantees require an upfront cost which will likely penalise rapid prototyping. It all depends though.
On embedded systems, Rust is amazing for prototyping, especially compared to C or C++. It has a proper ecosystem, and debugging Rust’s compiler errors is far, far superior to debugging runtime bugs on the board.
When I was in school (late ‘90s) we used Mathematica a great deal. That was very similar to the notebooks mentioned in this post, and shared most of the pain points enumerated there if memory serves. Even though “data science” wasn’t really a thing then.
I think some of the issues may actually just be inherent in the approach and might be best addressed in some sort of “publication” toolchain that takes a notebook, normalizes inputs, bundles dependencies and takes other preparatory steps for sharing it. Merging these steps into the notebooks themselves might add enough heft to them that it eliminates or severely reduces the advantages they carry vs just writing software.
I wonder if you could have a NixOS configuration.nix per notebook that gets merged into one Jupyter service.
Why is the response to the Rust community slut shaming a developer into abandoning their project a dress code instead of making clear that en-masse harassment is not ok?
Because its better to address the root cause? I’d prefer the Rust community remains positive and constructive. The childhood lesson can be left for the developers that misbehaved.
This already happened enough in other threads. For example https://words.steveklabnik.com/a-sad-day-for-rust
And it is very reasonable to decide on how we can handle safety expectations like these, which fuel the mob.