I'm sure it is. I use it because it works well in my config, specifically I was able to configure the fonts the way I wanted it. Before that I used xterm and it was absolutely fine. Typing lag? Please. The only terminals I've ever seen performance issues are the Mac ones like iTerm 2.
Displaying gobs of output in a terminal is pretty much the most useless benchmark you can do for a terminal emulator. You never watch output that goes by faster than you can read, unless you're actively watching movies through aalib or libcaca.
I would be happy to have a "framedrop" equivalent for terminals when this happens, as it's totally useless from my perspective.
Not to say that optimizing throughput it's useless (total time adds up over the course of a day), but latency and start-up time are really what matters in a terminal emulator.
It's also hard to measure correctly, because some terminal features such as output reflow and ligature support hide major spikes in latency that you only experience occasionally but can be incredibly annoying (say hi to all url regex matchers!).
alacritty felt absolutely abysmal in the latency department when I last tried it one year ago, which is even worse than most libvte based terminals.
kitty is much better, but it's not exactly a lightweight terminal. It still starts in no less than a full second compared to mere a tenth of a second of urxvt, xterm or mlterm. urxvt always felt more consistent to me, but all three outclass pretty much all other terminals I ever tried.
For those using a tiling window manager, the built-in tabbing and multi-window support is pretty much useless too. Having true-color support is probably the only big argument I can see, which is nice to have for inband images, but again.. something rarely used in practice.
> You never watch output that goes by faster than you can read, unless you're actively watching movies through aalib or libcaca.
This is not true for me.
During development I often run programs that spew an enormous quantity of log output, and I'm watching to see if I notice a pattern in the output visually, or if it just looks normal. Either some critical or warning message in a different colour or boldface, or a shape to the messages that I'd recognise.
Although in principle I could use various output filters, grep etc., sometimes that's effort and I'd rather just run the thing and have it run quickly.
Also it's convenient to have all the output readily available if I do want to look at something that happened, as I can scroll to that place and look at pages of surrounding context in detail. If I use output filters, then I have to faff about re-running the program with different filters, or with all outputs enabled so I can step through everything around the event of interest.
Admittedly sometimes its better to output to a file and search the file, but sometimes visual output at 60Hz works quite well.
I have been known to skim manuals very fast as well. I guess in the era when man pages were everything, I got used to scrolling really fast to look for things of interest. It's interesting that a brain is able to recognise particular word-forms that flick by extremely fast, much faster than reading them. I've had people tell me they cannot do this, so I guess it's a learned skill.
It has had a lot higher throughput than Kitty for a long time, but whether it is perceived as faster is a different thing. Some people in this thread say alacritty has high latency, which might make it feel more sluggish.
> 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.
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.
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.
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.
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.
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?".
And they're naturally much slower than Alacritty and any normal Linux terminal emulator.
I fought really hard to like alacritty and tune it to be fast and ultimately it was laggy and slow as heck. The rendering pass was abysmal last I checked. If there are too many characters on the screen, fps falls off a cliff. No modern terminal should have render performance of O(n), n=characters. If I hit enter you don't need to re-rasterize all those glyphs.
st with tmux is pretty great. Just about the lowest input latency you're likely to find on Linux, AFAIK, and tmux means you need few or no patches to st to have a full-featured term. Not as low-latency as Mac terminal, but then again I don't know of a Linux terminal emulator that is.
The last time I tried st the input latency was quite a bit more than xterm. Noticeable enough to feel the difference when opening them side by side and typing normally. xterm is really as good as it gets if you want a buttery smooth typing experience.
Kitty can match xterm's latency while having better throughput. The only drawback is the forced anti-aliasing, but that's easily patched out (in freetype.c, change the last line of get_load_flags() to "return base | FT_LOAD_MONOCHROME | FT_LOAD_TARGET_MONO;")
For example, when I do a selection, the selection follows my cursor on every frame. I don't have cameras that fast, but the end to end latency on a keypress seems to be mostly from my keyboard controller and the transport.
Windows Terminal has smart copy by default now and the UX improvements of it are a huge difference. I use pantheon-terminal (i.e. the one from elementaryOS) on my linux environments, and the only reason is because it also has smart copy.
It means that on all the applications I use, Ctrl+C does _exactly_ what I expect, all the time. I don't want to have to context-switch when I go to a terminal and remember "oh yeah, I need to hold shift too" and accidentally kill the running process like a "tail -f" that I have running for logs on some server.
I understand it might be technically difficult to implement, but it means I can't switch to Alacritty without inevitable daily frustration.
As someone who spends most of his computing time under macOS, this by far is my most frequently encountered frustration under Linux. You get so used to ⌘-C and ⌘-V doing the same thing everywhere, terminal included, and when that's gone it's maddening.
Copy on select is the bane of my existence. I use selection as a reading aid, to follow where I'm looking and to help me focus. I do this in the terminal all the time. If it clobbers my clipboard, this does _not_ help me.
I don't know what a cut buffer is is, but middle click copies to primary
clipboard is the Windows style paste. I personally never really use clipboard, as using primarily is so much easier. I guess there might be using it at the same time, but I've personally never felt the need for two buffers at the same time.
When immediately pasting after copying, the primary X buffer is obviously superior as it requires fewer actions, and only one hand.
However, if I'm selecting something to keep in the buffer for a bit before pasting, I'd often screw myself by overwriting the buffer via random clicks in between.
Now I'm in the habit of using primary in the cases when I know I already have an input field or prompt ready and waiting, and the very next thing I'm going to do is paste. When there are steps left to be performed after copy but before paste, I use the clipboard.
I know it sounds overcomplicated and perhaps insane, but it's actually totally automatic at this point, and doesn't feel like it costs any mental cycles at all. For the first case, either I just readied the other program for input within the last few seconds, or at least it's visibly waiting for input on my screen. If not, then Ctrl+C it is.
It’s cognitive overhead to remember a different key for something as common as copy+paste. What if selection was holding down middle click and copying was right click? This keybind may seem easy for you but it is arbitrary and therefore hard to remember, and is non-standard. I struggle with different copy semantics across OSes and terminals all the time. It’s very frustrating.
Middle click to paste only pastes when you're clicking in a place you can type input, like a text box or the URL bar. Just places Ctrl-V will paste. Middle clicking links to open new tabs works perfectly, as do other uses of middle click, like closing browser tabs.
Selecting in X absolutely does copy to the PRIMARY clipboard. Selecting then copying (e.g. with Ctrl-C) copies to the CLIPBOARD clipboard. Middle clicking pastes from the PRIMARY clipboard, and Ctrl-V pastes from the CLIPBOARD clipboard. It is incredibly useful, not horrendous.
Well there's nothing special about terminals, it should work the same everywhere you can select text. It goes into a different clipboard from where explicit copying goes (though most modern distributions have a way to turn on synchronising of the two clipboards - maybe you have that on without realising?).
I've literally never used Ctrl+V for anything other than paste, so I'm honestly not sure how it's implemented on Windows Terminal or pantheon-terminal. But the way they have it, it always does what I expect.
I'm also very much not a vi user because, for similar reasons, context switching is a nightmare. I use nano everywhere because it works almost exactly like everything else in my system (but honestly I should probably install micro everywhere).
IOW: if you press Ctrl+D, it will cause EOF on the input stream. If you press Tab, it causes your shell to attempt to autocomplete. But if you press Ctrl+V Ctrl+D, or Ctrl+V Tab, it will insert ASCII code 0x04 or 0x09, respectively, into the input stream.
That requires using both hands and not only my left hand; if I'm scrolling around or clicking around, I'll have my right hand on my mouse. Ctrl+C/V is a one-handed hotkey and works in every other application. I'm not going to use a different hotkey for a single application. Like I've already said, context switching is a nightmare. I want the same basic hotkeys everywhere.
Hmm.. I wonder if you could get your desired behavior by rebinding Ctrl+C in Alacritty to copy, and also using the "stty" command to change the keyboard shortcut that sends the interrupt signal from Ctrl+C to something else.
The latter may be necessary because traditionally you would interrupt programs (like say a runaway cat command or some other long-running process) with Ctrl+C, so using Ctrl+C to copy would normally conflict with that.
Though I suppose that a terminal could be implemented in such a way that Ctrl+C is used for copy if some text has been selected and when no text has been selected it could pass that Ctrl+C on to the application running in the terminal. This way Ctrl+C could remain as the shortcut for sending an interrupt signal to apps in the terminal, and you wouldn't have to mess with stty.
which is what Ctrl+C normally sends, to Ctrl+Shift+C, and copy to Ctrl+C. This is after getting used to the default behavior of VTE-based terminals (like GNOME Terminal), which set Ctrl+Shift+C to send Ctrl+C if you set copy to Ctrl+C.
(Also "\x04" (Ctrl+D) to Ctrl+W, which will close things like python if it's running or the terminal if nothing is.)
I don't use a mac though, and no, very no, thanks. I want my terminal to have the SAME hotkey as every other app on my system, not something different. And I'm not going to relearn Ctrl+C/V with a different hotkey globally. That's too crazy an ask.
I went from xterm to urxvt (which I used for many years), back to xterm, then to st to alacritty and finally settled on kitty, which I love.
kitty has TrueColor support, way more features than aclacritty (which seems to take a more minimalist approach, if I remember right, and this was one of the main reasons I switched from the latter to the former), and in my experience has been both extremely fast and extremely stable.
The only thing I really don't like about it is that it seems to copy continuously to the clipboard when I click and drag over some text, so pieces of that text end up cluttering my clipboard history (for which I use parcellite on Linux). The final selection when I finish moving my mouse and let go of my left mouse button works fine, as usual, so I'm willing to live with this... though I'd still prefer it not to copy anything to my clipboard until I've finished clicking and dragging and released my left mouse button.
I migrated from urxvt to Alacritty a little less than six months ago, here are some reflections.
Despite all the talk about performance, I find urxvt to be more responsive. However, it is really not something that bothers me during day-to-day usage and I suspect that it will improve over time as urxvt is about as dead as it gets when it comes to a code base. I also ran into some font scaling issues across monitors , but I suspect urxvt gets around this mostly by being completely ignorant of things that have happened over the last 20 years.
Some awesome parts on the side of Alacritty. The community is nice and responsive, documentation good, code modern, and configuring it is straightforward (auto reload upon file edit anyone?). Try getting fallback fonts to work properly with urxvt for example, that is what ultimately drove me away urxvt as the rendering issues I encountered with CJK fonts just drove me up the walls. The worst being somehow shifting the font size depending on whether a character was present in my Japanese font or not.
Bonus, I believe the following is sufficient to emulate the look and feel of urxvt in your `.alacritty.yml`:
Especially for lower end machines like the pinebook pro it's nixe to have a smooth scrolling and rendering experience. The only terminal that renderd without much of a delay on it was st
And that I would probably have to patch  to get a great experience out of. (it's already good)
The one issue I had with st, and it was big enough that I had to switch, was that it crashes on some emoji. It's actually not even an st issue, it's upstream in ... some X font library, I think, but that just means that I can't take my st with me from computer to computer. It sucks, really, because st's great otherwise and it's not even their fault.