Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

After a quick test this looks incredibly good and fast. I'll use it as a terminal for the next weeks to see how it goes, but I have good feelings. Thank you so much for writing it.

EDIT: WOOOW, for me this is going to be a game changer. I was just working at Redis stuff outputting a ton of debugging info and results, and normally the terminal was the bottleneck, and here instead it printed half million of results in the blink of an eye. And then I could go back in the history without any performance degradation. I love this: for development of systems it makes a big difference.



Really need scrollback search though. Was a bit surprised it was launched without that.



why don't you just pipe it into a file and then less it? if your redis stuff prints so much stuff you might want to reevaluate the respective program logic.


Sure, I redirect when there is to redirect, but sometimes during debugging you want to spam yourself to see what is happening during some stress testing when some code path is full of printfs. Also sometimes I'm just on the redis-cli and to test the system at scale I directly ask (like yesterday) for half million of similar vectors. It is very convenient I can type this on the CLI and see the result immediately, instead of flooding myself for seconds or minutes.


so, it's convenience. fair enough. i'm just trying to make sense of why it is so popular on hn. i often see stuff rated to mount everest here and i just don't get it. and then i'm wondering is it me? or is it them? am i one of those weak engineers who just don't know what's going on? that's all.


Since you asked, your point above effectively says "why don't you just work around your terminal emulator being slow by making more work for yourself?" That's not a compelling argument.


not really - the use case mentioned where you suffer from a slow terminal is a code smell as far as i am concerned


No it isn’t.


“why would you want your work to be easier” — yea, it’s you


Please don't be snarky or cross into personal attack. We're trying for the opposite here.

https://news.ycombinator.com/newsguidelines.html


Telling to creator of Redis that they might want to reevaluate their respective program logic (Redis) is pretty funny, only on HN :)


Haha, the question makes sense per se but there are definitely times where you want to see the output in real time. I'm a big fan of printf-debugging :D


It feels good to hear support for printf-debugging coming from such esteemed corner. I have been doing that for a significant majority of my career instead of dropping into debugger. The side effect is you become pretty good at crafting meaningful logs.


[dead]


These benchmarks are all flawed.

You can't measure input latency properly without a camera (or pixel access to the screen but then have to be careful it's not impacting your benchmark). The latency benchmark is just testing VT IO throughput for a specific zsh prompt. Not at all related to input latency.

The plaintext IO benchmark is suspiciously slow for both Alacritty and Ghostty relative to Kitty. I ran the same on my machine and got within 15% between all three. They're all fast but something looks wrong here. I also have issue with the contents, which aren't representative in my opinion of human output (that's why I like to use books as my plaintext IO benchmark). This changes things.

The memory usage doesn't explain the setup at all, nor exactly how memory is read (I'm not sure what the `mem` column is reading in btop). Memory usage on macOS is tricky to benchmark because the OS tries very hard to _not free memory_. As a macOS kernel guy told me once: "freed memory is wasted memory" [so long as you're not using all memory]. There are other metrics you can get out of the kernel to get accurate _allocated and used memory_. Activity Monitor exposes these well. (EDIT: Just realized the tests were on Linux, which should be better, so this might be okay but test setup still matters here)

I'm not saying any are directionally wrong, and I'm also not trying to claim Ghostty is the fastest (I don't, I claim it's just "fast", not the fastest). But this is not good benchmarking.


Author here, I will try to implement your suggestions. I made the benchmarks out of curiosity and excitement for ghostty release and never intended to pick on any specific terminal. Considering it's first initial release (1.0) ghostty performance is very good and I'm sure it will improve even more given a few months. I know ghostty doesn't just focus on performance, it excels in other area like utilizing native components and having a growing community that is very supportive.


...And you can also cc this your comment to the issues section of the provided repo, so that the author could answer these points and possibly improve their benchmarking process :).

---

> I claim it's just "fast"

Me, I have three terminal emulators installed on my main machine, alacritty, kitty and xterm. Definitely haven't noticed anything "game changing" (as mentioned in the comment above) from ghostty in this regard.


You could also provide your own terminal benchmarks; that would help Mitchell debug if needed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: