I just want to say that this project is amazing. At the risk of sounding hyperbolic, I think Rust is the most exciting thing that's happening in computing today. This sort of project that plausibly replaces software traditionally written only in C/C++ with something that has performance parity, but is in a language where contributions are relatively accessible and safe, is the most exciting thing even within the bounds of an intriguing ecosystem.<p>As someone who is especially concerned about the performance of my tooling these days due to what seems to be a generally infinite willingness to accept web apps that are slower than desktop apps from decades ago, and which seem to continually demand more resources year over year, I really appreciate that such a distinguishing eye has been given to Alacritty's speed and resource usage. Some contemporary alternatives like Electron-based terminals are academically interesting, but are programs I'd never want to use due to the huge step backwards in these areas.<p>One question: do you have any plans to use Alacritty to try and advance the state of terminal emulators more generally? e.g. Displaying images, richer interfaces that don't depend on ASCII bar characters, graphs, properly tabulated results, etc. This is a direction that I wish we were going, but it's not clear to me how to get there without many sacrifices.
I really disagree with the authors definition of minimal.<p>Terminal emulators have such a minimal user interface as it is it's a bit boggling that I have to make the case for the following "bloat" that other terminal emulators have.<p>I need scrollback because I do occasionally pick up my mouse and grab things that have scrolled off the screen. Tmux doesn't help with this but maybe there is some magic that I don't know these days.<p>I need tabs. At any given time many of those tabs might have instances of tmux somewhere in their multiply nested depths, generally on remote hosts.<p>I'm not going to start tmux on every local prompt just so I can use Alacritty and thus intentionally starting a tmux in tmux funshow.<p>I use "Monitor for Silence" "Monitor for Activity" pretty consistently.<p>It's free software so I glad the author is making something and hopefully enjoying the process. I can't really use this or consider it until he reconsiders. Maybe he'll get some collaborators that will argue him around on this.<p>Cool project otherwise.
It sounds like a fun project, but I don't really understand what performance issues this solves? I don't think I've ever had an issue with slow terminal rendering using the default terminals on Ubuntu or Mac OS. What sort of applications do you run where it becomes an issue?<p>On the other hand, something like mosh [1] seems like it could be really useful on slow network connections. But that's not about <i>rendering</i> faster.<p>[1] <a href="https://mosh.org/" rel="nofollow">https://mosh.org/</a>
> Make sure you have the right Rust compiler installed. Alacritty is currently pinned to a certain Rust nightly<p>Ok, I'll... um not do that. Hope you publish a build soon though!<p>edit: more seriously, the nightly compiler situation on rust is going to become a problem as it gets more developer use. I really hope they're able to stabilize it.<p>edit 2: I'm really sorry if I derailed the conversation in a not useful way, @jwilm
Jwilm: This is great, and I'm really looking forward to following this project; beers on me and thanks for the effort!<p>A few findings from my side if you want some feedback, I generally work mosh'd into some beefy servers with a long running tmux I resume -- so I'm probably the use case this is aimed at (client: xps13, archlinux).<p>1) If I create a vertical split view (tmux_key+v) while I already have some output in the left side of the split, and have nothing but my prompt in the right side; then resizing the split is instant/snappy.. However, if I then do a find / in the 'new' (right) split, ctrl+c it after a moment and then resize it lags/judders hugely -- I'm not sure what's going on there but let me know if you'd like me to try and explain that more if you can't reproduce from that.. This doesn't happen in termite..<p>2) I had to set offsets and use a giant font to make it look reasonable on my (highdpi) lappy:<p>font:<p><pre><code> normal:
family: SourceCodePro # should be "Menlo" or something on macOS.
style: Regular
bold:
family: SourceCodePro # should be "Menlo" or something on macOS.
italic:
family: SourceCodePro # should be "Menlo" or something on macOS.
size: 26.0
offset:
x: 4.0
y: -30.0
</code></pre>
Otherwise:<p>+100 :}
Hm, if we're doing GPU rendering for speed, I'd suggest uploading vector glyph data to the GPU and rasterising on the GPU in the pixel shader, rather than using FreeType. See here: <a href="http://wdobbie.com/post/gpu-text-rendering-with-vector-textures/" rel="nofollow">http://wdobbie.com/post/gpu-text-rendering-with-vector-textu...</a> . The WebGL Demo is really impressive - it lets you zoom in and out on a multi-page PDF at speeds I haven't seen anywhere else.
><i>tabs and scrollback are unnecessary. The latter features are better provided by a terminal multiplexer like tmux.</i><p>I beg to differ. I don't really know whenever there's a project that's almost perfect, there's some braindead decision that cripples it with no good reason.<p>I'd understand it if some more advanced or exotic feature wasn't available, but scrolling?
A pity you can't use Vulkan on MacOS. Otherwise you could have used vulkano[1] instead of OpenGL.<p>1. <a href="https://github.com/tomaka/vulkano" rel="nofollow">https://github.com/tomaka/vulkano</a>
This is a very interesting concept and another example of what can be done with Rust. However and without the intention of discouraging the author, I did not find any performance improvement from Alacritty using Ubuntu 16.04 on an i7-4500U (using integrated graphics HD 4400). Here are some numbers, simply printing the contents of 446 files:<p>At 80x24:<p>gnome-terminal:<p><pre><code> real 0m0.848s
user 0m0.032s
sys 0m0.072s
</code></pre>
Alacritty:<p><pre><code> real 0m6.832s
user 0m0.032s
sys 0m0.164s
</code></pre>
At fullscreen:<p>gnome-terminal:<p><pre><code> real 0m0.819s
user 0m0.020s
sys 0m0.088s
</code></pre>
Alacritty:<p><pre><code> real 0m8.972s
user 0m0.064s
sys 0m0.164s
</code></pre>
The font was a tad smaller by default on Alacritty, changing it made no significant difference in the numbers. Since the difference in performance was quite noticeable I decided not to test other possible configurations, but I could do so if it might help.<p>My graphics card has a pretty poor performance in general so that might be an indication that, since the performance of Alacritty is directly impacted by the graphics card, it might be useful for the author to determine the "minimum requirements" for Alacritty to outperform the competition.<p>In any case, it might not be a fair comparison as the author has stated that this is a pre-alpha release, but maybe he can find it helpful in some way, as he suggests he hasn't been able to find a test in which Alacritty didn't perform as well as another terminal.
Nice, but:<p><pre><code> thread 'pty reader' panicked at 'index out of bounds: the len is 24 but the index is 24', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcollections/vec.rs:1371
</code></pre>
or<p><pre><code> thread 'pty reader' panicked at 'cursor fell off grid', src/term/mod.rs:634</code></pre>
While GPU accelerated 3D interfaces (like it in 3D games) is a good idea (at least one could mix data visualization and with controls - the way WebGL guys do it) a terminal emulator does not require any acceleration, leave alone having a Nvidia drivers or Cuda as a dependency.<p>What a decent terminal emulator should have is standard compliance and decent font rendering (and freetype is good-enough).<p>Lousy engineering will lead to lousy code, especially when the main objective is to show off (engineering is, obviously, not an objective.) Btw, using Rust is <i>not</i> an engineering.
I'd like to host this terminal in a 3D environment. Any plans to enable this? Perhaps with a signed distance field texture.<p>I'm building a 3D game in Rust and would like to be able to drop this in.
> Both the utf8parse and vte crates that were written for Alacritty use table-driven parsers. The cool thing about these is that they have very little branching; utf8parse only has one branch in the entire library!<p>From a simplicity point of view table-driven parsing is pretty neat. However, it does mean you'll be getting a lot of branch misprediction in your single branch, since it's harder for the CPU to predict where it will branch to. You could probably go faster with some handcoding in the parser.
I didn't even realize my (iTerm2) terminal emulator wasn't fast until I tried Alacritty. When doing non-intensive tasks, the difference is less one of vision and more a "feel". And it feels SNAPPY. And, as a heavy tmux user, I'm definitely your target audience.<p>But...the font rendering doesn't look as good as iTerm's, at least not yet.<p>I suspect I'll be swapping once you're at a public build release.
I really like this. It combines my love of tmux and vim with my interest in rust, system software, terminals, and my eternal quest for the fastest, simplest, most cross platform terminal development environment. Great job - looking forward to running nightly builds of this.<p>EDIT: Ah, after a little sleuthing, the recent post from OneSignal on why they chose rust for one of their services makes sense :).
Installation was surprisingly easy.<p>And performance was surprisingly good. `find /Applications` results in...<p>- Unrecoverably crashing Hyper
- 1:28 iTerm2
- 0:32 Terminal
- 0:20 Alacritty<p>Very impressive stuff. I'll be keeping an eye on this project.<p>And performance was surprisingly good; a `find /Applications` on my computer crashes Hyper, takes 1:28 on iTerm2,
Looks great so far. Other than scrolling support, the one thing I miss the most is the use of the up arrow to scroll through history. Ctrl+R is great, but sometimes I just want to scroll through my most recent commands.
Like 58% faster than iTerm2 in my Late 2013 MBP retina.<p><pre><code> find ~
iTerm2 1m20s
alacritty 47s
</code></pre>
where the find command itself uses between 40% and 50% of a core, the TERM emulator process uses is 5x in iTerm2<p><pre><code> iTerm 130% (peak up to 140%)
alacritty 25% (peak up to 29%)
</code></pre>
I'm very excited with this and I'm going to follow the development of alacritty :)
Wow, I am definitely the target for this. I often have tmux panes watching fast-scrolling log files while trying to continue to work in another pane. I've been trying to tweak tmux to perform better, but it really is the rendering speed that's holding it back.<p>The lack of scrollback/tabs/etc doesn't bother me at all - I use tmux for this exactly as suggested.<p>Thank you for this!
I really, really like this so far. Interestingly, it's dependence on tmux (which I really like overall) for 'extra' terminal features presents some problems for performance and usability.<p>Tmux has its own non-trivial rendering bottlenecks, the most significant of which comes into play when you have multiple clients attached to a session. As a test, I went into a notes folder and did `grep -r e .`. When Alacritty was sized larger than mate's default terminal, mate's default terminal finished rendering first. When Alacritty was sized smaller than mate's terminal, Alacritty finished first. Also of note was that Alacritty running tmux rendered slower than mate's default terminal without tmux. This was an uncontrolled experiment, especially since this was a tmux session with a couple windows with a couple panes per window, on a tmux server with 2 other sessions (with a lot of vim windows etc), but something tells me the results would be the same if I used a tmux server with one session/window/pane. As a tmux user, this isn't a huge deal to me, but it should be concerning the the Alacritty devs since Alacritty requires a multiplexer to be usable.<p>My biggest concern, however, is not performance related, but usability related. Consider this use case: Alacritty -> ssh into remote server -> run tmux on remote server. How am I supposed to paste anything into that remote tmux session now? Am I supposed to nest my remote tmux session in a local tmux session? That sounds awful! I've found satisfactory workarounds to the lack of copy/paste when working locally, but it falls apart when I can't rely on duplicating the tmux register to the clipboard (and vice versa) because the clipboard is remote.<p>If I can find a workaround to the remote paste issue, I will probably use Alacritty exclusively. Otherwise, I can't use this terminal for remote work, and I'd rather not run two different terminals just so that rendering is faster _sometimes_
Oh thank you so much!!! I am right now in dire need of light terminal (read st's equivalent) for macOS, since iTerm2 felt bloated since few years ago and font rendering is kinda meh, and it is slow, and it has many many features I really do not need, and Terminal.app simply doesn't make the cut (no true color support for example). I need speed, true colors, and minimalistic terminal as possible, since I use tmux (tabs and gui not needed) for anything if I need more than one terminal screen. Not sure if this is worth the hassle to set up right now, I might just wait for alpha release. But I am watching this on GitHub and can't wait to try it! (plus it's Rust which almost made me dance in my room)
As a tmux+vim user, this hits right home for me. I never use terminal tabs and do almost everything inside tmux.<p>The only time during development I use a other app is when I start neovim-qt, just so I have faster rendering and squeeze even more performance out of it. If Alacritty is giving me the same speed without me having to spawn a graphical vim for it, sign me up!<p>I'm going to try this as my main tool for a couple of days and collect some feedback :)
<a href="https://github.com/unconed/TermKit" rel="nofollow">https://github.com/unconed/TermKit</a> or <a href="https://acko.net/blog/on-termkit/" rel="nofollow">https://acko.net/blog/on-termkit/</a><p>TermKit is another terminal app from 2011 designed to modernize the command line experience.<p>Sadly, I don't think it's being worked on anymore.
Also, Cathode is a terminal made with OpenGl and it's really fast: <a href="https://www.jwz.org/blog/2011/01/cathode-vintage-terminal-emulator/" rel="nofollow">https://www.jwz.org/blog/2011/01/cathode-vintage-terminal-em...</a>
Very impressive. I am manipulating huge amount of text data on a regular basis directly in the terminal, smoother exhaust experiment is a huge win. I wish I can give you some money right now to support the development.
Having never thought my current terminal emulator was slow I was surprised to immediately see a difference with Alacritty!<p>That being said, every time I install a package useing apt-get (Xubuntu) Alacritty crashes with the following:
thread 'pty reader' panicked at 'index out of bounds: the len is 24 but the index is 18446744073709551615', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcollections/vec.rs:1371<p>I guess we're not quite at 1.0 yet but looking good otherwise!
Awesome! This is exactly what I've been hoping for. The state of terminal emulators on macOS is particularly bad, at least when it comes to speed. Both the built-in term and iTerm have a lot of features, but really start to lag on big screens with a lot of text. I used to run urvxt under XQuartz for this reason, but there's scaling problems with retina screens these days.<p>Nice work. Hopefully this can fill a particular void for folks that want no-frills fast terminal emulation.
so this uses GPU-accelerated rendering with OpenGL. TBH I have never used OpenGL and when I read "GPU-accelerated XYZ" this still sounds like magic to me because I've know idea how this works. Could you point me to some resources where I can read up on this stuff? if this helps you: I am not a newbie, I already know C, C++ and Rust, but I haven't done any graphics programming at all yet. For example I only have a very rough idea what shaders do.
Thanks for making this and posting it. This is a thing I've been looking for (simple accelerated terminal that performs well) for a very long time.
> Welcome to nginx!<p>> If you see this page, the nginx web server is successfully installed and working. Further configuration is required.<p>On jwilm.io -- Just wanted to let you know
Wow. I just installed this on macOS, and the difference in speed compared to iTerm 3 is huge!<p>I always assumed that it was my bloated vim and tmux configs that made it feel a bit sluggish sometimes, but it turns out i was the terminal. Now everything feels instantaneous.<p>After some color bugs have been ironed out I'll switch full-time.
Great idea and I hope Alacritty continues to evolve because it should eventually be the fastest given the GPU integration. However, st is faster on my system, supports bitmap fonts like SGI screen, handles true color, works when no GPU is present, has half the LoC, and has less dependencies.
Excited and happy to see such a project!<p>I am using iTerm2 on a maxed-out MBP 15 Retina quad core and Xshell on a $150 Asus Cherry Trail netbook. You won't believe it but Xshell on the crappy netbook feels light-years faster and more responsive than iTerm2 on the MBP.<p>Wondering how Alacritty will perform, looking forward.
For those who rely on tabs, one great advantage of relying on the multiplexer instead is that your "tabs" live within the terminal, so when you ssh into your session, the machine has all your "tabs" ready and waiting instead of tied up in a non-accessible GUI.
Not sure why they rebuilt a clipboard library when "clipboard" exists (I think it might even be used within Servo, not sure): <a href="https://crates.io/crates/clipboard" rel="nofollow">https://crates.io/crates/clipboard</a>
A relevant Destroy All Software talk: <a href="https://www.destroyallsoftware.com/talks/a-whole-new-world" rel="nofollow">https://www.destroyallsoftware.com/talks/a-whole-new-world</a>
I added support for Alacritty in my iTerm color scheme conversion tool:<p><a href="https://github.com/davesque/iterm_convert" rel="nofollow">https://github.com/davesque/iterm_convert</a>
Just installed on Linux Mint. The installation was quick and painless from the instructions, and it is noticeably faster than my previous MATE terminal. We'll see if I notice a lack of scrollback.<p>Thanks!
Love the project! Completely agree with minimalistic philosophy. I can see why some people feel like scrollback would be needed, I personally myself always work in tmux sessions, but still.
Impressive! I run <a href="https://github.com/slash-hq/slash" rel="nofollow">https://github.com/slash-hq/slash</a> and it just works.
This is really cool though I can't seem to get it to build on my mac. Though the stock OSX terminal is plenty fast for me. Maybe I don't do enough intensive work
> Using vim inside tmux in many terminals was a particularly bad experience. None of them were ever quite fast enough.<p>When does this slowness show itself?
heh just fyi, my F-secure reports:<p>"Harmful web site blocked. blog.jwilm.io<p>This web site has been reported as harmful. We recommend that you do not visit this web site."
Projects like this are so so close but fall just short of the ideal. I've been thinking about this for years but I have not been at the point in my life where I could implement my ideas which are these:<p>1.) A UI which is just a line/text field to enter commands. Something like the command prompt but which fuzzy matches commands like the mini-buffer in emacs or the omni text field in Chrome or Firefox or even Enso from a few years back.<p>2.) Each command is name spaced to an "agent" to avoid command collisions. For example agent 'jarvis' would have a set of commands it response to like jarvis/foo, jarvis/bar or jarvis/baz.<p>3.) The output of each command is a list of 0..N items/objects rendered in a master/detail view where navigation over the list shows a detailed view of each object/item in the list.<p>4.) An item/object can be anything from an email, rss entry, web page, graphic, tweet, contents from a text file. Basically anything that is renderable.<p>5.) The output of any command can be piped to any other command which is able to parse the list of items/objects from the prior command and render its own new list.<p>This UI paradigm seems to cover an incredibly large set of use cases. The only use cases I can think of which are not covered are those where the keyboard input device is not sufficient; such things as graphics manipulation where a mouse or pen & tablet are needed.<p>The frustrating thing for me has been to witness the vast number of systems over the years that have nibbled at the edges of this paradigm but have not gone all the way. What I'm talking about mostly here are the numerous launcher systems like Enso or Quick Silver or dMenu. All these systems have UIs very similar to what I'm talking about but they're restricted to launching existing apps and controlling the options exposed in menus of existing apps.<p>The other class of applications I've seen that come close are the ones like that mentioned in this topic. Applications like notty where the effort is spent trying to shoehorn extra rendering capabilities into a terminal emulator.<p>What I want is essentially a Grand Unified User Interface (GUUI) such that applications as we know them are done away with and we only deal with commands and output.<p>A system where I can type web/news.ycombinator.com and a one item list comes back with that first item selected by default in the details view. And that item is the front page of Hacker News. Then I could next type email/inbox and a list of emails in my inbox are rendered. And of course while viewing one of the items in my email/inbox I could type email/reply which would render a text area to reply to my previously selected email.<p>As I said earlier, the use cases seem endless and this paradigm seems like it would be incredibly efficient for those who can type well.
This could definitely be tagged as a Show HN (<a href="https://news.ycombinator.com/showhn.html" rel="nofollow">https://news.ycombinator.com/showhn.html</a>).