A blink takes about 100 to 400 milliseconds. Someone on X announced that any terminal which takes more than 100ms to start is, for him, “genuinely unusable” — meaning his tolerance for a tool is shorter than a single blink. He tried Ghostty, the terminal everyone is raving about lately, and it took roughly a second to open. Ten times too slow. Verdict: unusable, plus a parting shot — how is anyone supposed to use this thing?

Most authors would leave a face-slap like that on read. But Ghostty’s author, Mitchell Hashimoto, walked right into that guy’s thread and replied. No apology, no hurt feelings, no promise to “make it faster next version.” He did something sharper: he said that second is on purpose, and then, in two short replies, pinned this guy — and a whole crowd of engineers — to the same mistake.

The mistake is this: the second he worked so hard to hate is exactly the money that buys him the next eight comfortable hours.

Mogu chimes in:

Here’s the hook, worth taping to your monitor: the thing you’re frantically optimizing is very likely a button you press once a day — and the slowness you resent in that one press may be stealing the smoothness you actually use all day long. What makes Mitchell sharp isn’t defending his product; it’s taking “my terminal boots slowly,” a complete triviality, and turning it into a lesson on what you’re actually measuring.

Slow, because it did your homework first

Mitchell’s explanation is one sentence, but it’s dense:

Ghostty is optimized for long running human operation so the startup includes a bunch of preallocation and registration (dbus) for that idea.

There’s a counterintuitive point worth pausing on: a program that does more work at startup ends up feeling more like it isn’t there.

Preallocation means grabbing all the memory and buffers it will need up front, at launch. The cost is a slower boot; the payoff is that later — typing, scrolling, pasting a giant wall of log — it never has to stop and beg the system for memory. Latency stays flat, no stutter here, no hitch there. D-Bus registration follows the same logic: it registers with the Linux desktop’s message bus once, wiring up notifications, single-instance, and desktop integration in one go. That registration fee is collected once, at boot.

So that “slow second” isn’t laziness — it’s deliberate accounting: concentrate the cost into the one moment you only feel once a day (the launch), and trade it for eight hours where you barely notice the tool exists. What that guy wants — “instant launch” — buys a different terminal: one that opens fast and then stutters at you right when you’re busiest.

Mogu going off-topic:

There’s no free lunch — in performance engineering that’s a law of physics. You want a buttery runtime? Someone has to pay the bill somewhere first; the only difference is whether you can see that bill. Ghostty puts the bill at the door, openly priced at one second; plenty of “instant” tools split the same cost into installments, hidden inside the latency of every keystroke — fast to open, dull to use. People who complain about slow startup often just haven’t noticed they’re paying interest somewhere else — and the interest costs more than the principal.

And the off switch was there all along

The most ironic twist: that crash-inducing “one second” always had a switch. Mitchell points straight to it:

If you’re on Linux and want instant launch then read our systemd integration page. That’ll do same process single instance launch and it’s faster than pretty much anything.

The mechanism is simple: instead of restarting a whole process for every window — re-running all that preallocation and D-Bus registration — you keep one process resident, and “opening a new window” just pokes the already-running process to spawn one. The first launch still pays full price; every window after that is nearly instant.

In other words, the whole “unusable” accusation boils down to treating a default as the only option. Ghostty bet its default on “best for the person who uses it all day,” not “best for a benchmark screenshot” — but it never locked the other road. What you want is right there; you just didn’t read on.

Mogu roast time:

Single-instance is itself a tradeoff, one Mitchell didn’t unpack in this thread (so this part is me adding to him, not his words): all windows share one process — cheaper, faster to open — but the blast radius grows too. That one process dies, and all your windows go down with it. The one-process-per-window design is the opposite: slower, heavier, but one window crashing won’t drag the rest down. Neither is “correct”; it depends on whether you fear slowness or fear dying together. Even something as small as “how do you open a window” has a tradeoff buried underneath — and that’s exactly what Mitchell wants you to see.

”But there are tradeoffs” — why that line cuts

If the first reply was a design note, Mitchell’s second reply turns the knife. He says it flat out, so no one can quote him out of context:

But just to be clear, fast cold start startup time is not something we optimize for at the expense of other things. We don’t claim it’s fast there and never claimed it’s a goal of the project. Of course, if we can get performance without tradeoffs we’ll take it. But there are tradeoffs.

It looks like he’s saying “I can’t make it fast.” He isn’t — he’s saying he won’t trade other things away to get that speed. A capability problem and a tradeoff problem are two completely different things, and that guy pinned the former on someone who merely made the latter choice.

Step back further: surely that at least means Ghostty loses on cold start? Also no — attacking a project on a metric it never promised is punching air. Ghostty isn’t selling “fastest cold start,” so faulting its cold start is like yelling at a cargo truck for not being a sports car.

So is Mitchell against “speed” itself? The exact opposite — if he can get performance without paying a cost, he’ll take it. He’s against exactly one thing: pretending speed comes for free.

And the pit that guy fell into is the most common one in engineering — judging a tool built for “long running use” by a metric you trigger exactly once a day. Cold start time makes a great benchmark: pretty numbers, easy to measure, especially satisfying to screenshot. The trouble is it barely reflects your real experience. Nobody reopens a terminal every second; the norm is open one in the morning and run it all day. Spread that one second across eight hours and it doesn’t even register as rounding error.

Mogu OS:

This disease is practically the national pastime of the AI-tooling world, and it’s worse there. Everyone fixates on “how fast the first token comes out,” “how many seconds the model takes to load,” “how long the agent cold-starts” — numbers that screenshot well — but working with an agent means running a whole task. What actually decides life or death is whether it’s still stable at step 40, whether it starts hallucinating once the context fills up, whether a long task drops halfway. Optimizing a button you press once a day into oblivion while ignoring the thing you stared at for eight hours isn’t engineering discipline; it’s optimizing the wrong dimension. It’s comparing the paint job on a facade you don’t even live in, while the house you sleep in every night leaks — the benchmark number is for other people to see; those eight rough hours are the ones you have to live through.

So, how many times a day do you press it?

Back to that tolerance shorter than a blink.

On the surface this thread argues about terminal startup speed; underneath, Mitchell is asking the question every technical person eventually has to face: is the metric you’re optimizing actually important, or just easy to measure? The two look alike, but the cost of betting wrong is sinking all your effort into a place you pass through once a day.

Ghostty’s answer is blunt — it bets you’ll use it for a long time, so it spends its resources on the stretch where you linger, not the instant you pass through. You’re free to disagree with that bet (if you really do open and close constantly, the single-instance switch is right there), but it’s hard to call it “wrong.” What’s wrong is taking a ruler that measures cold start and using it on something never built for cold start, then declaring it a failure.

As for why “but there are tradeoffs” deserves to be framed on a wall: it refuses the sweetest lie — that performance can be free, that speed costs nothing. Mature engineering was never about eliminating tradeoffs; it’s about knowing exactly what you’re trading for what, then saying the choice out loud and owning it.

So next time you’re about to melt down over a benchmark number, answer the question Mitchell never said out loud but the whole thread was asking — that thing you keep staring at: how many times a day do you actually press it? (⁠｡⁠•⁠̀⁠ᴗ⁠-⁠)⁠✧

Further reading