Comment by shevy-java
2 days ago
> The main problem with Oh My Zsh is that it adds a lot of unnecessary bloat that affects shell startup time.
Wowsers!
That +0.5 seconds delay will kill cats everywhere. We must microoptimise the startup time of shells!!!
Or ... we could simply use bash and KDE konsole with, say, 10 tabs. That setup works for me since ages; admittedly I use bash just as a wrapper for simple actions as well as calling a gazillion of aliases and mostly ruby scripts that do the real job. But damn I never knew there were guys who were concerned with +0.5 seconds delays caused by oh-my-zsh. The bloat! Oh my godsers!
For terminal-centric workflows, one ends up needing to open dozens of shells throughout the day.
Starting one command, realizing you need info from a previous command, often the fastest way to get that info is to open another terminal and start typing and the copy-pasting the relevant piece of cmd. Or needing the output from another command that's scrolled up in a window. In general you end up with a mosaic of tiles each of which is holding key information. So you inevitably open a new tab to make use of the information in the other 3 or 4 windows.
Shell startup is mainly not about waiting for a few terminals in abstraction, but about the way each shell is just a small piece of a longer live workflow and waiting a second for a shell so that you can fill in a piece of a command feels terrible. I think nushell will help cut down on this unpiped inefficiency, but it's usually much simpler to manually glue bash commands together than to parse text output and pipe.
Plus, how many shell can one individual open in a day ? I'm doing that once per day on a good day, maybe twenty if I have a lot of unplanned work on subprojects that needs to be done concurrently with my main task.
Sometimes hundreds per day. Tabs come and go here. People have different workflows.
Yesterday just shy over 50, according to entries from `login` in the system log.
I do launch multiple interpreters just to get a fancy coloful cowsay on each launch. Which involves the fortune program, lolcat (via ruby) and cowsay itself (via Perl). I probably should optimise that into a single C binary for better startup times! :)
The problem with long startups is that they break the flow. I live in CLI. I open and close terminal windows all day long, sometimes just for quick 2-3 commands to check something. 100 new interactive shells a day is my guess. I already know commands to run, my fingers are ready to type, they already pressed the keys ti spawn a new shell and now they have to stop for 500 ms. Repeat these 100 interruptions every day and you get the death by 1000 spoons.
I don't use oh my zsh, but on one laptop zsh took 600ms to start. I narrowed it down to a strange "bug": adding even a single empty file to the custom fpath caused the slowdown. It bugged me so bad that I decided to try fish again, but this time for real. And this time it stuck with me. I like its architecture (defining functions to change its look-and-feel - great idea!) and of course its 32 ms startup time.
As another commenter, I'm probably at 100s per day.
A reason is that I use i3 workspaces, with each workspace being for different tasks, so I don't want to reuse a terminal that has another context.
One issue with keeping a single shell is that the history is full of irrelevant stuff. If you run commands that take a while and print a lot of output, you want it to be as clean as possible. If I want the beginning of the command, I can scroll to the top, and I don't end up with some unrelated output.
I also take quite notes in vim everywhere, often next to long-running commands, using tmux.
I couldn’t help but think this as well. I understand wanting software that feels snappy, but this is hardly a problem. Instead of trying to convince the reader that we should care about this, it would be nice if the writer admitted this is an inconsequential personal preference.