What are your go-to checks for quality terminals, when you are scoping out something new?

I'll definitely do it as soon as the release happens!

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.

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.

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.

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

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.

You’ll be delighted to learn Professor Shoelace exists: https://www.fieggen.com/shoelace/

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.

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.

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.

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!

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.

I would still use xterm, don't really get the craze out optimising tty emulators.

Now graphical nicely powered REPL environments is another matter.

I keep going back to xfce-terminal after trying anything else. Ridiculously small footprint and never drew attention to itself.

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

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.

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

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

There was also the video where he did write the doctoral research project in a weekend.

> 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.

Given the memory-unsafe vice signaling, maybe this can become the official terminal of Fox News and the Department of War.

Given git is all over the corporate world, I say this is less of an issue than you make it out to be.

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.

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.

https://scholar.google.com/scholar?hl=en&as_sdt=0%2C10&q=%22...

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.

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?

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

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

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.

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.

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”.

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.

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.

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

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.

> 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

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.

We can run a poll asking the author to rename it `shitless` once it gets rid of the GPL.

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!)

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.

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!

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

> 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.

> 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.

stty is a very important existing command, but yeah sterm works.

shitty is a perfectly cromulent name.