Live data from Hacker News

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

github.com

51–60 of 168 posts

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

#53
Excellent use of Ragel to generate fast state machines. Everyone should check it out: https://www.colm.net/open-source/ragel/

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.

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

#54
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

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

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

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

Also present in urxvt and kitty.

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

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

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.

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

#57

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

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

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

#59
post #43

Why are you using pthread instead of std::thread?

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.

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

#60

Geeking out on terminals is like geeking out on shoelaces. I'm glad you guys are out there - someone has to do it.

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.

Post reply on HN