If you can't prototype, you can't release prematurely.
Memory safety. That's the super power that launched Rust into the minds of modern developers.
Wired describes the popularity of Rust as a "viral secure language," lauding its resistance to buggy memory conditions known as "out-of-bounds access," and "reuse of memory after free." And yet...
I find myself lukewarm to the language. While memory insecurity is a problem, it is not an existential one. Indeed, the problem has largely been addressed in C++ with Resource Acquisition Is Initialization (
RAII) which uses the
symmetry of constructors and destructors for resource allocation and de-allocation. As for accidentally reusing freed pointers, setting them to NULL after a free neutralizes any downstream threats, but this defensive practice has been largely ignored or forgotten. The real quandry is finding developers with the interest, patience, and care to actively manage memory, and Rust solves that dilemma by forcing developers to pay attention, or the code just won't compile.
Victor Ronin -- entrepreneur, manager, software engineer -- shared his progress on learning Rust on
Medium. Further along than I, his position is love-hate to my lukewarm, but I do find myself nodding in agreement to what he describes as the good, the bad, and the ugly parts of Rust. And yet...
Where Ronin sees a bad feature of Rust, I see a super power that is both good and bad. But first, in Ronin's words:
... You can write things [in C/C++] dirty (don’t free memory, don’t have the perfect protection against race conditions). You can throw something together to check that your basic premise works and, after, clean it up.
This is impossible in Rust. You are either 0% done (nothing builds) or 100% done (everything works and has no undefined behavior). Nothing in the between. ...
In other words, you can't prototype in Rust. The ability to prototype is extremely important, and goes beyond experimenting with new ideas. It helps when learning a language -- to explore its syntax, classes, expressiveness, and limitations. Inhibit prototyping, and Rust raises the barrier to entry to itself. And yet...
In what way is this good? Or even a super power? The answer is, if you can't prototype, you can't release prematurely.
As I reflect on my past projects, more critical than defending against memory leaks was when I defended against premature releases, not just against aggressive management, but also against my own internal optimism. Invariably, after showing off a prototype, there was one person who jokingly (or not) asked when can we release it?
The pressure to release early and often is common in software development, and in hindsight, I wonder about the road not taken. Shouldn't we have modularized this code and put it in a library? Could an additional database field be made part of the index and improve the speed of future searches? Is having a dedicated server dish out unique sequence numbers better than assigning a reserved range of possible values from a local process?
Most egregious were the times a version with minor and dirty issues was released with a promise of a subsequent clean-up release that never happened.
More recently, and much more publicly, X (née Twitter) collapsed during Ron DeSantis' campaign launch. From the article:
“Spaces was largely a prototype, not a finished product,” the ex-employee told CNN. “It’s a beta test that never ended.”
If Twitter Spaces were written in Rust, the launch would not, could not, have been attempted. So, hooray for Rust? Maybe.
Comments