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?
Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours
131–140 of 168 posts
Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours
#132Creator 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…
Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours
#133Creator 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
#134Earlier 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.
Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours
#135Earlier 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?
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
#136Project seems too good to be squatting on that name. I imagined some joke terminal when I first saw it.
Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours
#137Earlier 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!
Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours
#138Re: Show HN: Shitty – fast terminal. Memory-unsafe and faster than yours
#139Nice 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.”
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
#140Earlier 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…
When we learn something well we model it thoroughly and notice the tiniest change