|
>> At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, > Yes, but some (e.g. ripgrep) don't actually do the same thing as the programs they are supposed to "re-implement". Most Rust "re-implementations" don't actually re-implement programs, they are new programs doing a similar-but-not-quite-the-same thing to the older C implementations. For example, ripgrep is neither GNU or POSIX compliant, and therefore it is not a re-implementation. That ripgrep isn't GNU or POSIX compliant is indeed a distinction worth making, but certainly not in this context. You're taking on a very pedantic interpretation of "re-implementation" here that doesn't really matter to the general point. Specifically: > At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, etc. A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. None of this requires any of the "re-implementations" to be 100% strict bug-for-bug compatible tools. This general confusion comes up so often that I have a FAQ item for it: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos... |
It is a worthwhile distinction, because the "re-implementation" talked about is often materially different, to the point that it no longer adheres to what little standardization there is.
So realistically we are talking about a new product, or a radical evolution of an existing one. It and everything above it also have to change.