> There's lunatics ...
I think the problem is people calling developers "lunatics" and telling them which languages they must use and which software they must not rewrite.
Battle tested is not bulletproof: https://cybersecuritynews.com/sudo-linux-vulnerability/
Applying strict compile time rules makes software better. And with time it will also become battle tested.
My point is against rewrites of critical software for the point of rewriting it *insert my favorite language*. Zig is also a safer language than C, so are many other alternatives, yet the Zig community is not obsessed in rewriting old software but writing new one. And the Zig compiler has excellent C interop (in fact it can compile C/C++), yet the community is more focused in writing new software.
There are many factors that make software reliable, it's not just a matter of pretty types and memory safety, there's factors like platform/language stability, skill and expertise of the authors, development speed and feedback.
In this specific case we are talking about the maintainer adding a new language into the existing codebase.
I think refactoring parts of the software in the new language is what you call "rewrite" here, correct?
So what improvements does it bring? You actually answered it yourself:
> it's not just a matter of pretty types and memory safety
So indeed, stricter/stronger type system and additional automatic compile time and runtime checks are a major improvement.
> platform
As already mentioned in this thread: neither of the platforms lacking Rust were supported officially anyways.
> language stability
Rust is extremely stable and backwards compatible - 1.0 code still compiles without any issues on 1.90 and will continue to do so for the forseeable future.
> skill and expertise of the authors
The same developers continuing to contribute and newcoming developers have more checks in place to prevent bugs.
> development speed
I guess you imply here that developing in C++ is faster. It's in fact not if your aim is to produce correct software. There are so many more things to keep in mind and take care of with C++, you have fewer automatic checks being done by the compiler and the type system.
About Zig: it's a nice language and much more comfortable to use than C/C++ IMO, but compared to Rust it lacks in strictness and safety, so added benefits are smaller and fewer if you put away subjective preferences.
Because you're replacing a real point with a made up one, the reason for rewriting is to get the critical benefits for critical software, which battle testing has shown can't be had in the current language, not "my favorite"
> Zig community is not obsessed
They don't even have a 1.0 language? You're also ignoring the critical difference in the level of safety
https://www.oligo.security/blog/new-sudo-vulnerabilities-cve...
And by the way, we had to replace almost all of the basic Unix tools at the turn of the century because they were completely unfit for purpose. There aren't many left.
This holds for many things in C
What would length represent? Bytes? Code points?
Anyway, I think what you are asking for already exists in the excellent ICU library.
And it's not a very easy thing to maintain. Unicode stuff changes more often than you might think and it can be political.
If it were correct, we wouldn't see these issues continue to pop up. But we do.
Of course there's a risk that new issues are introduced, but again, that depends a lot on the verification suite for the existing tool.
Also, just because someone did a port, doesn't mean it has to be adopted or that it should replace the original. That's open source / the UNIX mentality.
Supporting Rust attracts contributors, and those contributors are much less likely to introduce vulnerabilities in Rust when contributing vs alternatives.
There's lunatics that want to replace basic Unix tools like sudo, etc, that are battle tested since ages which has been a mess of bugs till now.
Instead Rust should find it's niches beyond rewriting what works, but tackling what doesn't.