I wish the article had started with “I don’t really care” about safety, and by extension, security issues.

It’s putting your head in the sand to hold this perspective in modern computing. The funny thing is, I don’t disagree with the author’s contention that Rust derived from C++, but this completely ignores the fact that C++ directly derives from C!

C++ wanted to make certain patterns in C easier, and to reduce certain foot guns. Rust is in essence, a reimagination if that same effort, but includes the next 30 years of language research in its design to overcome those same problems.

So Rust does derive from C. But who cares? It’s a different language, if you like Go more because it’s closer to what you think of as C, then use that. But don’t kid yourself that C safety concerns don’t have practical implications in the real world.

I would say if you rewrite it and have more bugs, you must have no understanding of the existing codebase, or understand so little of it you shouldn't be the one rewriting it regardless.

All the rewrites I have done have resulted in leaner codebases with fewer potentials for bugs. I think people take some article one software developer wrote almost two decades ago as gospel, but "second system syndrome" doesn't have to be a syndrome.

This "rewrite" fear is exactly why our banks are stuck on 1970s and 80s code with an almost 60 year old programming language and no one left to take over maintenance. Eventually we need to get over this fear.

I guess you disagree with the likes of [1] then. Presumably it depends on the age and complexity of your project.

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Absolutely, and some people _really_ care about these things. Especially in my domain where things are safety critical like avionics/robotics we absolutely do not want to segfault and fall out of the sky or have degraded capabilities. I have found a lot of interest in using Rust in this domain exactly because of the safety. Especially with the awesome work that RustBelt[1] has done.

Further a compiler that verifies memory safety for you can save an incredible amount of money when otherwise you would need to manually prove memory safety.

[1]: http://plv.mpi-sws.org/rustbelt/

Yeah that's what stands out to me as well. I wish the author had put that sentence at the top. The biggest feature of Rust is it's safety. If you don't care for the biggest feature of a language then it shouldn't be a surprise that you don't like the language.

Having written Rust code for 4 years, I'd say it's not the biggest feature of Rust. It's just one of many good points. Among my favorite are the explicit & rich APIs, high level concepts (ADTs, pattern-matching, trait-based generics), and Cargo. The safety does play a big role in shaping some of the features though, and enabling some powerful APIs and optimizations.

Not to mention that segfaulting is if you're lucky. Otherwise, you run into undefined behavior and the code keeps running.

I'm not sure why a programmer who is making something for others would even say 'I don't care'. Someone wrote a post saying that python was slow and they don't care.

Users do care. They care if something is fast, they care if it bloated and takes forever to load, or if it crashes or if it is insecure.

Sure you can have nice things, they're there - just use them to create the 'next big thing' and the nice things will hitch a ride on its fame. Trying to push others to use those nice things does not work as long as those others prefer to use what they consider to be their tried-and-true older but nicer things.

imho he probably meant for experienced engineers we don't really care because knowing what's underneath is way more expert than learning another language/funny syntax which tries so hard using name mangling type system to hide it.

“Smart engineers won’t make that mistake” has been shown to be false on a constant basis.