Live data from Hacker News

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

github.com

61–70 of 168 posts

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

#61
post #52
post #43

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

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!

What do you mean you didn't notice? I saw another comment about Claude below, are you not even reviewing the output?

I just browsed the project for two minutes and it's one of the first things I noticed. std::thread is more portable (Windows, if anyone cares) and allows you to pass in a lambda, which keeps the code local and also has the compiler generate the closure for you instead of having to pass function pointers and void* captures around. I don't see any advantage to using pthread directly.

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

#62

This is cool, but I gotta say - I care much more about keypress-to-screen latency on my terminals than throughput - would love to see some numbers on that.

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.

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

#63

What's the boot time for shitty? I can't use half of the terminal emulators because theyre so slow that after hitting my key bind to open them and I start typing half of the first word is missing.

I don't know, I haven't measured it. For me, it's "instantaneous" enough that I don't have to think about it.

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

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

I see, I wasn't aware of that one. Typically I'd assign an ID, but yeah, names make things easier.

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

#65

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

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.

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

#67

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

Yes, see also gimp, thefuck and other equally depressing juvenile names. I'm aware of precedence.

It's partly frustrating because the laziness of the naming presumably doesn't actually reflect the effort that has gone into the project.

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

#68

Gutenberg's copy of Moby Dick is 1.2MB[0]. Which is to say the slowest benchmarked terminal could display a paltry ~53 Moby Dicks per second, while shitty gives you ~98 Moby Dicks. I am not sure how many Moby Dicks I require per second, but it is good to have options. [0] https://www.gutenberg.org/ebooks/2701

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?

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

#69

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

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.

The name screams for attention, so of course it's on topic. I made no appeal to authority, just maturity.

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

#70

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

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.

Post reply on HN