What is Reddit's opinion of
Alacritty?
From 3.5 billion Reddit comments
80 reviews of this app found across Reddit:
I'm one of the Alacritty maintainers and Version 0.3.0 has just been released, since this is a slightly bigger release I've decided to write up what has changed for people who haven't been following the project.
If you have any questions, please let me know. I'm happy to answer all of them.
The source of the project can be found here: https://github.com/jwilm/alacritty
> especially for getting smoother output.
Well, you are asking quite a lot of your terminal emulator here... I'm actually impressed by the performance you've been able to squeeze out thus far.
One thing you might want to try is to use a GPU accelerated terminal emulator like alacritty.
PLEASE. Especially after the (small amount of) drama that happened with <code>alacritty</code>'s claim to be the fastest terminal emulator, it'd be great if one could lead their marketing with at least cursory benchmarks. We're not ALWAYS going to avoid things like users on HN looking for ways to criticize whatever gets noticed, but we can at least do a defensible amount of homework before making claims of superiority!
I was under the impression that Alacritty's claims were about throughput, not latency. That being said, there isn't any hard benchmarks to back this up (https://github.com/jwilm/alacritty/issues/289), although the posted benchmarks that Alacritty does well in do seem to be throughput focused.
> Portability: Alacritty should support major operating systems including Linux, macOS, and Windows.
but
> Windows is not yet part of the list, but the initial offering demonstrates making a cross-platform terminal emulator is possible.
So, not yet, but at some point. https://github.com/jwilm/alacritty/issues/28 is the tracking issue.
Just going off of this test, it looks like Alacritty supports truecolor/millions of colors. Which is awesome. Can we add it to https://gist.github.com/XVilka/8346728?
I haven‘t had any luck getting a smooth performance (especially scrolling) with this combination. Using Neovim made it feel a bit better, but what really made a difference was switching to Alacritty.
I'm a minimalist: http://imgur.com/XExWUxf
I have the dock and status bar hidden and use the keyboard. Instead of the dock for opening, quitting, and force-quitting apps, I use ⌘ SPACE, ⌘Q, and ⌘⌥⎋ — also for emptying the trash there's ⌘⇧⌫. I only use the status bar when I check my battery or connect to bluetooth devices. The background image is one of the solid color defaults.
I primarily only use two apps, Safari and alacritty (a terminal emulator). I spend most of my time on the terminal, this is what my terminal setup looks like (inside tmux, for those who are more familiar): http://imgur.com/5F85bwU
edit: non-album imgur links
I'm one of the Alacritty maintainers and Version 0.3.0 has just been released, since this is a slightly bigger release I've decided to write up what has changed for people who haven't been following the project.
If you have any questions, please let me know. I'm happy to answer all of them.
The source of the project can be found here: https://github.com/jwilm/alacritty
I don't say rendering font data on the GPU is wrong. But that's not what this is about. The windows ui is gpu accelerated anyways. The font renderer probably as well. It doesn't make much sense to implement your own font rendering for the terminal of there's already one that does a perfectly fine job for the rest of the system.
Oh and the super hyper mega awesome fast Alacritty is much slower than you think: https://github.com/jwilm/alacritty/issues/179
They fixed this bug and only got to speeds comparable to or still slightly slower than non-gpu accelerated terminals.
Even though many terminal emulators (TE) aren't made for animating the entire terminal character buffer with something like 20 frames per second or more, there is Alacritty, a GPU-assisted TE that prides itself on being the fastest one around. There is also Kitty, it uses GPU as well, and there may be others that do fit the description from the above repository description:
> Terminals seems to be not optimized to render large amount of character changes.
Because it's too hard to type
rustup run nightly cargo install --git https://github.com/jwilm/alacritty
Once the first stable release is made it will just be
cargo install alacritty
But that's too hard...
I've typically got about 30 tabs across 10 instances of iTerm2 all pushing 24-bit color codes to a 4k display using anti-aliased 13pt font. Performance was becoming a problem, and the worst part is that it was inconsistent. Sometimes keystrokes would just bog down for no reason. Neovim felt "mushy". I could literally perceive the re-paint algorithms whenever I resized a window, for example.
> I've never noticed lag caused by actually rendering the terminal.
I suggest installing Alacritty for yourself to see what you may be missing. I've spent a day and a half with it now and I don't think I'll be able to go back to iTerm2. Currently forging the arcane config to match my previous workflow.
It's weird for me because I remember printing to a text mode CRT on my old 386 and feeling a much more direct connection with the machine. Terminal emulators now are wrapped in so many layers of abstraction that something gets lost.
I'm using something very similar to this method but much more simple and hackish. I just disabled the window decorations and appended the NSTitledWindowMask mask to get the title bar buttons, without making it a new window initialization option at winit.
I'm still not 100% satisfied at the final result since I need to add the padding to make it look like it's actually a black title bar, which leaves me with that blank space at the bottom.
You should give alacritty a try. It's also gpu-based and very similar to kitty (mentioned in this thread) in terms of features, but it's written in Rust.
I'm a big fan of rust-based tooling since the code winds up being just as fast as C, but without the memory safety issues that cause bugs and system vulnerabilities.
I switched from iTerm2 to Terminal (big difference in NeoVim speed) some time ago and then started using tmux instead of tabs. And then I found out Alacritty has matured quite a bit and switched to it (which was a breeze thanks to tmux) https://github.com/jwilm/alacritty -- the speed is insane.
So in addition to fiddling with resource-heavy nvim plugins I also suggest you try other terminal apps. iTerm is a resource hog.
> I just don't see any reason for it to be faster than C++. > > I do see reasons for C++ to be faster, though, because it allows doing some things that Rust disallows or at least makes very difficult
But, on the other hand, safety means you can write more complicated code that's still fast. It will never be faster than assembly, but it may well be the only way for a human to write complex software like a terminal emulator. Rust says "yeah, we're more limited, but you were never going to write that algorithm in C anyways because it would be a pain in the ass."
That didn't <strong>exactly</strong> happen. But the claim that Alacritty is the fastest in practical benchmarks (dumping unformatted text doesn't count), is disputed to say the least.
I used to use st but I noticed it was having some performance issues, then I found terminator and it was faster, it handled unicode characters better than st, which couldn't display colorful emojis. But recently I made the switch to alacritty and honestly it's really fast. The configuration is easy, it's missing a few features I loved in other terminal emulators but it's getting better. It got the rectangular selection recently which was great for me. If you want to mess with the source code of st and learn how a terminal emulator works that's great. But if you just want a terminal that works fast I say go for Alacritty.
This has been brought up and it will not be supported because of the inconsistencies and issues it causes in addition to the complexity it adds.
A more detailed discussion can be found here: https://github.com/jwilm/alacritty/issues/1919
All selections are automatically copied to the clipboard anyways, so there's no need to press ctrl+c to copy them. If you have issues with this I'd recommend going for the saner choice and binding copy/paste to something different in your OS. I've been using dedicated Copy and Paste keys for a long time and it works everywhere without any issues.
Regarding native Wayland applications with the binary Nvidia driver:
> native Wayland applications should work fine already
Am I doing something wrong? Apart from the Nvidia driver crashing (nothing I can do about that) I can't seem to even get some (not all) native Wayland applications to work. Obvious examples I can think of off the top of my head:
- Alacritty crashes on startup due to failing to create a GL context (https://github.com/jwilm/alacritty/issues/1269)
- Mpv fails to playback any videos at all when using the wayland or waylandvk gpu contexts. You get a black screen and that's it. This works perfectly fine in Sway and Kwin when using Intel graphics.
There are probably other examples I can't think of right now.
Alacritty: A terminal emulator with GPU support for faster vim scrolling. I recommend buying the latest Nvidia card for this. You will get ray traced enabled fonts.
Do some benchmarks for pure rendering performance. Atleast on my machine, urxvt is over 10 times faster and looks smoother in the benchmark.
#create large ~100M file of printable characters base64 /dev/urandom | head -c 100000000 > /tmp/large.txt time cat /tmp/large.txt
Further urxvt with the daemon / client mode makes terminals open instantly and consume very few active resources. I compile urxvt without perl support because I don't need it.(although vs ST, the resource comparison(memory usage) dosn't really matter)
However, when I moved to wayland (sway) I am hoping to switch to alacritty . Alacritty is fast, simple(not as simple as st) and does have true colour support. Currently Alacritty does not have a daemon/client model (requiring 30mb per window) and currently uses much more resources to initialize which is why I not using it now as I open a lot of terminal windows.
std::unjerk::spawn(|| {
Seriously though, would it hurt to market a language as sitting somewhere between C and OCaml, with at least theoretical advantages over modern C++ (as in making it possible to be less defensive when storing references, using non-atomic reference counters, passing pointers between threads, etc. Now I feign no hypotheses whether that does actually improve performance, or is just voodoo)?
Or maybe it would hurt, as less memes and less shit stirring, with the unwitting help of those annoyed by rigged benchmarks, would mean less exposure and thus fewer people who try it out of sheer curiosity, and might end up liking it. I wonder if it's deliberate.
});
It was pretty easy for me. Once I got hardware setup it was a just a matter of installing i3-gaps, polybar, firefox, terminal emulator of choice (for me, Alacritty), and echo "exec i3" >> ~/.xinitrc. Then you just write/copy/mix config files to your heart's content and install a gtk/firefox/qt theme. After logging in I just run startx to get into i3 (though you can easily automate this on login, or you can use a display manager).
So, to answer your questions:
1) Yes you need some window manager. This could be as lightweight as xmonad or i3 or as fully-featured as gnome or kde. It's up to you.
2) I think this is fairly dependent on you setup (wm and distro to a lesser extent). For i3 there's a fairly good youtube series that got me into it at first (here's the first video).
3) Yeah all you have to do is get arch setup (probably the hardest step), sudo pacman -S i3, echo "exec i3" >> ~/.xinitrc, startx. But you'll be screwed without a terminal emulator (otherwise you can't access a terminal), so I'd install that first. You can open it with dmenu search ($mod+d).
Hope this helps.
It's used by (and developed for) Alacritty: https://github.com/jwilm/alacritty/blob/864cd9b8ef2c7d708d4160756e51dfa4bab94f16/alacritty_terminal/Cargo.toml#L23
Not 100% sure, but your clipboard issue may have something to do with the hotkey presets? I know there are some that affect the copy + paste combos: https://github.com/jwilm/alacritty/wiki/Keyboard-mappings
>I disagree with your assertion that rewriting must by definition introduce bugs
Writing code in general creates bugs. Rust is not immune to bugs:
https://github.com/jwilm/alacritty/issues?q=is%3Aopen+is%3Aissue+label%3A%22B+-+bug%22
https://github.com/gfx-rs/gfx/issues?q=is%3Aopen+is%3Aissue+label%3A%22type%3A+bug%22
https://github.com/BurntSushi/ripgrep/issues?q=is%3Aopen+is%3Aissue+label%3Abug
I could go on.
Maintaining existing code does not create new bugs.
I don’t see it mentioned in this thread, have you tried alacritty?
There are tricks to get Linux terminals to run with a gui in WSL so you aren’t stuck with Windows’ not great cmd experience.
I've not tried it yet, but I'm not really convinced by alacritty. Seems to me the only reason people use it is because of their bold claims of being 'the fastest terminal emulator in existence', but this is demonstrably false
> Is there a way to control the default initial window size when starting Alacritty?
There is: https://github.com/jwilm/alacritty/blob/master/alacritty.yml#L15-L22
There are some X11 WMs where this still causes problems, which will hopefully be resolved in 0.3.1, but at least in i3 it already works great so you can definitely give it a shot.
> On Mac OS X, I can't figure out how to launch it from the desktop without a Mac Terminal session hanging around for having spawned it.
I'm using macos only at work and have a custom WM setup to make it usable for me, so my workflow might not be 'usual'.
I think what I did before switching to a custom WM was launching the first instance through launchpad and then opening other instance with a custom keybinding using the SpawnNewInstance action. But now I just have open -na /Applications/Alacritty.app mapped to a key combination in chunkwm and everything works great.
Well, you can compare the two yourself if you wish, I like Alacritty because of GPU-acceleration. It works really well keeping ncurses apps snappy, and is under constant development.
You might look at this blog post.
I use alacritty, which is designed to be used with tmux.
I have the following in .tmux.conf to get 24-bit color support working:
set-option -g terminal-overrides ',xterm-256color:Tc,st-256color:Tc,xterm-termite:Tc,xterm-256color-italic:Tc,alacritty-256color:Tc' set-option -g default-terminal "tmux-256color"
I have the following in .vimrc:
set t_8f=[38;2;%lu;%lu;%lum set t_8b=[48;2;%lu;%lu;%lum set termguicolors
Note that you sometimes also need to run tic on the terminal's terminfo file to get its colors (and italics) working right.
have you tried alacritty? If so, do you have any opinions of either terminal?
I was too deep into configuring alacritty when I discovered kitty.
*EDIT*: just realized you're the creator of CHUNKWM. oh my god. love what you're doing and the options you've presented fo*r mac*OS users such as myself!
Tried many (if not all) of the available ones on osx. So far vimr is the best one for rendering speed, but I've been using it only for a couple days so I can't say anything about stability or hiccups. The electron based nyaovim has some potential but in my experience it tends to be very slow in some edge situations (e.g., opening a big rails schema.rb file with a lot of ale linter errors). Same goes for nvim-qt. Even the terminal based combo with alacritty, tmux and neovim isn't as fast as vimr when scrolling the above file. So yes, vimr is really good.
Written in D for some reason, wierd.
Anyway, just learn Tmux and use regular terminals or something like https://github.com/jwilm/alacritty imo, way more beneficial in long run and Tmux is found on pretty much all unix like systems in official repositories.
Two things you could try, while staying in the windows theretory (not using wsl or anyting like that)
Use terminal neovim (nvim.exe) with more modern terminals alacritty or the new windows terminal
I personally run neovim under wsl (with alacritty) or using fvim, which I fell in love with as a neovim gui. It is pretty and fast (for the most part) supports ligeratures etc. It's startuptime is kinda slow, but as I do not closed neovim as a gui as often as I would to, when using it in the terminal, this is not an issue for me.
I've tested many of them and Alacritty is the best.
https://github.com/jwilm/alacritty
I'm using it with my very custom tmux. It's fast, extremely configurable and effective.
Alacritty terminal has this as a configuration (decorations: none). Here's my config file.
I tried with Alacritty which also suffered from some level of stuttering. One interesting observation from your solution is that log-update doesn't clear the screen with ESC[2J, but instead clears all lines individually. Intuitively it feels like that should be slower, but it guess it isn't.
Alacritty has a visual bell, which I actually prefer because I don't need headphones all the time or annoy other people. Audio bell is planned though.
https://github.com/microsoft/terminal/issues/376
https://github.com/microsoft/terminal/issues/545
Looks like they plan to have it fixed next month. That'll be nice because it also blocks things like alacritty.
- Terminal: Alacritty
- Bar: polybar
- Editor: Neovim
- Programs on the screenshot: neofetch (top left), cava (top right), Neovim (bottom left), gotop (bottom right)
Alacaritty, kitty, and st all support Nerd Fonts well. Recent versions of Konsole likely work too.
You might want to try putting a space after the double-width characters in your configs to make the icons render correctly in some terminals.
Last I read on the situation was this in 2017 https://github.com/kovidgoyal/kitty/issues/84 and switched to Alacritty soon after, but Kitty has better opacity support (Alacritty gets weird artifacts (https://github.com/jwilm/alacritty/issues/889) so I'm tempted to switch back to Kitty.
I have hide_window_decorations set to true, but my kitty version might be a bit old by now.
A few suggestions I'll drop here because most of it relates to terminals. I'd recommend trying tmux+alacritty. If you use linux at all or even if you don't, using a term like alacritty is great as you can easily share config files, its written in rust and has GPU acceleration which is a bit niche but it's a nice feature; alacritty has great resource optimization and idles at less than 1% memory consumption for me. Also tmux over iTerm split pane/tabs or hyper split pane/tabs is great imo because you can close your terminal and the tmux session will be kept alive so you can attach to it later. Tmux also has the advantage in that it's a consistent tool that you can use no matter which terminal you end up in. Although hyper as a recommendation may look good to some, alacritty should be faster as it's GPU accelerated, written in rust and DOESN'T USE ELECTRON. Having a terminal based on electron just seems ridiculous to me. On a MacOS specific note, setting up Karabiner elements + hammerspoon is a useful workflow optimization step to take. If you follow a guide like this you'll end up with the ability to quickly resize and snap windows to specific shapes using just a three key presses and some other useful keyboard shortcuts.
I just switched over from kitty, and was surprised at how much it's progressed. I'd suggest taking a look at the example config and seeing for yourself if it's good enough to use yet. One of the pleasant surprises I found was that most config settings (minus font) are hot-reloaded, so ricing your terminal is a lot nicer.
No, Alacritty is the fastest terminal but that doesn't help WSL because the terminal itself is not the bottle-neck. It's just going to take MSFT some time to make the underlying technology faster. Or you have to buy a faster CPU/SSD
Thanks a lot for the info, turns out that it was trivial for Alacritty to support 1.31 and I think that's a great choice because of Rust 2018 too.
So hopefully that will make things a little easier on maintainers in the future!
I've used ConEmu, it has 24-bit color. I don't remember why, but it seemed wonky when I used it.
Yep! Though I can't boot Alacrity (no OpenGL 3.30 support https://github.com/jwilm/alacritty/issues/128) and Android Studio just gives me a background color (but it runs much faster, 😏).
Ligature support for Alacritty. However, I think that I'll start over by making a generic shaping API that is rasterizer-independent, and operates directly on font files.
Huh, I was unaware that termite was modal... Very interesting, I might have to use it a bit. It doesn't have ligature support, but niether do urxvt or alacritty.
Really, the reason I like urxvt is its daemon mode, it's blazingly quick. The issue on Alacritty for the feature is pinned, but is blocked by refactoring the rendering code into a library (so libalacritty can be used in bells-and-whistles terms as well).
I've been on sway for almost a year and it's fantastic & much more stable as of 1.0 (beta). I'm a terminal-heavy user, so I don't need a lot of fancy features. +1 what martins_m said about disabling noveau.
I haven't yet found a blazing fast wayland-native terminal with support for ligatures and scrollback. I would love to switch to alacritty once they add ligatures 1 and reduce boot time 2. Right now, I use termite and it's great aside from this single concern.
There's some small stuff that probably won't apply to you - I wish I could bind Ctrl+Shift+- to output an em-dash, or Ctrl+Shift+4 to take a screenshot of part of the window (a la OSX).
I feel you pain. I moved away from urxvt for many similar reasons, including this one. Perhaps this thread will help, or searching things related to Pango. I don't think I ever got this working, so my suggestion should be taken with that in mind. Now, I use Alacritty and, more recently, Termite. I don't use urxvt anymore because it's pretty old and I don't like how it "feels" to me, but don't get in the habit of switching software/distros when you run into an issue. That's something I had to unlearn. Best of luck!
Ok so reading through that it seems that the version of GLSL that crostini is running is 3.0
Seems like Alacritty needs 3.30+
https://github.com/jwilm/alacritty/issues/128#issuecomment-429118476
Are you referring to the benchmarks from 2017 or the ones from September 2018 I linked? The newer ones are documented and the testcode is published.
https://github.com/jwilm/alacritty/issues/289#issuecomment-422196471
As for features, if you don't use them, then you don't need them.
Interesting. Never really thought about the speed of a terminal before.
I did find this, which calls the benchmarking into question and leads into and interesting discussion about how to properly go about making a consistent speed test for terminals. Didn't trudge through all of it, but I believe the takeaway is that alacritty does shake out near the top of most tests.
If you use tender.vim and alacritty, you might also want to use this tender-alacritty color scheme to have an identical theme in both terminal and vim.
If you use tender.vim and alacritty, you might also want to use this tender-alacritty color scheme to have an identical theme in both terminal and vim.
If you use tender.vim and alacritty, you might also want to use this tender-alacritty color scheme to have an identical theme in both terminal and vim.
Have you tried Tramp?
But I have used in a terminal without any problem.
Your experience depends on which terminal emulator you're using.
Try something like alacritty ?
No, no slowdown whatsoever. Perhaps there are other factors making vim slower for you? I've found iTerm to be awfully slow with it, and switching to Alacritty sorted that out. If it's not the terminal, you can also try profiling vim to see what's up.
Firstly I'm using what's called a window manager (WM) not a desktop environment (DE). But to answer your questions:
You can set the font in alacritty by editing ~/.config/alacritty/alacritty.yml. Both of these packages can be found using xbps-query and are in official void repositories.
If by slurp you mean consume and store the complete output in memory of the output the program and then print it, than that sounds really inefficient memory wise. How large was the buffer 100M, larger, 'infinite'. Or did it just throw away what did not fit in the buffer?
The benchmark is flawed; true, given you point and also especially since the base64 random text doesn't look like the normal text you print (no newlines, colour, escape sequences). But for whatever reason I see this benchmark and similar used for testing the rendering performance of a terminals all the time. Ex: https://github.com/jwilm/alacritty/issues/289
Regardless, urxvt and ST (there are probably patches to improve performance also) both render fast enough it probably does not matter. However, I have a high repeat speed on my keyboard and when I scroll in a manage holding 'j', urxvt is perfectly smooth other terminal emulators are not.
Yup and yup. Went through the wiki a few times - just in case I missed anything. I have no evidence to support this theory, but I feel the issue lies with w3m. I am going to play with urxvt / ranger to see if that works; but, to be honest, I probably won't switch terms - alacritty is pretty sweet. I found a post, here on unixporn and github, stating that alacritty image-displaying worked, but I can't seem to reproduce what they are doing.
The problem is. With these new generation terminal emulator, rendering emacs in these terminal emulator is faster than GUI on my machine.
Check alacritty https://github.com/jwilm/alacritty and kitty https://github.com/kovidgoyal/kitty
as an example, unless you are familiar with rust all of this is just gibberish. https://github.com/jwilm/alacritty/blob/master/src/display.rs
i consider myself proficient in a fair amount of languages, c, c++, python, go, c#, bash, js, java, even obj-c - and these are just languages i've had to develop professionally but i'd say all (except maybe obj-c and bash) have an innate readability. rust does not fall into that
You are probably following the the instructions to install on Arch Linux. There's no makepkg part on macOS.
Read the Manual Installation section and then this one.
It didn't solve the lag or you couldn't install it? The instructions on the readme.md are pretty straightforward, just make sure you create the app bundle: https://github.com/jwilm/alacritty/wiki/MacOS-application-bundle
CodeMirror! Sounds cool. I have never thought of it when talking about building terminal emulators. Maybe I should dig into your Extraterm someday.
Maybe yes command is not a good example. I tested each terminal emulator by typing ls -lR in a large Node.js project. Some of them without GPU-acceleration became laggy. In contrast, hardware-accelerated terminal such as Kitty, Alacritty and macOS builtin Terminal.app (it sould be!) can display large text streaming smoothly at 60 FPS. There is still a gap between modern browser tech and GPU rendering these days.
But who cares the speed of ls -lR. We need functional and convenient tools!
Does this give the possibility to run VLC in the terminal? Is this the terminal emulator that allowed this years ago?
Edit:
I was mistaken, Alacritty is written in Rust and afaik, doesn't support video output in the terminal...yet. reddit post
Try a few ones. On one end there's alacritty which takes a more st-like approach (minimalism and not-so-many features, focused on speed, I doubt w3mimgdisplay will work here but there's no harm in trying). On the other end, there's cancer which takes a more urxvt/xterm-like approach (it has many cool and experimental features, it even supports sixel so w3mimgdisplay has a chance of working there).
mlterm is also cute. My font looks weird in it but it supports Hebrew much better than any other terminal and it also supports sixel
But generally just look for terminal emulators in the AUR or on Github, read about them and try the ones that seem good.
Have you ever used a GPU accelerated terminal? 60 fps in terminal makes suprisingly big difference.
https://github.com/jwilm/alacritty
That app changed the way I look at shell output - I can't work with gnome-terminal or other traditional terminal anymore.
It seems like that's the case, which is actually weird. Either way, both drivers are fast enough for you to not care in that particular use case. If you really want to go fast, try Alacritty - it's OpenGL based and is considerably faster than even urxvt.
> Even iTerm is super slow
This is 100% true. I have high hopes for alacritty though. I tried it out with vim+tmux and it already seems a million times faster than iTerm. https://github.com/jwilm/alacritty
Haven't tested it much but see for example: https://github.com/withoutboats/notty for UI innovations, and: https://github.com/jwilm/alacritty (which apparently will merge some functionality of notty in the future), for performance innovations.