Live data from Hacker News

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

github.com

131–140 of 168 posts

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

#131

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?

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

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

#132

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…

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

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

#133
post #132

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…

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

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!

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

#134
post #121
post #72

Earlier quoted context omitted.

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.

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.

"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

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

#135
post #8

Earlier quoted context omitted.

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

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?

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

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

#137
post #133
post #132

Earlier quoted context omitted.

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

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!

Ghostty provides official nightly builds from the main branch [0]. You do not need to build it yourself.

[0] https://github.com/ghostty-org/ghostty/releases

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

#138
post #88

Earlier quoted context omitted.

How much of it was written by AI?

If we are talking about the process of direct code production according to a given specification, then 100%.

Lmao "professional"

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

#139
post #30

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

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.

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

#140

Earlier quoted context omitted.

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

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 yo…

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

Post reply on HN