|
|
|
|
|
|
by gspr
1849 days ago
|
|
|
I wholeheartedly agree. Especially since one huge strength of Rust is its C interoperability, one would imagine that incrementally replacing or extending parts of the legacy tools would be a much more sound approach. But of course, the point you make does answer this: > And a lot of those projects are just someone’s pet project, often written as a task for learning Rust, and certainly likely to have numerous new bugs that haven’t yet been found just by virtue of being a ground up rewrite. Many of the replacements are indeed not meant to actually replace the tools. They're learning projects. That's great, but it's a bit scary that people wanna use them for anything else. |
|
|
When it is unlikely that the maintainers of existing tool written in C would accept pull requests that add Rust as a dependency (and I imagine this would usually be the case), why wouldn't you start anew? It also allows easier experimentation on the architecture of the original tool, and breaking compatibility. For example, ripgrep isn't a drop-in replacement for grep and the author never intends it to be, so forking grep probably wouldn't have made it easier to develop.
I think the difference between a learning project and a "real" project is mostly how many people end up using it.