Gutenberg's copy of Moby Dick is 1.2MB[0]. Which is to say the slowest benchmarked terminal could display a paltry ~53 Moby Dicks per second, while shitty gives you ~98 Moby Dicks.
I am not sure how many Moby Dicks I require per second, but it is good to have options.
Mere 25-30 years ago I saw some very chatty Java builds run faster if the terminal window was obscured or minimized. Slow console output held back the compilers.
This is cool, but I gotta say - I care much more about keypress-to-screen latency on my terminals than throughput - would love to see some numbers on that.
It's VERY difficult to measure. But I can say that shitty has the best damage tracking model among foot/kitty/alacritty/ghostty. It's best in the sense that it's cell-exact; I only draw to the screen what has actually changed.
Furthermore, on Linux, I reuse buffers from the swapchain after the wayland compositor returns them, and I only update the areas that changed after I sent the buffer to the window system. In other words, I'm provably doing the minimum amount of work possible. Unfortunately, this isn't possible on MacOS, since the Metal documentation states that it can (and does) corrupt a buffer while displaying it.
Basically, based on code, not actual measurements, shitty is the best terminal in terms of change delivery latency.
> The executable is named st; the desktop application and icon are named shitty
That conflicts with the already existing suckless st.
Also I am suitably impressed with the perf numbers, but I also somewhat take away that I could stick with (at least) alacritty or ghostty and not be much slower.
To me, the most relevant aspect is the time it takes to open. I can't believe how slow the startup time in common linux distributions is by default, it's so annoying, by the time it opens I already forgot what I wanted to do. Alacritty has this cool feature where you only ever have to "open" a single terminal, whereas new windows can be created very efficiently with `alacritty msg create-window`, being forks of the initial window. It makes using my pc a lot more comfortable.
IME, usually you care more about latency than throughput for normal interactions, and there is a noticeable difference between the slowest ones, and the fastest ones, but I've tried a lot of terminal emulators, and any of the ones that put some effort into performance are plenty fast enough.
However, there is one case when throughput matters: when an application has a lot of output. But then the problem isn't the speed that it displays the text, it's going by too fast to read anyway, the problem is that the application can be slowed down by blocking on writing to stdout when the buffer is full. And honestly, the best approach in that case is probably not to actually render all the text, but send most of the output straight to the scrollback buffer, and only render some of the frames.
Speed itself may not be very important, but it is a very interesting challenge in itself - to prove to yourself that you can surpass the state of the art!
Going by the childish naming of the project, it doesn't inspire confidence in the professionalism of the author going forward, and neither will it help with getting it installed on corporate networks.
I'm all for vulgar wit but this isn't that (yes I'm aware of the -tty convention) & just reinforces the cliche of tech skills inversely proportional to social ones
Why did you make this comment? It's completely off topic.
Your appeals to authority do not apply when the author is clearly telling you not to use it for that. We're well past the point where this kind of software eventually ends up under corporate use policy or any policy at all.
I can't use half of the terminal emulators because theyre so slow that after hitting my key bind to open them and I start typing half of the first word is missing.
Can you explain why you think so? Seems like a very childish name to me.
Like a neighborhood kid outside on his bike yelling “shit” then pedaling away as fast as he can, to dissociate himself from the event out of fear of getting caught.
FaTTY - Fast Terminal (executable named “ft”)
RaTTY - Rapid Terminal (“rt”)
LighTTY - Lightspeed Terminal (“lt”)
Dragster (“dt”)
McQueen (“mt”)
Names are hard, but it’s trivial to come up with a name better than “shitty”.
Mitchell is a big proponent of using AI to code. He’s just not a dummy and knows his sh*t and he reviews the code diligently. Hell, he just promoted that he started a company for making tooling for AI agents. There is lots of LLM code in Ghostty it’s just not attributed.
I'm a huge proponent of AI, as long as there's a human in the loop and strong models are used. In fact, it's even reflected in our CONTRIBUTING.md that we prefer LLM-assisted code!
What do you mean you didn't notice? I saw another comment about Claude below, are you not even reviewing the output?
I just browsed the project for two minutes and it's one of the first things I noticed. std::thread is more portable (Windows, if anyone cares) and allows you to pass in a lambda, which keeps the code local and also has the compiler generate the closure for you instead of having to pass function pointers and void* captures around. I don't see any advantage to using pthread directly.
> What do you mean you didn't notice? I saw another comment about Claude below, are you not even reviewing the output?
Of course I looked at the LLM output, but people, uh, make mistakes and can miss something.
> std::thread is more portable (Windows, if anyone cares) and allows you to pass in a lambda, which keeps the code local and also has the compiler generate the closure for you instead of having to pass function pointers and void* captures around. I don't see any advantage to using pthread directly.
These are obvious things, and the objections to them are equally obvious. For example, std::thread is an additional level of abstraction over pthreads, which, in essence (not in form), gives me nothing. And I don't care about Windows, really.
One advantage to using pthread is the ability to call pthread_setname_np to name threads and thereby make debugging easier. Granted, you can call it with std::thread by using std::thread::native_handle() to get the pthread handle, but you're still using a non-std::thread API.
No, there are no such plans right now, but overall, the project's architecture allows for easy separation of different layers for developing a terminal emulator - the parser, in the form of a ragel state machine, and the vterm state machine, with distinct boundaries between them. The rendering layer is separated slightly less clearly, but it's also solvable.
The thing generates one of big DFA with actions for everything that can ever happen in the terminal. Precisely correct way to do it. Plus, Ragel is a joy to program once you get the hang of it. You can compose edge-triggered, level-triggered, and recursive operators in surprisingly elegant ways.
this is not true on my machine, at least for my usual benchmark Doom-fire-zig[1]. on said benchmark, ghostty 1.3.1 runs at about 350fps, wezterm 20260713-212414-b3255666 runs at 415fps, Terminal.app runs at 100fps, iterm2 3.6.11 runs at 80fps.
I'm not imposing my opinion, but in my experience, iterm2 is the slowest terminal emulator I know of, so I didn't even bother trying. But overall, I'll add iterm2 to the list, too.
has iTerm2 improved significantly in the last couple of years? I remember feeling the speedup when I went from iTerm2 to kitty, so that's surprising to me.
1. Don't call your project "shitty". At best it's juvenile humor. At worst, it's going to make adoption within companies difficult for literally no reason; and
2. You don't need a two letter command. I'm sorry but you're not that special. Your tool should instead denote its purpose with its name. In this case something like "sterm" or "stty" would do that perfectly without being verbose.
I thought it was quite clever, and was surprised I hadn't thought of it (given the prevalence of "tty" puns like kitty and ghostty).
But I'm a 14 year old boy living in a 45 year old body, so I can't get enough juvenile humor. A friend of mine with similar taste in humor once said, "if I ever stop finding this stuff funny, put me in the ground", and I still wholeheartedly agree with the sentiment.
(For example: whenever I need a quick scratch file to put some text in, I call it "shits", because then I can type "cat shits" and giggle inside my head. I'm also have cats, so I deal with cat shits daily.)
> You don't need a two letter command. I'm sorry but you're not that special.
This I agree with, though perhaps in a politer way.
Regardless, though... live and let live? The existence of this doesn't harm you an any way, and your judgey moralizing is a bit much.
The lifetime rendering-time savings wouldn’t even offset the five minutes required to install it and make it my default terminal.
I would need to display roughly 70 GB of benchmark-equivalent ASCII output before Shitty recovers a five-minute switching cost relative to GNOME Terminal.
This assumes I’m actively blocked by every byte being rendered.
Because I don't need to. I've never even once thought "my terminal feels slow and I want to find a different one". My terminal (xfce4-terminal) also uses a GUI toolkit that makes it visually fit in my desktop, and I like that.
Regardless, sometimes you just gotta write some code because there's an itch that needs to be scratched. Sounds like this author really wanted to see if he could write a super fast terminal, and make one faster than the incumbents. It's a cool achievement!
Any project I see on HN now, I have no idea if the developer will still be interested in it in a month. I'll stick with ghostty because of its reputation.
I am not sure how many Moby Dicks I require per second, but it is good to have options.
[0] https://www.gutenberg.org/ebooks/2701
Furthermore, on Linux, I reuse buffers from the swapchain after the wayland compositor returns them, and I only update the areas that changed after I sent the buffer to the window system. In other words, I'm provably doing the minimum amount of work possible. Unfortunately, this isn't possible on MacOS, since the Metal documentation states that it can (and does) corrupt a buffer while displaying it.
Basically, based on code, not actual measurements, shitty is the best terminal in terms of change delivery latency.
That conflicts with the already existing suckless st.
Also I am suitably impressed with the perf numbers, but I also somewhat take away that I could stick with (at least) alacritty or ghostty and not be much slower.
on the other hand what gives them the right to st but not you?
I'm glad you guys are out there - someone has to do it.
They also count my steps.
(also I had to look up aglet)
Fuck nvm btw.
It matters!
There is some number of fps where "the human eye can't tell the difference" I bet there is one for ms delays
I do wonder, however, whether people really have issues with perf on any terminal emulator in 2026
I’ve been living in Terminal.app / zsh / tmux / vim for 15 years and have never once thought “this is slower than I want.”
However, there is one case when throughput matters: when an application has a lot of output. But then the problem isn't the speed that it displays the text, it's going by too fast to read anyway, the problem is that the application can be slowed down by blocking on writing to stdout when the buffer is full. And honestly, the best approach in that case is probably not to actually render all the text, but send most of the output straight to the scrollback buffer, and only render some of the frames.
I'm all for vulgar wit but this isn't that (yes I'm aware of the -tty convention) & just reinforces the cliche of tech skills inversely proportional to social ones
- we have 5,000 tests covering all aspects of terminal behavior
- we have address sanitizer and ub sanitizer runs of these tests
- we also have regular fuzzing!
- we even monitor code coverage
This is definitely a top 0.1% GitHub project in terms of development approach.
> and neither will it help with getting it installed on corporate networks.
I'm fine with it.
The moronic naming immediately undermines that claim.
See my other comment [1] that acknowledges the effort is presumably there, which is why the childishness is frustrating.
[1] https://news.ycombinator.com/item?id=49150227
Your appeals to authority do not apply when the author is clearly telling you not to use it for that. We're well past the point where this kind of software eventually ends up under corporate use policy or any policy at all.
It's partly frustrating because the laziness of the naming presumably doesn't actually reflect the effort that has gone into the project.
I can't use half of the terminal emulators because theyre so slow that after hitting my key bind to open them and I start typing half of the first word is missing.
With this you can DuckDuckKagi for the crappy terminal (versus “CRM crm”… ah guess they wanted you to remember their company name)
https://github.com/fearlessgeekmedia/shiTTY
This one just tried to reserve the name with an empty repo a year ago... probably where the LLM got the name.
https://github.com/immz4/shitty
Like a neighborhood kid outside on his bike yelling “shit” then pedaling away as fast as he can, to dissociate himself from the event out of fear of getting caught.
FaTTY - Fast Terminal (executable named “ft”)
RaTTY - Rapid Terminal (“rt”)
LighTTY - Lightspeed Terminal (“lt”)
Dragster (“dt”)
McQueen (“mt”)
Names are hard, but it’s trivial to come up with a name better than “shitty”.
Later, Microsoft fixes the issue but fails to give Muratori credit. After backlash, they went back and gave him a footnote: https://devblogs.microsoft.com/commandline/windows-terminal-... (atlas release section)
GitHub thread in question: https://github.com/microsoft/terminal/issues/10362#issuecomm...
And this gem: https://github.com/microsoft/terminal/issues/10362#issuecomm...
https://github.com/pg83/shitty/blob/master/CONTRIBUTING.md
I just browsed the project for two minutes and it's one of the first things I noticed. std::thread is more portable (Windows, if anyone cares) and allows you to pass in a lambda, which keeps the code local and also has the compiler generate the closure for you instead of having to pass function pointers and void* captures around. I don't see any advantage to using pthread directly.
Of course I looked at the LLM output, but people, uh, make mistakes and can miss something.
> std::thread is more portable (Windows, if anyone cares) and allows you to pass in a lambda, which keeps the code local and also has the compiler generate the closure for you instead of having to pass function pointers and void* captures around. I don't see any advantage to using pthread directly.
These are obvious things, and the objections to them are equally obvious. For example, std::thread is an additional level of abstraction over pthreads, which, in essence (not in form), gives me nothing. And I don't care about Windows, really.
An interesting, and disappointing choice. Shitty, one may say.
The author of shitty encoded the whole terminal state machine in Ragel: https://github.com/pg83/shitty/blob/master/parser.rl
The thing generates one of big DFA with actions for everything that can ever happen in the terminal. Precisely correct way to do it. Plus, Ragel is a joy to program once you get the hang of it. You can compose edge-triggered, level-triggered, and recursive operators in surprisingly elegant ways.
this is not true on my machine, at least for my usual benchmark Doom-fire-zig[1]. on said benchmark, ghostty 1.3.1 runs at about 350fps, wezterm 20260713-212414-b3255666 runs at 415fps, Terminal.app runs at 100fps, iterm2 3.6.11 runs at 80fps.
[1]: https://github.com/const-void/DOOM-fire-zig
1. Don't call your project "shitty". At best it's juvenile humor. At worst, it's going to make adoption within companies difficult for literally no reason; and
2. You don't need a two letter command. I'm sorry but you're not that special. Your tool should instead denote its purpose with its name. In this case something like "sterm" or "stty" would do that perfectly without being verbose.
I thought it was quite clever, and was surprised I hadn't thought of it (given the prevalence of "tty" puns like kitty and ghostty).
But I'm a 14 year old boy living in a 45 year old body, so I can't get enough juvenile humor. A friend of mine with similar taste in humor once said, "if I ever stop finding this stuff funny, put me in the ground", and I still wholeheartedly agree with the sentiment.
(For example: whenever I need a quick scratch file to put some text in, I call it "shits", because then I can type "cat shits" and giggle inside my head. I'm also have cats, so I deal with cat shits daily.)
> You don't need a two letter command. I'm sorry but you're not that special.
This I agree with, though perhaps in a politer way.
Regardless, though... live and let live? The existence of this doesn't harm you an any way, and your judgey moralizing is a bit much.
I wouldn't want to work somewhere like that. Trying to pretend that people don't swear is just dumb. It's not even offensive.
(I have, also, thought about building my own perf-optimized terminal. It's a fun problem space!)
I would need to display roughly 70 GB of benchmark-equivalent ASCII output before Shitty recovers a five-minute switching cost relative to GNOME Terminal.
This assumes I’m actively blocked by every byte being rendered.
Regardless, sometimes you just gotta write some code because there's an itch that needs to be scratched. Sounds like this author really wanted to see if he could write a super fast terminal, and make one faster than the incumbents. It's a cool achievement!
My main complaint with ghostty is the crappy configuration.