Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours

Sometimes you want to dump a LOT of debug to the console but not have the console slow down that program. Or you accidentally cat a TB file?

Besides, most screen only show 60 images per second. That's not many Moby Dicks per second.

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.

I know, but there aren't that many two-letter abbreviations!

Optimize the aglets!

I once took around two weeks worth of evenings to get my zsh startup from 300ms down to 50ms because it felt laggy.

Fuck nvm btw.

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!

Terminal.app is amongst the best, if these old danluu benchmarks still hold https://danluu.com/term-latency/

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 don't know, I haven't measured it. For me, it's "instantaneous" enough that I don't have to think about it.

I hoped that at least someone would like it :))

Except others are already using it, with proper capitalization.

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

I will forever love reading or watching Casey dunking on people from so far above that they’re unaware of the delta.

I guess I just didn't notice. In any case, it wouldn't have been std::thread, but https://github.com/pg83/std/blob/master/std/thr/thread.h from my bike lib!

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.

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!

https://github.com/pg83/shitty/blob/master/CONTRIBUTING.md

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.

> far outperforms the likes of kitty and ghostty

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

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.

> At best it's juvenile humor.

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.

> At worst, it's going to make adoption within companies difficult for literally no reason

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.

shitty is a perfectly cromulent name.

Personally, I have never felt constrained by the performance of my terminal, so I pick based on other features.

(I have, also, thought about building my own perf-optimized terminal. It's a fun problem space!)

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!

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.

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.

For example, flicker free resizes for MacOS, something that neither Kitty, nor Alacritti, nor Ghostty can boast of.