9.1 KiB
+++ title = "A modern CLI renaissance?" date = 2024-03-04T12:20:02-06:00 draft = true +++
Take a look at this table at the bottom of the page. Ill wait. Notice the relative scarcity between ~1995 and ~2015? Id like to talk about a trend Ive seen these past few years, where people are rewriting and rethinking staples of the CLI, why I think this trend is a good thing, and why I think this trend might be happening.
History
The terminal has been a staple of computer user interfaces since before computer monitors were available,
with some of the first computers offering an interactive mode in the late 1950's.
The 'modern' Linux terminal traces its linage to the very first version of Unix, in 1971.
Many utilities that a Linux user interacts with every day,
commands like rm, cat, cd, cp, man and a host of other core commands trace their initial versions to this first version of Unix.
Other tools are a bit newer, such as sed (1974), diff (1974) bc (1975), make (1976) or vi (1976).
There were a few more tools introduced in the 90's, such as vim (1991) and ssh, (1995), but you get the picture.
The majority of the foundational CLI tools on a Linux pc, even one installed yesterday, are older than Linux itself is.
Ok, so?
Now, theres nothing wrong with this, the tools work fine still, but, in the half-century since they were first written, Terminals and the broader Linux ecosystem have all changed. Terminals now have capacity to display more colours, Unicode symbols, and even inline images. Terminal programs now coexist with graphical user interfaces, and only a small subset of computer users even know they exist, wheras in the past, terminals were the only way one interacted with the computer.
Additionally, and perhaps more importantly, our knowledge has expanded, our knowledge of user interfaces, of what works and what doesnt, of what usecases are common and what usecases are niche, the way that error messages can teach, the value of a good out of the box experience, and the value of documentation that is easy to find and digest.
Exploration of the solution space
These changes to the environment surrounding CLI apps has in recent years, led to a resurgence in development of command line utilities. Instead of just developing completely new tools, Ive noticed that people are rethinking and reinventing tools that have existed since the early days of Unix.
The lessons learned from the past
A large amount of the innovation in the area, I think, can be attributed to lessons that have been learned in 50 years of using software; sharp edges we have repeatedly cut ourselves on, unintuitive interfaces that repeatedly trip us up, and growing frustration at the limitations that maintaining decades of backwards compatibility imposes on our tools.
These lessons have been gathering in the collective conciousness, through cheatsheets, guides, and FAQs; resources to guide us through esoteric error messages, complex configurations, and dozens upon dozens of flags.
Id like to go over a couple of the more prominent lessons that I feel terminal tools have learned in the past several decades.
A good out of the box experience
While configurability is great, one should not need to learn a new configuration language and dozens or hundreds of options to get a usable piece of software. Configuration should be for customization, not setup.
One of the earliest examples of this principle may be the fish shell. Both zsh and fish have powerful prompt and autocompletion engines, but zsh requires you to setup a custom prompt and enable completions in order to use the features that set it apart from the competition. With no config file, zsh is no better than bash. When starting fish for the first time, however, its powerful autocompletion and information rich prompt are front and center with no configuration required. Of course, fish still has the same level of configurability as zsh, it just also has sensible defaults.
Friendly error messages
Concise and discoverable documentation
Common usecases should be easy
Shedding historical baggage
The trendsetter
The languages
Appendix: the tools
This is an extremely unscientific table of command line tools that I have tried, have used, or currently use. It is assuredly incomplete, but should be broadly representative. The date data has been gathered from the first git commit where available, wikipedia otherwise, and sorting is by year first, then alphabetical.
| tool | year | language |
|---|---|---|
| ls | 1961 | c |
| cat | 1971 | c |
| cd | 1971 | c |
| cp | 1971 | c |
| man | 1971 | c |
| rm | 1971 | c |
| grep | 1973 | c |
| diff | 1974 | c |
| sed | 1974 | c |
| bc | 1975 | c |
| make | 1976 | c |
| vi | 1976 | c |
| awk | 1985 | c |
| screen | 1987 | c |
| vim | 1991 | c |
| midnight commander | 1994 | c |
| ssh | 1995 | c |
| fossil | 2006 | c |
| tmux | 2007 | c |
| git | 2008 | c |
| go 1.0 | 2012 | go |
| fzf | 2013 | go |
| eza/exa | 2014 | rust |
| neovim | 2015 | c |
| pueue | 2015 | rust |
| rust 1.0 | 2015 | rust |
| just | 2016 | rust |
| micro | 2016 | go |
| nnn | 2016 | c |
| ripgrep | 2016 | rust |
| fd | 2017 | rust |
| bat | 2018 | rust |
| broot | 2018 | rust |
| difftastic | 2018 | rust |
| hyperfine | 2018 | rust |
| lazygit | 2018 | go |
| lsd | 2018 | rust |
| nushell | 2018 | rust |
| scc | 2018 | go |
| sd | 2018 | rust |
| git-delta | 2019 | rust |
| grex | 2019 | rust |
| starship | 2019 | rust |
| tre | 2019 | rust |
| typst | 2019 | rust |
| diskonaut | 2020 | rust |
| helix | 2020 | rust |
| pijul | 2020 | rust |
| zellij | 2020 | rust |
| zoxide | 2020 | rust |
| btop | 2021 | c++ |
| ast-grep | 2022 | rust |
| yazi | 2024 | rust |