How do you know that? Is there any data backing that up?
I've never seen any research showing that a programming language, no matter how strict (Haskell, Ada, Rust) actually improves the reliability of software, except for comparisons between memory-safe and non-memory-safe languages. It almost always goes down nearly entirely to development process and team skills/experience, showing anything else convincingly would be a huge breakthrough.
Well, here's my point of anecdata: despite Python being a very productive language and very easy to use, despite it existing for more than three decades and being perhaps the most massively learned language by aspiring programmers today, you hardly see any stand-alone application written in it. I can name not a single application that I use on a daily basis written in Python. It seems it's strongly confined to the web-server, where the environments are well controlled via containers, runtime bugs impact a single page load and fixes can be applied continuously. People don't ship Python standalone apps.
Based on the buggy and unstable Python desktop apps I have used, I have a strong suspicion that developing large applications in Python is strongly self-limiting after the initial sprint.
I'm speaking from my own experience here. I've tested a couple of Rust programs which were developed in relatively short order yet were quite complex (a Minecraft type game being one) and there wasn't even the slightest hint of instability.
Some of my own Rust code is moderately complex but never showed any signs of instability during development. I often have crashes now and again with my C++ programs. Sure, I fix those afterwards but getting it flawless every time the first time is (for me at least) unheard of.
I'd agree with that too, but that's just my point of view and I'd respect anyone else's sensible argument of the opposite.
But this article isn't that, and to make manual memory management more appealing they had to ridiculously inflate the issues that come with ownership-based memory management…
I think it's you being biased against the article now. As I read it, it was pretty honest and really trying to find some sort of true, not just trying to bash Rust. Feels like Rust fans are very defensive against criticism of any sort, even when well intentioned as I think is the case here.
Author here, I tried to make this article as balanced as possible, and even talked about Rust's advantages in concurrency and encouraging cleaner architectures and the disadvantages of MMM and GC approaches (plus other aspects, see my other comment down-thread about this).
There are actually 45 citations in the article on all angles, but I think you're talking specifically about the anecdotes.
Regarding the anecdotes, I had to add more of those to the borrow checking sections because it was the most surprising to my initial readers. Very little discussion online actually compares borrow checking to higher-level languages with good development velocity; most discussion online compares it to languages like C, C++, Javascript, or Python, so this was new to most readers.
The article also explicitly mentioned that those were anecdotes and colored them differently, so that people didn't mistake them as data.
They also made that part of the article much longer than it was originally.
I can see how that could come across as biased. Perhaps I should have added citations to the other parts of the article so their distribution was more uniform.
When you look at the content itself, it's pretty balanced I'd say (hence the focusing on the other benefits of borrow checking plus the downsides of GC), it's unfortunate that's not coming through as much.
It may slow them down during their initial development when they're new to Rust, but I'm convinced that it will be much cheaper during the entire Application Lifecycle (ALM), not to mention customer satisfaction.
Programs with Rust will always be rock-stable, unlike many C/C++ programs which are more like a house-of-cards.