modern-unix

popular in the past several years, here's a whole list of them: [https://github.com/ibraheemdev/modern-unix](https://github.com/ibraheemdev/modern-…. They sort of get to learn the lessons from software history, and implement more features and some have differences in usability. Its hard to predict the future but could the cycle repeat? What are the odds of someone writing a successor to ripgrep that is as (subjectively) better than ripgrep, as ripgrep is to grep, if not more? (and the possibility of it being written in a systems language designed to succeed languages like Rust, like how Rust is used as an alternative to C, C++, etc.). Or, we have gotten all the features, performance, and ease of use as we can for a CLI that searches text in files? It seems like we don't have more ideas for how to improve that, at least with the way computers are now. Are CLIs like Ripgrep better than grep on 70s Unix machines without much rewriting (if they can be compiled for them), or would they require lots of rewriting to run, perhaps to account for their computer architectures or very low hardware specs? Could computer architectures change much in the next 10-30 years such that Ripgrep would need rewriting to work well on them, and or a successor to Ripgrep wouldn't be out of the question? By architectures I don't mean necessarily CPU architectures, but all the hardware present inside the computers, and the relative performance of CPU RAM Storage etc. to each other. If it would take too much effort, what if someone time traveled to the 70s with a computer with ripgrep and its source code? Could Unix engineers apply any ideas from it into their Unix utils? How much of the improvements in newer tools are simply the results of better ideas for how they should work? Unix engineers did their best to make those tools but would the tools be much better if they had the ideas of these newer tools? Also, I wonder if these newer tools would last longer because computers are accessible to the average person today unlike in the 70s, and the internet allows for many programmers with great ideas to collaborate, and easily distribute software. Correct me if I'm wrong but in the 20th century different unixy OSes have their own implementations of Unix tools like grep find etc. While that still applies to some degree, but now we have very popular successors to Unix tools on Github, If you ask online about alternatives to ones like grep and find, a lot of users will say to use ripgrep and fd, and may even post that link I mentioned above. If you want to make your own Unix OS today, you don't need to make your own implementations of these tools, at least from scratch. I only skimmed the top part but this might be worth looking at: [https://en.wikipedia.org/wiki/Unix\_wars](https://en.wikipedia.org/wiki/Unix_wars). Or none of the above happens?

yable I want to hear about that too! One thing I wish I picked up earlier is a familiarity with Perl regular expressions and basic Perl syntax. Perl seems to be everywhere and being able to whip up a fancy one-liner with lookarounds and embedded code execution can be incredibly useful. I wouldn't say there's a steep learning curve, but, like most things, the skill atrophies if not exercised regularly.