I don't agree. I think the author is conflating two things:
1. learning Rust, and
2. using Rust.
If you take away "Rust made us slow because our team had to learn how to use it and thus we had slow iterations and it's harder to find hires with Rust knowledge" from the equation, then you aren't left with much argument against using Rust early.
The iteration time issue with Rust is solved by experience. We use Rust and our iteration times are average. What we gain is not performance, that's not a reason we use Rust (for an early stage startup, totally agree you burn credits until you can afford to care). We gain correctness. And at an early stage, correctness without paying for a massive QA team is a huge boon.
There are definitely more mature tools for quickly standing up CRUD APIs. If you want a framework that can bootstrap you into an OpenAPI with docgen, swagger, all the bells and whistles, Rust doesn't do that. But Rust will help force you to write correct code that never crashes and handles edge cases it's easy to forget about when moving fast in a duck typed language.
The only language we seriously considered over Rust was Swift. But Swift's just wasn't quite there yet. It might be today. If I was starting something from ground zero today, I'd probably lean towards Swift and need to be argued down back to Rust or Python.
The author touches on why it matters in the article - either you have to restrict hiring to folks who are already rust experts (much smaller hiring pool, also usually meaning higher comp expectations) - or you have to consider the cost of training new/existing staff on Rust. Rust has a notoriously difficult learning curve, especially to folks who don't have a background in C/C++. As the author mentions, you may be looking at 6+ month ramp up time until new hires can comfortably write non-throwaway tech-debt free production code. For many startups looking to iterate quickly, that's just too slow.
Conversely if you are looking to hire Java folks, you'll have an enormous pool to pick from, or if you need to train somebody in eg Go - you can do that significantly quicker than you could with Rust.
I was putting that argument aside because that's an argument you can make for any language and it changes depending on who you know, what circles you're in, etc. It's and externality not specific to Rust. You can say the same for Erlang, or Swift, or C#, or ...insert language that isn't JavaScript.
What I'm saying is that, disregarding the externalities, I've found Rust to be quite a boon and not inherently a bad fit for an early stage. YMMV.
Leaving joke languages aside, it is very much true. If you use less lines of code to implement a software feature, the software feature will on average have less bugs.
Programmers write bugs per line, something like Python which only uses 33% of the lines and thus contains only around 33% of the bugs. On the other hand, if you go down the prove things are correct at compile time you will eliminate around 5% of the bugs.
So you can choice between eliminating 67% of the bugs by making the language simpler to use or 5% of the bugs by doing formal checking.
Just finished my learning Rust project (very basic version of minecraft). It's great for writing highly parallel high performance code.
At no point was the memory of my program ever replaced with the number 53 nor did memory become corrupt due to multiple threads accessing the same areas at the same time. Much better than C++.
Did my Rust project suddenly contain no errors or did it never crash? Well no. How did it crash?
Array indexing (called default instead of new which created an invalid version of the struct)
Infinite loop (logic error causing it to add the result each loop to the input vector rather than the output vector).
That said Rust is almost certainly going to kill C++. It's a lot better.
By definition this is true. Duct type languages don't care about whether your program is expected to work at compile time. They just run it and hope it does so it's all "logic errors".
I've experienced an array indexing issue in Rust exactly once and when it happened the stack trace told me exactly where and then I did exactly what you did: changed default to new or something and called append instead of my_vec[N] = foo. This issue was caught in my test btw.
That leaves infinite loop which is a problem in any language if you aren't intending to loop infinitely. So it's simply not something Rust fixes. I must say the number if times I've had a program infinitely loop and it be a problem that made it through a basic test of the logic is minuscule compared to the number of times I've had a program just shit the bed with poorly managed pointers or corrupt memory.
So you're basically proving our point. Rust eliminated all your bugs except an infinite loop and an array index out of bounds. I bet your mincraft clone is running flawlessly and you have Rust to thank.
What Rust has shown me is that programmers by and far make more unforced semantic errors (like not properly managing a pointer or accessing memory without proper synchronization) than they do logic errors. When you remove all the silly BS errors, you're left with surprisingly few problems to solve and you can almost surely blame yourself and find and fix the issue when one does crop up. It's way different. If you haven't, try writing Minecraft in Java.
I think the metric you’re looking for is bugs per line not raw total bugs. Bugger programs have more bugs is trivially true if all programs had the same rate of bugs per line.
1. learning Rust, and 2. using Rust.
If you take away "Rust made us slow because our team had to learn how to use it and thus we had slow iterations and it's harder to find hires with Rust knowledge" from the equation, then you aren't left with much argument against using Rust early.
The iteration time issue with Rust is solved by experience. We use Rust and our iteration times are average. What we gain is not performance, that's not a reason we use Rust (for an early stage startup, totally agree you burn credits until you can afford to care). We gain correctness. And at an early stage, correctness without paying for a massive QA team is a huge boon.
There are definitely more mature tools for quickly standing up CRUD APIs. If you want a framework that can bootstrap you into an OpenAPI with docgen, swagger, all the bells and whistles, Rust doesn't do that. But Rust will help force you to write correct code that never crashes and handles edge cases it's easy to forget about when moving fast in a duck typed language.
The only language we seriously considered over Rust was Swift. But Swift's just wasn't quite there yet. It might be today. If I was starting something from ground zero today, I'd probably lean towards Swift and need to be argued down back to Rust or Python.