I know it's just a terminal and very mundane to be excited by, but the performance shows if you're a heavy command line user. tail logs look smoother, typing never lags, really well done.
Was a lot faster there.
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.
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.
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 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.
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.
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.
In many cases it's just newby devs surprised by how faster (almost for free) they get than some scripting language they used before...
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.
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.
Actually alacritty was faster than kitty and konsole.
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?".
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.
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...
And they're naturally much slower than Alacritty and any normal Linux terminal emulator.
It's pretty much on par with Visual Studio Code.
There's also this:
They still claim it's "the fastest terminal emulator in existence."
Hmm. Am I tripping? Would you mind installing Konsole on macOS via Homebrew and telling me whether latency still seems that way to you?
The former feels snappier (and is probably GPU-accelerated as well anyway), looks better and comes out of the box. The later has way more features.
I just tried Alacritty 0.5, and it has some weird artifacts when text color changes, which happens a lot when the shell highlights commands, or when editing text.
Anyway, it's great to have options.
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.
PRIMARY: Copy by select, paste with middle click or shift-insert.
CLIPBOARD: Copy with explicit copy action, paste with explicit paste action (mostly ctrl-c/ctrl-v, except in terminals/vim)
I'm not sure if this is carried over into Wayland. I've seen some Mac terminals offer copy on select and there it does clobber the clipboard, unlike on Linux.
Vim exposes these as the * (PRIMARY) and " (CLIPBOARD) buffers
- Tilix supports it, just set Ctrl-C/Ctrl-V as copy/paste and it'll intelligently handle it.
- Kitty does as well, but needs to be configured manually to do so.
- Terminator has a smart copy option enabled by default.
- No support with default GNOME terminal.
Heavy/Traditional Xorg users have enjoyed + gotten used to the multiple clipboards available. 
Users are migrating to Linux from Windows/MacOS and are not used to it; and asking for changes. (Remember Chrome + FF changing the selection behavior on the address bar to match windows?)  
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.
I find two buffers convenient when grabbing both url and title for a hyperlink.
But if the focus is in a text field (where it actually makes sense to paste) in a web browser, then middle clicking does in fact paste, just like it does in every other sane X application.
> with Xorg
The behaviour you describe only happens under windows.
But how does it know what action to take on Ctrl+V?
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.
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.)
There are packages in the Pop OS PPA I am planning on using. (They haven't added 0.5 yet.). I won't add the PPA, just download and install the deb.
It looks like this release has been published to crates.io, which was a blocker to getting alacritty packaged in Debian, so hopefully soon it will be added and synced to Ubuntu.
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.
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)
Edit: Both terminals kitty and alacritty seem to work now out of the box on my setup.No environment variablres required :)
Don't know for sure, but it does feel faster and more polished than kitty.