Am I the weird one? I usually have 3/4 terminals open at a time and rarely open new ones. Terminal startup speed is a non-issue for me.
The only thing I demand to be fast on my terminal is grep reverse search (ctrl+r) and of course typing a character. But if your terminal can't keep up with your typing speed there is something deeply wrong with it.
It can affect shell subprocess startup time as well, which, depending on your setup and the tools you use, might be worth optimising for.
I don't remember when I did it, but it looks like I must have gone through this at some point (maybe due to using GNU Make a lot? Or perhaps it was some other tool) - my zsh setup does a bunch of autocomplete setup only in the interactive case, and it seems to help a bit with startup time, at least on macOS:
% for i in {1..5}; do /usr/bin/time zsh -i -c exit; done # zsh in interactive mode
0.05 real 0.03 user 0.02 sys
0.02 real 0.01 user 0.01 sys
0.02 real 0.01 user 0.00 sys
0.02 real 0.01 user 0.00 sys
0.02 real 0.01 user 0.00 sys
% for i in {1..5}; do /usr/bin/time zsh -c exit; done # zsh in non-interactive mode
0.01 real 0.00 user 0.01 sys
0.01 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
For the interactive case, I don't really mind (within limits - the worst case, on macOS after a reboot, takes several seconds, and that's tedious). I also start new interactive terminal sessions fairly rarely.
I wasn't actually aware of the impact. I measured the zsh startup time locally (with mvn active and commented out) and it indeed makes a difference (.39s -> .08s). Not that I would have noticed that without measuring :) - yes I'm an old geezer.
Thank you for the recommendation, I might then also be able to ditch sdkman as well.
I know nobody is missing it, because it is the first bit of the blog post, but the author does have a follow-up where they note corrections based on push-back they received from a reader.
Apparently for some of the simplicity-produces-speed arguments, users have found complex/featurefull. tools that are still quick. I’m not sure how to evaluate this (I like simplicity just because it is easier to fit simple tools in my head) but we should note the counter argument (and applaud the follow-up).
"The single biggest win is what's not there: no oh-my-zsh, no prezto or plugin manager. I've honestly never understood the appeal of these frameworks."
"Most of these optimizations are about leaving stuff out. It's about being intentional and only adding things you're going to use."
I don't use X11 or a similar graphics layer, only textmode. Thus I don't use a terminal emulator
I don't use zsh. I use NetBSD sh
Smaller and faster
This is what I am comfortable with
Others may have their own preferences; to each their own
I might not understand others' preferences but that's their business, not mine
Maybe I should remove the following bit of code from my profile?
if [ "$SESSION_TYPE" != 'remote/ssh' ]; then
if [ "${TERM_PROGRAM}" != 'tmux' ]; then
( if [ $[RANDOM % 10] == "0" ]; then fortune -n 40 -s; else echo "Hi, $(whoami)!"; fi ) | cowsay | lolcat && printf '\n'
else
if [ "${TMUX_PANE}" == '%0' ]; then
fortune | cowsay -f small | lolcat && printf '\n'
fi
fi
fi
It's a whole chain of interpreters firing up (sub-shells, Perl for the cow, Ruby for the lol, I think.) :D
But what would life be without a little bit of fun?
Speaking of slow, what I absolutely cannot comprehend is why ghostty is so popular. Despite being written in Zig it is very slow and a total CPU and memory hog. Just sitting there idle it’s pulling a constant 40% of my CPU? No thanks!
WezTerm is great too and, AFAICT, is everything Ghostty wants to be. Kitty is also very good, although WezTerm edges it out for having an integrated muxer.
I can't understand Ghostty either except as some kind of trendy memetic thing, the $GME of the TTY world.
I know ghostty is designed to be super high performance but I find it both uglier and slower than Iterm2!
I started using it expecting to love it, but in reality it didn't seem to gain me anything but in fact was worse in several major ways. Also less configurable than Iterm2. :/
That happened to me too, turns out my desktop was software accelerated because I had screwed up the GPU config somehow. I asked Claude to fix it and it did.
I suspect you enabled some weird setting that you've forgotten about. ghostty isn't unimaginably fast but it's faster than iTerm 2 which is plenty. And I'm sitting here with a lengthy Claude Code session open, as well as a couple tabs for my docker container and dev servers, and its idle CPU usage is 0.0%.
$ for i in {1..5}; do /usr/bin/time zsh -i -c exit; done
0.01 real 0.00 user 0.00 sys
0.01 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
I read Ghostty runs in a single process, but whenever I tried something like that eg a client/server model in urxvt or foot, I ended up reverting, because eventually some weird state affected the daemon and had to restart it killing all my terminals, so nowdays I just run foot standalone, with sway tabbing and splits are kind of built into the wm anyways. But keep hearing about Ghostty and wondering if I am missing out on something.
Great post! There are some neat tricks around completion initing that I'll have to grab. I use fish shell and have done a bunch of optimization around async git statuses too.
On Cygwin, FWIW, it pays huge dividends to avoid making the shell fork at all costs. Don't use $(sed ...). Use ${variable%foo%bar} or whatever. Cygwin punishes you hard for unnecessary fork().
As it turns out, avoiding unnecessary fork() is good hygiene everywhere.
In my life I can spare 50ms waiting for an terminal. But I have no time to spend 10000000 ms commuting to work, cleaning poop after an animal, or waiting for partner to put their face on!
> Most of the time the GUI experience is the same or better than terminal tools
I started to take your comment seriously until that line. You're avoiding leveling up and learning how to use the CLI. Whatever reason you are avoiding it for, understand that's what is at play here.
If what a person does during the day is mainly interacting with text then they need a tool for working well with text. Possibly this is an editor window inside an IDE. Possibly this is a shell in a terminal emulator. However, dismissing GUIs out of hand and asserting superiority of CLI is wrong. Far more disciplines need a GUI to get maximum utility from their computers than can get by with a CLI. Designers, architects, actual engineers, artists, lawyers, etc.
If it is a one-off task, it doesn't matter if you use GUI or Terminal commands to do it. But more than once, terminal starts paying off IMO.
Here are some advantages.
- It is repeatable, you can do the same exact thing you did before. With ZSH history + FZF, recalling a command is a breeze.
- Auditability. The command in your shell history is there for you to revisit and servers as a permanent record of something you did (or didn't do).
- A command line doesn't make a mistake at 10th time, due to fatigue, inattention etc.
- Reusability. You may have to repeat the same command for different folders (or remote servers). A slight modification of the previous command will do it for you.
If you haven't combined terminal tools together then you haven't use the terminal the way it's intended.
If you start 1 command and get 1 output, the terminal isn't particularly powerful.
One you do start combining commands then it's a totally different thing.
If your GUI does everything you need, then a terminal isn't necessarily useful. If your GUI doesn't provide a feature though, you are most likely stuck. You might be able to learn it's own API in a specific language, e.g. Lisp for Gimp, Python for Blender, etc. If though your terminal application doesn't provide what you need you can pipe its output to another terminal application and thus get something that none of those applications individual can. Once you have done it with 2 applications you can do that with 3, 4, etc. You can label those applications and re-use that tomorrow, share with someone else, etc.
The terminal isn't about starting one application.
In a Turing machine theory, a GUI application can do all the same things a terminal application can do.
In practical design, GUI applications inevitably deprecate keyboard abstractions in favor of graphical abstractions and graphical abstractions require parsing visual representations and are less conducive to "muscle memory" whenever pointer control is relative rather than absolute (which these days is approximately always [1]).
Keyboard oriented applications feel more like a language and human brains tend to map well to language and touch typing while GUI's rely on something akin (or identical) to hand-eye coordination. Hand-eye coordination is harder than touch typing and every GUI application requires developing a unique mental model.
[1] in the ancient days of digitizing tablets with absolute coordinates, it was possible to "touch mouse." But that's not how we do things today (and it would not work well with infinite scrolling, etc.)
Depends on what you grew up on/learned I think. CLI was the only thing around when I learned so that's still what I prefer. It's one of those things where I think you use the tool that you are proficient with. No right or wrong, just different strokes for different folks.
I think, for folks who grew up in the early 2000’s at least, CLI is the way to go forward. The GUIs at the time were really quite good, it was after the really limited time of the 90’s, but before we started dumbing down GUIs for… I dunno, style I guess.
If you were raised on programs where most of the features were accessible at a button-click, without going through a bunch of hamburgers, modern GUIs won’t feel familiar, CLI will.
GUIs are almost entirely non-scriptable. Some exceptions exist, but they're few and extremely limited compared to what you can do with a CLI. (Note I said CLI. A TUI is almost always a GUI made of text, and is just as non-scriptable.)
Terminal tools are nice because keyboard shortcuts and text commands are quicker than clicking through menus and pressing buttons. For certain types of work (programming for example) this is much quicker and more comfortable than GUI interfaces.
Of course, other tasks are nicer with a GUI and/or mouse/tablet/touchscreen (art creation for example).
Am I the weird one? I usually have 3/4 terminals open at a time and rarely open new ones. Terminal startup speed is a non-issue for me.
The only thing I demand to be fast on my terminal is grep reverse search (ctrl+r) and of course typing a character. But if your terminal can't keep up with your typing speed there is something deeply wrong with it.
It can affect shell subprocess startup time as well, which, depending on your setup and the tools you use, might be worth optimising for.
I don't remember when I did it, but it looks like I must have gone through this at some point (maybe due to using GNU Make a lot? Or perhaps it was some other tool) - my zsh setup does a bunch of autocomplete setup only in the interactive case, and it seems to help a bit with startup time, at least on macOS:
For the interactive case, I don't really mind (within limits - the worst case, on macOS after a reboot, takes several seconds, and that's tedious). I also start new interactive terminal sessions fairly rarely.I'd say your workflow is pretty typical, from what I am seeing.
Developers that are very heavily invested in terminal and (over) optimize their terminal configuration are a small but very vocal minority.
I do the same, so there's a good chance you're (we're) the weird one
I'm surprised people are still using nvm, considering it's impact on shell startup time.
I can't recommend switching to mise highly enough: https://mise.en.dev/
I use aliases that lazily load nvm when I actually want to use it. This converts the shell startup penalty into a node/npm startup penalty.
I wasn't actually aware of the impact. I measured the zsh startup time locally (with mvn active and commented out) and it indeed makes a difference (.39s -> .08s). Not that I would have noticed that without measuring :) - yes I'm an old geezer.
Thank you for the recommendation, I might then also be able to ditch sdkman as well.
I know nobody is missing it, because it is the first bit of the blog post, but the author does have a follow-up where they note corrections based on push-back they received from a reader.
Apparently for some of the simplicity-produces-speed arguments, users have found complex/featurefull. tools that are still quick. I’m not sure how to evaluate this (I like simplicity just because it is easier to fit simple tools in my head) but we should note the counter argument (and applaud the follow-up).
"The single biggest win is what's not there: no oh-my-zsh, no prezto or plugin manager. I've honestly never understood the appeal of these frameworks."
"Most of these optimizations are about leaving stuff out. It's about being intentional and only adding things you're going to use."
I don't use X11 or a similar graphics layer, only textmode. Thus I don't use a terminal emulator
I don't use zsh. I use NetBSD sh
Smaller and faster
This is what I am comfortable with
Others may have their own preferences; to each their own
I might not understand others' preferences but that's their business, not mine
Life is too short to waste time on things that don't matter.
Maybe I should remove the following bit of code from my profile?
It's a whole chain of interpreters firing up (sub-shells, Perl for the cow, Ruby for the lol, I think.) :DBut what would life be without a little bit of fun?
"I tell you, we are here on Earth to fart around and don't let anybody tell you any different."
— Kurt Vonnegut
Speaking of slow, what I absolutely cannot comprehend is why ghostty is so popular. Despite being written in Zig it is very slow and a total CPU and memory hog. Just sitting there idle it’s pulling a constant 40% of my CPU? No thanks!
WezTerm is great too and, AFAICT, is everything Ghostty wants to be. Kitty is also very good, although WezTerm edges it out for having an integrated muxer.
I can't understand Ghostty either except as some kind of trendy memetic thing, the $GME of the TTY world.
My ghostty is using 0.4$ - 2.5%?
> Just sitting there idle it’s pulling a constant 40% of my CPU? No thanks!
You need to figure out what is going on because that certainly isn't normal.
Literally seeing 0.0% on Linux
I know ghostty is designed to be super high performance but I find it both uglier and slower than Iterm2!
I started using it expecting to love it, but in reality it didn't seem to gain me anything but in fact was worse in several major ways. Also less configurable than Iterm2. :/
That happened to me too, turns out my desktop was software accelerated because I had screwed up the GPU config somehow. I asked Claude to fix it and it did.
I suspect you enabled some weird setting that you've forgotten about. ghostty isn't unimaginably fast but it's faster than iTerm 2 which is plenty. And I'm sitting here with a lengthy Claude Code session open, as well as a couple tabs for my docker container and dev servers, and its idle CPU usage is 0.0%.
30ms is pretty slow
I read Ghostty runs in a single process, but whenever I tried something like that eg a client/server model in urxvt or foot, I ended up reverting, because eventually some weird state affected the daemon and had to restart it killing all my terminals, so nowdays I just run foot standalone, with sway tabbing and splits are kind of built into the wm anyways. But keep hearing about Ghostty and wondering if I am missing out on something.
Follow up / errata post written by the author today: https://mijndertstuij.nl/posts/what-i-got-wrong-about-fast-t...
Great post! There are some neat tricks around completion initing that I'll have to grab. I use fish shell and have done a bunch of optimization around async git statuses too.
On Cygwin, FWIW, it pays huge dividends to avoid making the shell fork at all costs. Don't use $(sed ...). Use ${variable%foo%bar} or whatever. Cygwin punishes you hard for unnecessary fork().
As it turns out, avoiding unnecessary fork() is good hygiene everywhere.
In my life I can spare 50ms waiting for an terminal. But I have no time to spend 10000000 ms commuting to work, cleaning poop after an animal, or waiting for partner to put their face on!
Life is too short for a terminal period
I really dont get the hype around terminal tools
Most of the time the GUI experience is the same or better than terminal tools
> Most of the time the GUI experience is the same or better than terminal tools
I started to take your comment seriously until that line. You're avoiding leveling up and learning how to use the CLI. Whatever reason you are avoiding it for, understand that's what is at play here.
If what a person does during the day is mainly interacting with text then they need a tool for working well with text. Possibly this is an editor window inside an IDE. Possibly this is a shell in a terminal emulator. However, dismissing GUIs out of hand and asserting superiority of CLI is wrong. Far more disciplines need a GUI to get maximum utility from their computers than can get by with a CLI. Designers, architects, actual engineers, artists, lawyers, etc.
If it is a one-off task, it doesn't matter if you use GUI or Terminal commands to do it. But more than once, terminal starts paying off IMO.
Here are some advantages.
If you haven't combined terminal tools together then you haven't use the terminal the way it's intended.
If you start 1 command and get 1 output, the terminal isn't particularly powerful.
One you do start combining commands then it's a totally different thing.
If your GUI does everything you need, then a terminal isn't necessarily useful. If your GUI doesn't provide a feature though, you are most likely stuck. You might be able to learn it's own API in a specific language, e.g. Lisp for Gimp, Python for Blender, etc. If though your terminal application doesn't provide what you need you can pipe its output to another terminal application and thus get something that none of those applications individual can. Once you have done it with 2 applications you can do that with 3, 4, etc. You can label those applications and re-use that tomorrow, share with someone else, etc.
The terminal isn't about starting one application.
In a Turing machine theory, a GUI application can do all the same things a terminal application can do.
In practical design, GUI applications inevitably deprecate keyboard abstractions in favor of graphical abstractions and graphical abstractions require parsing visual representations and are less conducive to "muscle memory" whenever pointer control is relative rather than absolute (which these days is approximately always [1]).
Keyboard oriented applications feel more like a language and human brains tend to map well to language and touch typing while GUI's rely on something akin (or identical) to hand-eye coordination. Hand-eye coordination is harder than touch typing and every GUI application requires developing a unique mental model.
[1] in the ancient days of digitizing tablets with absolute coordinates, it was possible to "touch mouse." But that's not how we do things today (and it would not work well with infinite scrolling, etc.)
I happily used a small Wacom graphics tablet as a mouse for a long time. Thanks for the memories, I’d nearly forgotten.
All other things being equal, GUI apps are not usually composable - the unix philosophy lets you do a lot by not solving every problem yourself.
a hype that lasts since the 70s can it be called a hype ?
Depends on what you grew up on/learned I think. CLI was the only thing around when I learned so that's still what I prefer. It's one of those things where I think you use the tool that you are proficient with. No right or wrong, just different strokes for different folks.
I think, for folks who grew up in the early 2000’s at least, CLI is the way to go forward. The GUIs at the time were really quite good, it was after the really limited time of the 90’s, but before we started dumbing down GUIs for… I dunno, style I guess.
If you were raised on programs where most of the features were accessible at a button-click, without going through a bunch of hamburgers, modern GUIs won’t feel familiar, CLI will.
"gui"? what gui?
my take is terminal is just quicker than "gui".
it's common as a junior to think in such a way
Skill issue.
Meh. I take typing commands in the terminal over clicking stuff with a mouse and learning keyboard shortcuts for every app.
echo $bait > /dev/null 2>&1
GUIs are almost entirely non-scriptable. Some exceptions exist, but they're few and extremely limited compared to what you can do with a CLI. (Note I said CLI. A TUI is almost always a GUI made of text, and is just as non-scriptable.)
Terminal tools are nice because keyboard shortcuts and text commands are quicker than clicking through menus and pressing buttons. For certain types of work (programming for example) this is much quicker and more comfortable than GUI interfaces.
Of course, other tasks are nicer with a GUI and/or mouse/tablet/touchscreen (art creation for example).