The bit about how hard it is to store all that plastic fruit and get it ready on demand for your mock store is just one of the most on-point comments about testing at scale ever. Instantly shared with several teams at my job.
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.
I didn’t expect something like this from Cadey, always seemed like a go advocate. (See also the fun hello-world compilation test with big functions.) I’ll still bet we’ll see another post about all the things that are (still) hard to get working in rust, in contrast to more mature ecosystems :)
Expect the unexpected. I’m hitting a point in my career (and understanding of programming) where I really think that more elaborate tools are better. I gotta do a lot more with Rust to get fully up to speed on it, but so far I think it is a lot more fair to trade slower development time for more correctness.
Nice to hear and wasn’t meant offensive. My second point was more from my own experience. Though it really depends on the use case.
It does, but correctness is probably a lot more important than developer efficiency. At least if you don’t want to wake people like me up at 3 AM :)
I hold a slightly different belief: correctness enables developer efficiency. In all its forms (type systems, test suits, formal proofs, module invariants, &c.), it enables developers to stop worrying about different things. The more background cycles you can free up to work on the actual problem, the more productive your developers become.
Types both direct me towards solutions AND check my solutions, at the SAME TIME.
I think the phrase “slow is smooth and smooth is fast” is applicable here.
IMO Correctness costs early, and pays off later. Maintenance is always easier the more explicit everything is, because you’re always shuffling different contexts in and out of your meat cache, and when you can’t see information in the code you’re looking at, you have to constantly stop and go hunting for it.
Having coded rust for a while and used typical GC-based langs as well, I can totally see both sides. Especially when you also add the ecosystem into the mix. For some it’s faster to build stuff and also remove it fast again, the overhead to get it truly right isn’t worth it. I personally strive for the opposite but sometimes it’s really hard to sell this.
I spent a lot of time looking at green tests and flames in production, and decided there had to be a better way to catch problems before they set prod on fire. Now I’m all about the types.
Would be interesting to hear how this turns out. Most of my experience is from writing async stuff pre async/await, so I’m curious how it feels now. (Haven’t had the time to switch over my projects.)
I feel this, in fact I feel a take brewing but I don’t have it fully realized yet.
We have this eternal tension between “developer efficiency” which usually means, maybe simplicity however you may define it or intuitiveness (also subjective of course) and lack of friction to get up and running, and correctness which means robust software that handles many error cases and can self correct in some cases… but maybe this is a false dichotomy.
I am thinking of musical instruments, where in order to really express yourself it takes years of effort to become fluent technically. nobody bats an eye at this, but we all also appreciate that the easiest way to play liszt on the piano is to put a bluetooth speaker on the top of it and connect it to spotify. I’m joking, but not by much.
Anyway what I’m getting at is that the sharpest tools cut the most easily, which is axiomatic and we all laugh at the C jokes, but why shouldn’t it take a lot of effort to become fluent in them?
This isn’t really a well thought out take but maybe you see what I’m getting at.
Be careful, nowadays your attitude that using tools properly might take years of practice is often dismissed as “gatekeeping”.
What kind of stuff are you looking to make with Rust?
So far I’m easing into what I know really well: chatbots and webapps. Eventually I hope to port Olin to Rust and use it as the backend for wasmcloud. I’ve started to work on something for this here, but right now it’s a very elaborate hello world :)
Here’s my first real public facing one: https://printerfacts.cetacean.club Here’s the source code: https://github.com/Xe/printerfacts
Very cool, looking forward to reading more about that in the future.
Interesting view. How do you feel about tools like Ada Spark, Agda, and others that try even harder for correctness?
I have no opinion on them because I haven’t used them yet.