3 ms·
How much of it is because there's a reason (of sorts), to do a complete re-think, when you're porting tools over? C and C++ have been stable for years, and so
by sk0g 8y ago
How much of it is because there's a reason (of sorts), to do a complete re-think, when you're porting tools over?
C and C++ have been stable for years, and so has all the little UNIX tooling that was built using them. People are excited by Rust, and take it upon themselves to re-build these tools, as they have well defined requirements and characteristics.
The reason these tools might be better is because thought has gone in to modernising and enhancing existing features. That might not be so feasible/ easily doable if you were juggling a decades old codebase to start off with.
I'm not sure what my point is, entirely... But ripgrep is good! I have replaced awk and grep with it, because it just feels more... user friendly?
EDIT: remembered my point. Are you switching to Rust tools because they are written in rust/ benefit from Rust in some unique way, or because it's a common platform people are re-implementing and re-imagining classic UNIX tools in?
- benatkin 8y agoIt’s because I want something that’s been re-imagined, yes.
- feanaro 8y ago> Are you switching to Rust tools because they are written in rust/ benefit from Rust in some unique way, or because it's a common platform people are re-implementing and re-imagining classic UNIX tools in? I think it's a little bit of both for me. The Rust tools tend to have a nicer UX (pretty-printing, colouring by default, with smart detection whether output is to a terminal, subcommand-oriented CLI a la git, etc). This is probably a consequence of nice library defaults but also a matter of culture. They also tend to be very fast. Again, Rust is inherently inducive to writing fast tools, but you also have to do things the right way.