Rendered at 14:16:00 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
3eb7988a1663 2 days ago [-]
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.
tdeck 1 days ago [-]
In about 2013 I was an intern at Microsoft and my mentor showed me that if you were running something that streamed a lot to the terminal, it would run faster if you covered it with another window (but didn't minimize it, for some reason I don't recall). I was surprised this kind of trick was still a thing.
the_onion_hater 19 hours ago [-]
I have reduced build times of Java projects on our Jenkins CI by half (like from 15min to 7min) just by disabling extra logging the application did during tests.
Logs can be real slow.
Bulat_Ziganshin 1 days ago [-]
"A lot" is quite a bit of an overstatement. I don't remember the exact numbers, but my program, which updated stats (about 100 chars + '\r') every 0.1s, was becoming noticeably faster if these stats were disabled. so, the update speed was at most 100 KB/s
genxy 2 days ago [-]
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?
actionfromafar 2 days ago [-]
Besides, most screen only show 60 images per second. That's not many Moby Dicks per second.
tosti 2 days ago [-]
I can't give a single FPS how much Moby Dicks per second a terminal emulator can handle!
mitchellh 1 days ago [-]
Creator of Ghostty here. Always a fan of new terminals. I noticed your benchmarks are against Ghostty 1.3.1, which is fair, since its the latest released, but our IO throughputs in particularly the areas you tested have improved by more than double on some machines, so if you get a chance, I would ask you rebenchmark on `main`.
I don't know if it'd be faster than your terminal or not, but it'd be significantly faster than 1.3.1. On my M4 MacBook Pro, ASCII processing improved by about 2.8x, if that holds in your benchmarks, it would be faster than shitty. But, who knows. I'd prefer you ran it yourself.
sejje 1 days ago [-]
What are your go-to checks for quality terminals, when you are scoping out something new?
pg83 1 days ago [-]
I'll definitely do it as soon as the release happens!
pg83 1 days ago [-]
I'd try the master, but I have no experience with the zig ecosystem. I'd end up compiling something wrong and getting weird results. I'd rather wait for the official binaries!
lr1970 1 days ago [-]
Ghostty provides official nightly builds from the main branch [0]. You do not need to build it yourself.
> 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.
pg83 2 days ago [-]
I know, but there aren't that many two-letter abbreviations!
zamadatix 20 hours ago [-]
Does "shitty" really need a default abbreviation, let alone a 2 letter one? It's already a quite short dictionary word which is easy to type and recognize.
em-bee 1 hours ago [-]
how about tree letters? sht?
eru 1 days ago [-]
You can branch out to different alphabets. Embrace unicode.
functionmouse 2 days ago [-]
on one hand I wanna say you shouldn't make conflicting names
on the other hand what gives them the right to st but not you?
account42 1 days ago [-]
> on the other hand what gives them the right to st but not you?
Distributions. They'll probably rename one or the other so that they can be installed in parallel.
zamadatix 20 hours ago [-]
st both gains more from the abbreviation plus put it into use first and even then I'm not sure it really needs to be 2 letter either.
voakbasda 2 days ago [-]
Let the best tool win.
jcelerier 1 days ago [-]
> Shitty is moving from the imported GPL baseline to an MIT-only codebase. It does not intend to retain the GPL as the final project license.
that's really something that cannot be done if you don't have the original right of the code. It's 100% derived work and thus has to preserve GPL license, even if you rewrite every single line.
pg83 1 days ago [-]
I'll probably stick to the perspective expressed to me by the lawyer (I actually consulted on this topic), rather than the opinion of some random "GPL zealot" on the internet.
The procedure described has been done many times, is well described, and is quite feasible, albeit quite complex.
I think I can handle it!
And, in any case, anyone who wants to can sue me in a real court, not an online one.
pg83 1 days ago [-]
The procedure is quite simple in principle: each new contributor confirms their permission to use their code under two licenses—MIT and GPL3. After a while, the entire codebase becomes dual-licensed. At that point, I leave it as is and (tentatively) copy the MIT portion to another location. Yes, the derived work will still remain under the dual license, and therefore under the GPL3 as well, but no one can stop me from copying the MIT portion, which, by coincidence, will cover the entire project. This isn't relicensing; it's rewriting it under a dual license.
potamic 1 days ago [-]
It does seem to be quite some (very boring) work. I'm curious about your reasons for taking it up. Is it more of a principles kind of a thing or do you see it could make a difference to the project in the end?
pg83 1 days ago [-]
At the very least, the ability to use the code as a library. A library under the GPL3 is unlikely to be popular.
graemep 17 hours ago [-]
I am more interested in why ?. Do you think its likely that people will want to use this code in proprietary software and you do not want the GPL to block this ? Do you feel as a matter of principle that people are free to do so regardless of whether they actually want to or not?
tdeck 1 days ago [-]
Seems like a missed opportunity to use a license more aligned with the project's naming convention.
Hmm. Sounds like it follows the letter of the law (although much of it is LLM-generated, and there’s obviously quite a legal cloud surrounding that), but it does feel a bit against the spirit to me. Overall, I am quite satisfied with the name you’ve given it.
p1necone 2 days ago [-]
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.
pg83 2 days ago [-]
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.
grg0 1 days ago [-]
> I'm provably doing the minimum amount of work possible.
That is a very bold claim to make for the amount of render code generated by the LLM. It's not obvious what the critical path even is, which is what would bound the latency. And I mean actual code, not just some informal description of what happens.
pg83 1 days ago [-]
Expert opinion versus expert opinion. I will probably stick to my point of view and suggest that you either offer a benchmark or show a specific problem in my code, without speculation on the topic of LLM.
eru 1 days ago [-]
If you say 'provably', you should offer the proof. In Lean perhaps? But in English is also ok.
rdslw 20 hours ago [-]
these days on HN, if you oppose someone, you get dead-flagged.
I vouched for your comment, as I find it perfectly 'not agreeing' answer.
grg0 13 hours ago [-]
It wasn't me flagging, by the way.
The burden of proof also falls on the person making the claim.
grg0 13 hours ago [-]
Sorry, but you simply prompted an LLM and didn't even bother reviewing the output per our other discussion about pthreads. I'm not sure you can claim to be an expert, let alone put your opinion on the same level as mine.
mrtesthah 22 hours ago [-]
If you truly want low latency input on a Mac then your Terminal app needs to be able
to run full screen to enable Game Mode: https://support.apple.com/en-euro/105118
cyanregiment 2 days ago [-]
Geeking out on terminals is like geeking out on shoelaces.
I'm glad you guys are out there - someone has to do it.
I do love the Ian Knot, and I taught myself to do it for a while. Alas I stopped wearing lace-up shoes for some years and when I went back to them the muscle-memory for the standard knot was strong, so I just stuck with it.
butterisgood 2 days ago [-]
Optimize the aglets!
cyanregiment 2 days ago [-]
I only use the finest of gold.
They also count my steps.
(also I had to look up aglet)
defrost 1 days ago [-]
There's an 80s era tip of my tongue movie with glob of dialogue abut the inventor of the aglet living the American dream becoming insanely rich from Nth of a cent per shoelace royalties.
egeuvuvy6 2 days ago [-]
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.
cyanregiment 2 days ago [-]
I remember the infamous 300ms delay on tap when smartphones first came out.
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
chowells 1 days ago [-]
Yeah, there's actually been a lot of research on that. 100ms is generally considered to be the threshold between perceiving a delay or not. But even that needs some additional context. That's the threshold for feeling like you're waiting to get a response after completing an input. But a 100ms round-trip delay on a mouse cursor would feel like you were using a broken computer. And when you're doing something where you're used to continuous feedback from your input, you can sense incredibly small changes in the response time. +/- 10ms from what you're familiar with is noticeable for almost everyone. There are people who consistently notice half of that - but remember that's in the context of difference in latency of continuous feedback. 100ms is a pretty good rule of thumb for the threshold of "why am I waiting for this?"
entrope 1 days ago [-]
100 ms might be a good threshold for a lot of purposes, but for when refresh, 30 fps is painful to use compared to 60 fps: it is extremely noticeable when moving windows, but I'm old and can tell the difference even just moving the cursor. (Others will say the same about 60 fps compared to 120 or 144 fps.)
cyanregiment 1 days ago [-]
One of the reason they gave CSS access to the GPU I guess - it would be so choppy without it
cyanregiment 1 days ago [-]
Switching from 52mm skate wheels to 54mm feels like going from a car to lifted truck - I guess the same effect.
When we learn something well we model it thoroughly and notice the tiniest change
joncp 2 days ago [-]
Nice work!
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.”
marvinborner 2 days ago [-]
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.
christophilus 1 days ago [-]
Foot is instant. Ghostty takes ages. I don’t know why there’s such a difference, but I can’t use anything slower than Foot now without getting annoyed.
boltzmann64 2 days ago [-]
this is is not new. we have had factory model (forking the initial window) in terminal emulator since 1990s.
Evidlo 2 days ago [-]
Also present in urxvt and kitty.
skydhash 2 days ago [-]
I'm using OpenBSD with xterm, and when I use something like `time xterm -e 'sh -c "echo 1; exit"'`, it says 360ms or something. Starting it with the wm keybinds is as snappy as opening a new Firefox tab. foot and st felt as fast when I was using them.
porridgeraisin 1 days ago [-]
Yep, I want really fast startup too. Of the two I use:
xfce4-terminal starts utterly instantly without single instance feature.
Kitty has the single instance feature and starts instantly with it.
pg83 2 days ago [-]
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!
thayne 2 days ago [-]
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.
bityard 1 days ago [-]
Right? I have always just used whichever terminal came with the Linux desktop I was using at the time. If anything, the terminal is already the smallest and fastest gui app I have open.
I ask this question often in the comments when a new "blazingly fast" terminal is announced and after years of doing so, have yet to read an actually practical answer that applies to modern systems.
My guess is that some people just enjoy the process of optimizing well-understiod low-stakes graphical stuff.
I would still use xterm, don't really get the craze out optimising tty emulators.
Now graphical nicely powered REPL environments is another matter.
aqula 1 days ago [-]
I keep going back to xfce-terminal after trying anything else. Ridiculously small footprint and never drew attention to itself.
wavemode 1 days ago [-]
the new Windows Terminal had horrendous performance when it first came out. in the aftermath of the drama surrounding that, was when I first started seeing a lot of terminal emulator projects bragging about their throughput.
pjmlp 1 days ago [-]
Regardless of all the twitter and Github drama, it was fast enough for me, and I don't get what is the interest running HLSL shaders, pets extensions or rainbow colours on the terminal.
mellosouls 2 days ago [-]
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
platinumrad 1 days ago [-]
> and neither will it help with getting it installed on corporate networks
This might not be something the author cares about. Compliance with corporate policies is certainly not something I've prioritized when giving away open source software for free.
wmf 1 days ago [-]
Given the memory-unsafe vice signaling, maybe this can become the official terminal of Fox News and the Department of War.
pg83 2 days ago [-]
I assure you, this is a very professionally made product:
- 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.
gertop 1 days ago [-]
> This is definitely a top 0.1% GitHub project in terms of development approach.
Shitty is almost 100% generated by AI, tests and all. Is that really what you see as the epitome of development? Enough that you self rank in top 0.3%?
naikrovek 2 days ago [-]
How much of it was written by AI?
pg83 1 days ago [-]
If we are talking about the process of direct code production according to a given specification, then 100%.
queenkjuul 1 days ago [-]
Lmao "professional"
EPWN3D 2 days ago [-]
lol fuck this guy, the name and branding are awesome dude
mellosouls 2 days ago [-]
[flagged]
pg83 2 days ago [-]
> The moronic naming immediately undermines that claim.
It's quite obvious to me that professionalism in product manufacturing correlates very weakly with naming :) Proof me wrong.
naikrovek 1 days ago [-]
Nothing else on any market called “shitty” that I’ve ever seen, and if I had, I would avoid it.
Any sales or marketing person will gladly tell you how bad an idea it is to use this name. “Shitty” is slang for “terrible quality”, for one.
potamic 1 days ago [-]
Given git is all over the corporate world, I say this is less of an issue than you make it out to be.
krautburglar 1 days ago [-]
He took zutty (GPL licensed), shitted some claude on it, then released it MIT. A license violation, but not like it matters, since it will end up in the same heap as every other bozo's vibeslop. It is aptly named.
Yes, see also gimp, thefuck and other equally depressing juvenile names. I'm aware of precedence.
It's partly frustrating because the laziness of the naming presumably doesn't actually reflect the effort that has gone into the project.
sublinear 2 days ago [-]
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.
mellosouls 2 days ago [-]
The name screams for attention, so of course it's on topic. I made no appeal to authority, just maturity.
1bpp 2 days ago [-]
They aren't asking for money or literally anything from you, it's just someone's project with a silly name.
mellosouls 2 days ago [-]
They're asking us to engage and try it, that's what ShowHN is.
rdslw 20 hours ago [-]
It is still slow.
Honestly I do not understand those last ten years craziness about 'new-native-gpu-turbo-ultra-xhigh-max-terminal' <insert current trend here>.
(my) battle tested urxvt under X11 is STILL faster then shitty (and all others):
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.
pg83 2 days ago [-]
I don't know, I haven't measured it. For me, it's "instantaneous" enough that I don't have to think about it.
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.
pg83 1 days ago [-]
I'm glad someone noticed this, but ragel is a very niche tool; few people have heard of it! I believe my parser is the first complete description of a terminal output parser in FSM form, and that alone is quite valuable.
Paul Williams made this years (if not decades) ago, and it has been widely used by terminal emulator implementers.
moderation 21 hours ago [-]
monstar [0] from rockorager is an fast Wayland that leverages libghostty. It is easy to build from source. I can't build shitty from source on OpenSUSE Tumbleweed. Tons of issues with Ragel versions and flags and linker issues. All dependencies are installed.
> Shitty is moving from the imported GPL baseline to an MIT-only codebase. It does not intend to retain the GPL as the final project license.
An interesting, and disappointing choice. Shitty, one may say.
naikrovek 1 days ago [-]
I never understood this stance. I’ve heard this for 30 years and I still don’t understand why people feel entitled enough to enjoy the benefits of someone else’s work without giving anything back.
Forcing someone to release their code for free isn’t freedom, that’s a lack of freedom. Oh, you want the code to be free. Well guess what? MIT licensed means you can have it. Oh, you want a third party’s changes to be made free. No. Expecting that is batshit insane.
If someone forks this, changes it, and doesn’t release their changes, this still exists. Nothing is lost.
When something is released under MIT, it is “released”. When GPL software is released, it “binds” anyone that works on it, adding requirements to the entity doing the work. I.e. not free.
teo_zero 1 days ago [-]
I'm confused. You begin your post with a stance that's typical of copyleft proponents, then you end it in the opposite direction.
There is a trait in human nature that pushes us to share our knowledge. But we would like this sharing to be mutual.
When I publish a piece of software for free, I would like others to read it, comment it, give me suggestions on how to make it better, and the whole community can benefit from the process.
Unfortunately, someone might instead take it, start making profit out of it, and never giving anything back to me or the community.
As a device to get the former effect and avoid the latter, a sort of "contract" was created that mimicks a copyright licence. It is called copyleft and says that you can do whatever you want with my work except profit.
Now, someone might say that stopping a third party from profiting out of something they have not made is correct, someone might say it nevertheless means removing a freedom from them.
Whose side are you on?
naikrovek 16 hours ago [-]
we all would like people to share their code with us, but forcing them to because of your license is extremely anti-freedom to me.
address this culturally, that is the only way to address this completely. legal means cannot fundamentally redirect the culture of a society and make them believe that sharing is better for everyone. if you want a society that shares what it creates, then help create THAT. forcing people to do it pushes them in the opposite direction, they want to grasp their things even tighter than before.
andyroid 6 hours ago [-]
“we all would like corporations to share their products with us, but forcing us to pay because of their proprietary license is extremely anti-freedom to me”
No one is forcing you to do anything, and least of all which software licenses to depend on. If you don’t like something, choose something else. Freedom, you know?
teo_zero 8 hours ago [-]
Absolutely. That's how coding used to work in the 70s. Then software passed from people to companies, which proved alien to the cultural values that had hold so far. At the end of the 80s Stallman designed something to address the corporate world with a language they would understand. They had copyright, he created copyleft.
Now, please reread your post replacing "people" with "corporations" and check if it still sounds reasonable.
oneshtein 1 days ago [-]
Nobody forces to release YOUR code for free, you can keep it at home, OR you can buy a commercial license for MY code.
t0mpr1c3 1 days ago [-]
Free for who
mrwaip 21 hours ago [-]
I once gave up on NeoVim because I couldn't bind the CMD key properly and switched to VS Code. Can I do that here?
d3Xt3r 1 days ago [-]
Is implementing sixel, kitty graphics protocol and the kitty keyboard protocol in future scope at all? Because without these, it's not really fair to compare Shitty with other (modern) terminals.
pg83 1 days ago [-]
There are no plans for this right now. I don't use graphics in the terminal myself, but if there's a need, why not?
chamomeal 2 days ago [-]
I will def try this out and I absolutely love the name. Just an A++ name
naikrovek 2 days ago [-]
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”.
andreyvit 1 days ago [-]
I disagree that FaTTY is better than shitty. And I concur with the original commenter; an awesome name fit for the terminal proliferation age.
kaliqt 1 days ago [-]
I am certain the name was chosen purposefully because damn is it funny.
naikrovek 16 hours ago [-]
if you think "shitty" is a funny name then there is nothing anyone can ever do to convince you otherwise. you are so far out of reach that only maturing can cure this.
if you are over 30, you are out of reach to anyone and everyone.
theturtletalks 2 days ago [-]
Any plans for a "libghostty" alternative for your terminal?
pg83 2 days ago [-]
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.
elitepleb 2 days ago [-]
excited to see a work of zutty lineage, it's a massively underrated terminal, but please clank something meaner and leaner that an agent can manage to get built in less than 128k tokens, x11 would be appreciated too
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.
pg83 2 days ago [-]
> 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.
quotemstr 2 days ago [-]
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.
grg0 2 days ago [-]
I see, I wasn't aware of that one. Typically I'd assign an ID, but yeah, names make things easier.
bearead 2 days ago [-]
I prefer Ghostty as there is no this "Claude" thing in its contributors. But I guess it's always good to have competitions.
throwatdem12311 2 days ago [-]
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.
pg83 2 days ago [-]
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!
why no iTerm2 in the benchmarks ? It far outperforms the likes of kitty and ghostty
pg83 2 days ago [-]
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.
jitl 2 days ago [-]
> 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.
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.
normie3000 2 days ago [-]
Why wouldn't you use this?
Retr0id 2 days ago [-]
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!)
scuppernong 2 days ago [-]
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.
tulio_ribeiro 2 days ago [-]
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.
kelnos 2 days ago [-]
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!
jcelerier 1 days ago [-]
> I've never even once thought "my terminal feels slow and I want to find a different one"
wild
pg83 2 days ago [-]
For example, flicker free resizes for MacOS, something that neither Kitty, nor Alacritti, nor Ghostty can boast of.
y1n0 2 days ago [-]
I'm not knocking your project, but ghostty doesn't flicker for me on resize. Is this a common problem people have?
My main complaint with ghostty is the crappy configuration.
pg83 2 days ago [-]
It's not that it's a serious problem, it's just that for me, as a perfectionist, flicker is very noticeable when resizing.
mrwaip 21 hours ago [-]
Why not Rust?
protocolture 2 days ago [-]
Project seems too good to be squatting on that name. I imagined some joke terminal when I first saw it.
eigrad 1 days ago [-]
We can run a poll asking the author to rename it `shitless` once it gets rid of the GPL.
Null-Set 1 days ago [-]
Is the memory-unsafe descriptor just saying it wasn't written in rust? Or does it specifically do some UB stuff which happens to work out so far?
pg83 1 days ago [-]
Yes, "blazingly fast", but not in Rust! In fact, I have my own development model in C++, which allows me to write at approximately the same level of safety that Rust provides (at least, I think so, and asan/ubsan agree with me) - https://github.com/pg83/std/blob/master/README.md
jmyeet 2 days ago [-]
Two mild criticisms:
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.
Rohansi 2 days ago [-]
> 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.
kelnos 2 days ago [-]
> 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.
compiler-devel 2 days ago [-]
shitty is a perfectly cromulent name.
potamic 1 days ago [-]
It indeed embiggens the spirit very well.
porridgeraisin 1 days ago [-]
stty is a very important existing command, but yeah sterm works.
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
I don't know if it'd be faster than your terminal or not, but it'd be significantly faster than 1.3.1. On my M4 MacBook Pro, ASCII processing improved by about 2.8x, if that holds in your benchmarks, it would be faster than shitty. But, who knows. I'd prefer you ran it yourself.
[0] https://github.com/ghostty-org/ghostty/releases
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?
Distributions. They'll probably rename one or the other so that they can be installed in parallel.
that's really something that cannot be done if you don't have the original right of the code. It's 100% derived work and thus has to preserve GPL license, even if you rewrite every single line.
The procedure described has been done many times, is well described, and is quite feasible, albeit quite complex.
I think I can handle it!
And, in any case, anyone who wants to can sue me in a real court, not an online one.
https://www.wtfpl.net/
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 is a very bold claim to make for the amount of render code generated by the LLM. It's not obvious what the critical path even is, which is what would bound the latency. And I mean actual code, not just some informal description of what happens.
I vouched for your comment, as I find it perfectly 'not agreeing' answer.
The burden of proof also falls on the person making the claim.
I'm glad you guys are out there - someone has to do it.
Good for you Ian, happy guy.
I gotta say though: https://www.fieggen.com/shoelace/knots.htm
Most of these look like dogshit.
Feel like I would be tripping over my own feet lookin like a shipwreck.
This one is bullshit, he's padding content: https://www.fieggen.com/shoelace/startknot.htm That's not a knot. Not a knot.
That's the beginning of tying your shoes.
Come on Professor!
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
When we learn something well we model it thoroughly and notice the tiniest change
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.”
xfce4-terminal starts utterly instantly without single instance feature.
Kitty has the single instance feature and starts instantly with it.
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 ask this question often in the comments when a new "blazingly fast" terminal is announced and after years of doing so, have yet to read an actually practical answer that applies to modern systems.
My guess is that some people just enjoy the process of optimizing well-understiod low-stakes graphical stuff.
Now graphical nicely powered REPL environments is another matter.
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
This might not be something the author cares about. Compliance with corporate policies is certainly not something I've prioritized when giving away open source software for free.
- 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.
Shitty is almost 100% generated by AI, tests and all. Is that really what you see as the epitome of development? Enough that you self rank in top 0.3%?
It's quite obvious to me that professionalism in product manufacturing correlates very weakly with naming :) Proof me wrong.
Any sales or marketing person will gladly tell you how bad an idea it is to use this name. “Shitty” is slang for “terrible quality”, for one.
It's partly frustrating because the laziness of the naming presumably doesn't actually reflect the effort that has gone into the project.
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.
Honestly I do not understand those last ten years craziness about 'new-native-gpu-turbo-ultra-xhigh-max-terminal' <insert current trend here>.
(my) battle tested urxvt under X11 is STILL faster then shitty (and all others):
## ascii (95 MiB cat, best wall of 3)
| terminal | wall | user | sys | throughput | |---|---|---|---|---| | urxvt | 0.78s | -s | -s | ~122 MiB/s |
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
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.
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...
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.
https://www.vt100.net/emu/dec_ansi_parser
Paul Williams made this years (if not decades) ago, and it has been widely used by terminal emulator implementers.
0. https://github.com/rockorager/monstar
An interesting, and disappointing choice. Shitty, one may say.
Forcing someone to release their code for free isn’t freedom, that’s a lack of freedom. Oh, you want the code to be free. Well guess what? MIT licensed means you can have it. Oh, you want a third party’s changes to be made free. No. Expecting that is batshit insane.
If someone forks this, changes it, and doesn’t release their changes, this still exists. Nothing is lost.
When something is released under MIT, it is “released”. When GPL software is released, it “binds” anyone that works on it, adding requirements to the entity doing the work. I.e. not free.
There is a trait in human nature that pushes us to share our knowledge. But we would like this sharing to be mutual.
When I publish a piece of software for free, I would like others to read it, comment it, give me suggestions on how to make it better, and the whole community can benefit from the process.
Unfortunately, someone might instead take it, start making profit out of it, and never giving anything back to me or the community.
As a device to get the former effect and avoid the latter, a sort of "contract" was created that mimicks a copyright licence. It is called copyleft and says that you can do whatever you want with my work except profit.
Now, someone might say that stopping a third party from profiting out of something they have not made is correct, someone might say it nevertheless means removing a freedom from them.
Whose side are you on?
address this culturally, that is the only way to address this completely. legal means cannot fundamentally redirect the culture of a society and make them believe that sharing is better for everyone. if you want a society that shares what it creates, then help create THAT. forcing people to do it pushes them in the opposite direction, they want to grasp their things even tighter than before.
No one is forcing you to do anything, and least of all which software licenses to depend on. If you don’t like something, choose something else. Freedom, you know?
Now, please reread your post replacing "people" with "corporations" and check if it still sounds reasonable.
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”.
if you are over 30, you are out of reach to anyone and everyone.
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.
https://github.com/pg83/shitty/blob/master/CONTRIBUTING.md
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 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!
wild
My main complaint with ghostty is the crappy configuration.
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 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 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.