Hacker News Reader

Comment by DrBazza | Hacker News Reader

I've used alacritty, and then just went back to using konsole. I didn't really get any feeling it was 'faster'.

Why does every rust project claim to be 'blazing fast'?

> Why does every rust project claim to be 'blazing fast'?

It doesn't seem particularly mysterious to me. Performance is often a feature that an author of some software has put a lot of time and work into, is proud of and can be a differentiating factor between it and other alternatives.

I don't know if "every" Rust project makes the same claim, but one of Rust's wheelhouses is in performance critical code, so it's not particularly surprising---at least to me---when people who enjoy writing performance critical code produce such things in Rust.

Now, I don't really know the first thing about benchmarking terminal emulators and performance was never really a concern for me when I used to use Konsole. I personally switched to Alacritty because it worked better in cases that I cared about: https://twitter.com/burntsushi5/status/967896697421615105

I've used some of your code (ripgrep?), and it is fast.

I didn't claim it's mysterious, just that every Rust project I see says 'blazingly fast' somewhere on its web page. Other native languages that are fast (C++, D, etc.) don't seem to feel the need to advertise their speed.

Golang projects seems to use the same claims too -- even if they're way behind C/C++ etc equivalent projects in performance.

In many cases it's just newby devs surprised by how faster (almost for free) they get than some scripting language they used before...

Rust straddles the line between the statically typed, compiled languages and newer more featureful ones that tend to be slower due to things like GC, dynamic typing, running on a VM. For those migrating from C++ they want to advertise it as a better language without performance compromise. For those coming from the other side the primary benefit may actually be the increased performance.

In the case of Alacrity the author did go to great lengths to optimize and benchmark the text rendering. It really is fast. That's not usually an issue in a terminal, but I have had rare moments when an excessive amount of text output caused me to wait for the terminal to catch up.

>the author did go to great lengths to optimize and benchmark the text rendering

I think they went to great lengths to optimise the text output buffering but not necessarily the text rendering. Their benchmarks involving catting large files don't require the rendering to be fast.

On Windows, Alacritty is actually extremely fast compared to anything else I've tried, including windows terminal, powershell and CMD, from startup time to keystroke delay. Unfortunately many of the third party terminals for windows that have normal terminal features are Electron apps and are so slow they're unusable (looking at you Terminus). On Linux I don't see a difference between Alacritty and konsole, terminator, rxvt, etc.

I didn’t realize Alacrity supported Windows. That’s great to know! Finding useable console on Windows was always a pain for me.

I've noticed the same thing, and on macOS, too.

Non-free operating systems have a really poor selection of terminal emulator software, both in terms of feature sets and in terms of performance. They're usually inflexible (Microsoft's old terminal emulator, like for PowerShell and CMD by default) or extensible but based on web technologies, and in both cases, they're slow.

iTerm2 can be made to perform passably, but only by throwing GPU acceleration at the problem, which doesn't seem to be necessary for popular and banal terminal emulator choices on Linux, like Gnome Terminal and Konsole.

The performance differences become much more visible if you're a tmux user, in many cases.

> I've used alacritty, and then just went back to using konsole. I didn't really get any feeling it was 'faster'.

Anecdata: I switched from Konsole to Alacritty about a month ago, after playing around with it for a bit, going back to Konsole, and realizing how everything in Konsole now felt surprisingly sluggish. Not in the sense that I can actually tell how much slower a certain operation is, but it feels like Konsole is working with one arm tied behind its back.

Throughput vs latency. Latency is not the absolute best (still fine though) but it can keep up when you accidentally spam your terminal with a huge logfile.

I've done simple test with this command `time fd` on ~/.

Actually alacritty was faster than kitty and konsole.

2.8x 3.0x 3.6x

And they never tell you how many blazing-fasts there are to a regular fast.

There was a blog post with some benchmarks in 2018: https://jwilm.io/blog/alacritty-lands-scrollback/ But not sure if this is still applicable.

Some other benchmarks show it as slower, particularly with respect to latency (where I agree with the people who say this is the most important metric: "throughout" has only really ever mattered to me in extreme cases, such as with mintty, which slowly renders all intermediate states); this was brought up in a Hacker News discussion of this link you just posted, and has been discussed elsewhere, such as reddit.

https://news.ycombinator.com/item?id=18006751

https://www.reddit.com/r/rust/comments/8ffddi/alacrittys_not...

The whole "Alacritty is the fastest terminal emulator in existence" just frankly just comes off as dishonest marketing BS given that people even elsewhere here on this thread keep reporting jank issues :/, and it kind of gives the Rust community in general a "bad look" since a lot of projects also claim they are "blazing fast" and it makes you wonder "are you really checking that? are you measuring the right thing?".

My comment about rust and 'blazingly fast' is a bit offhand, but my point is just because it's native, doesn't mean it's fast. People can, and do, write crappy slow code in any language.

C++ projects (or D, Zig, Nim, Swift, or your native language of choice) don't sell themselves as 'blazingly fast' every single time but all, in principle, produce fast native code.

If the competition was written in say Ruby or TCL they might have had a point in touting the language used as a performance enhancer.

But all terminals people care about are already C/C++ -- Rust doesn't have that much (if any) speed advantage there...

It's all down to algorithms used... It's not like terminal code will take benefit from e.g. memory aliasing related optimizations...

There are a ton of terminal emulators out there based on HTML5, CSS, and Javascript, little Chromium apps and similar. And on some platforms they're often the only ones offering certain features or extensibility.

And they're naturally much slower than Alacritty and any normal Linux terminal emulator.

>There are a ton of terminal emulators out there based on HTML5, CSS, and Javascript, little Chromium apps and similar.

Just not those people really care about -- except maybe the one in VSCode.

And of course, they are not those that Alacritty competes with and alludes to being faster to.

"Faster than HTML5-based terminals!!!" would be a pretty low bar, if not embarrasing as a motto...

Reply on news.ycombinator.com