
Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust - jwilm
http://blog.jwilm.io/announcing-alacritty/
======
brandur
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.

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.

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.

~~~
sliken
I tried the terminal. No scroll bars, no menus, and no highlighting of URLs.
Not nearly as functional as the original xterm from the early 90s.

It might be super fast, but I've not really been scroll speed limited.

~~~
barrkel
I generally use rxvt because xterm is too slow. It doesn't have menus or URL
highlighting and scrollbars are nonfunctional in the presence of screen, tmux,
Emacs or generally any interesting terminal app.

On Windows I use mintty and I turn off scrollbars there. I simply don't use
the mouse to interact with the terminal other than to select text, and that's
with selection buffer to copy.

Speed is highly relevant to me. Most modern terminal emulators are very slow,
most noticeable when you get a lot of output in a panel in something like
tmux.

(Simplistic benchmarks that test full screen scrolling usually hand the crown
to terminals that don't bother to refresh the screen with everything output,
but that's not the only bit of a terminal emulator that can be slow.)

~~~
stuaxo
Interesting. For me, there isn't enough integration between the GUI and
terminal ... they shouldn't seem separate, but should be bridged to create a
coherent experience.

------
WhatIsDukkha
I really disagree with the authors definition of minimal.

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.

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.

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.

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.

I use "Monitor for Silence" "Monitor for Activity" pretty consistently.

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.

Cool project otherwise.

~~~
lobster_johnson
> Features like ... are better provided by a terminal multiplexer

I would strongly argue that this thinking is putting the cart before the
horse.

I don't use tmux, nor do I want to (though occasionally I have to use screen
as a hack to keep programs running on remote servers, and I hate every second
of it). Solutions like tmux arguably exist _because_ terminals have poor UIs,
and the terminal protocol is too weak to form the foundation for the kind of
interactivity and statefulness provided by modern graphical UIs. If terminals
were as powerful as, say, web browsers ( _not_ that I'm suggesting that anyone
conflate them), the world would be a different, happier place.

I think Hyper [1] is going down the wrong path, but I strongly believe a new
"terminal-oriented UI model/protocol" could be invented that would scratch
every possible itch — good for text, mouse support, custom UI widgets,
_seamless_ remote connections, multiple screen regions — without sacrificing
functionality at all.

[1] [https://hyper.is](https://hyper.is)

~~~
jwilm
Thank you for the thoughtful comment.

There's been a lot more pushback on the scrolling decision than I had
anticipated. It's not something I want in my terminal, but it seems that a
simple feature like this is essential for others. Perhaps I should reconsider.

I worry that a "simple" feature like this may be overly complex internally.
Performance with large amounts of output is also a concern. At least if we
were to add support, it could be designed as a build feature and be removed
completely if it were undesired.

~~~
netheril96
> Performance with large amounts of output is also a concern.

Frankly, removing two very important features for a lot of people (me
included) and then claiming highest performance feels a bit like cheating.

~~~
arandomcoder
I respectfully disagree. Alacritty follows the Unix philosophy of doing one
thing, and doing it well. I used to think that terminal scrollback and tabs
were great ideas -- but switching to tmux changed my mind completely. Tmux is
so much more capable for managing your session history. The terminal's tab and
scrollback features can never match this. They're just bloat :p

~~~
lobster_johnson
> Alacritty follows the Unix philosophy of doing one thing, and doing it well.

That principle is often misapplied, and I think that's true here, too.

The "do one thing" about Unix is really about composability (e.g. "find"
doesn't need to sort because you do "find | sort"), but you don't compose a
terminal app with anything.

A _terminal_ app that has _terminal features_ doesn't violate any principles
of simplicity.

~~~
chriswarbo
I use st as my terminal application. Inside, I run dtach to provide
detaching/reattaching functionality. Inside that I run dvtm to provide
multiplexing and scrollback. Inside that I run bash. Inside that I run ad hoc
commands.

Everything's highly composable, e.g. I can switch out bash for zsh, fish, etc.
I can switch out dtach for abduco. I can switch out dvtm for tmux or screen. I
can switch out st for xterm or urxvt. And so on.

Adding an extra layer for scrollback, separate from a multiplexer, wouldn't
disrupt anything, and would provide more flexibility for composition.

~~~
atombender
Each to his own. Your setup sounds like a parody of the most outlandishly
neckbeardy things devs can do in a shell. Most users don't want to deal with
that sort of "layering".

~~~
chriswarbo
> Your setup sounds like a parody of the most outlandishly neckbeardy things
> devs can do in a shell.

I shaved off my neckbeard, I'll have you know! ;)

My setup's no more outlandish than using tmux or screen, except instead of
typing `tmux` or `screen` I type `shell`, which aliases a `dtach dvtm` one-
liner (with a few options sprinkled around, so I don't have to bother with
config files).

The point is that none of these applications care if/how they're composed; if
I want to add in or swap out something, it's just a change that one-liner.

Not so if, say, my terminal application were hard-coded to rely on tmux, as
some sibling comments have suggested.

------
jwilm
I'm the author of Alacritty, and I'm here to answer any questions!

~~~
h4nkoslo
Cool project, but I have literally never thought a terminal was excessively
low-performing enough to prevent work from getting done. What applications
benefit from a terminal that's even an order of magnitude faster than the
alternative?

~~~
jwilm
Terminal performance is fine at smaller sizes and with less going on.

In a multi-pane tmux window with vim, performance issues start to become
noticeable. Many people I've talked to have experienced a situation where a
bunch of output is being written to the screen, they panic to hit C-c, and
then all you can do is wait for it to finish. This just isn't an issue with
Alacritty.

Alacritty is about having tools that don't get in your way and don't distract
you from what you're trying to accomplish.

~~~
ericbb
With the C-c issue specifically, I don't think that emulator throughput is the
most likely culprit.

It could be that the emulator is not handling inputs fairly: maybe it tries to
process all available input from the pseudoterminal before processing the next
batch of keyboard input. Or it could be that the pseudoterminal (kernel
driver) is not configured to send the signal as expected. Or it could be that
the process you're trying to interrupt is not responsive to the signal.

I maintain a terminal emulator that is not optimized at all and I just tested
interrupting a process that was dumping one gigabyte of text to the screen.
The interrupt was handled instantaneously.

~~~
JdeBP
It isn't the most likely culprit. The mosh people point out that the place
where people hit this is with a SSH session to another machine. Where the data
are actually building up is the SSH connection. It's not a problem with the
terminal emulators at all.

------
skybrian
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?

On the other hand, something like mosh [1] seems like it could be really
useful on slow network connections. But that's not about _rendering_ faster.

[1] [https://mosh.org/](https://mosh.org/)

~~~
mrob
Not all people are equally sensitive to graphical performance issues. The
default Ubuntu terminal is capped at approximately 40fps[1]. This is
deliberate and hard-coded. It's not an integer multiple of any common screen
refresh rate and it looks very bad. There is no way to configure keyboard
autorepeat so new input is shown with consistent timing. I consider this bad
design and I'm happy that Alacritty is limited only by the monitor. But some
people might never notice the timing problems in other terminals.

[1]
[https://github.com/GNOME/vte/blob/b517d20379c7a665e897f925ca...](https://github.com/GNOME/vte/blob/b517d20379c7a665e897f925ca3ecb7b778364f2/src/vte.cc)
line 10685

~~~
jstimpfle
keyboard autorepeat doesn't have anything to do with the terminal emulator (or
I would be surprised). There's an X11 setting, try "xset r rate <delay-ms>
<repetitions-per-sec>", e.g. "xset r rate 170 30".

~~~
mrob
The timing of the input itself doesn't vary, but the timing of the visual
feedback does. I like a fast 60Hz autorepeat, and I rely on visual feedback
for precise positioning (I find this has lower cognitive load than Vim style
character/word/line/etc counting). If the terminal is displaying at 40fps then
some separate inputs will be merged and displayed at the same time. And if you
like 30Hz autorepeat, instead of consistent 2 frames per input, you get a
mixture of 1 to 3 frames per input depending on how the cycles line up. It
makes it much harder to hit the exact character you want if you're using
autorepeat for navigation.

Ideally the terminal should have MPV-style motion interpolation for supporting
keyboard repeat rates that aren't an integer multiple of the display's refresh
rate.

~~~
saghm
> I like a fast 60Hz autorepeat, and I rely on visual feedback for precise
> positioning (I find this has lower cognitive load than Vim style
> character/word/line/etc counting).

I thought I was the only one who turned the key repeat way up and then
navigated things by moving one line/character at a time _really fast_! I've
always felt a bit guilty about this due to feeling like I'm just too lazy to
get used to using more typical navigation, but "preferring lower cognitive
load" sounds like a more more positive spin on it.

~~~
rsync
I have slowly, over the course of _20 years_ moved to holding down movement
keys to trying (and not always succeeding) to remember to use forward and
backward search to jump around to the string I am moving to.

I think it's the "right thing to do" but it's hard to not just hold down 'k'
...

------
llimllib
> Make sure you have the right Rust compiler installed. Alacritty is currently
> pinned to a certain Rust nightly

Ok, I'll... um not do that. Hope you publish a build soon though!

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.

edit 2: I'm really sorry if I derailed the conversation in a not useful way,
@jwilm

~~~
steveklabnik
Looking at the code, it looks like this basically only relies on two things:
inclusive ranges, and clippy. But you don't have to use clippy this way; it's
just one way of doing it. So it's really one feature. EDIT: Oh oops, and
custom derive, which is stable in a month.

> I really hope they're able to stabilize it

In general, "nightly" is never going to be stabilized. Remember, it's how Rust
development works. Some people will always want to be on the cutting edge. I
elaborated here:
[https://news.ycombinator.com/item?id=13277438](https://news.ycombinator.com/item?id=13277438)

Also, nightly-only is less of a deal here, since this is mostly an
application, not a library. End-users won't need to worry about having Rust at
all.

~~~
llimllib
My feeling is that having a lot of people running on different rust versions
is likely to raise the bar to contribute to the project; for example if I go
to hack on a python project the odds that I have to change my interpreter
setup are basically zero.

In this specific example, I saw that building the project required mucking
with my rust version/setup and decided that the cost of that was too high for
me to proceed. Totally possible that I mis-evaluated the cost, but that was
what happened in my head.

I don't at all mean to tell you what is best, I do think highly of your
project and wish you all the success.

~~~
dbaupp
It is a little unfortunate, but Rust isn't blind to the problem. The community
is converging on everyone using rustup (e.g. as of a few weeks ago, the
install page recommends it [https://www.rust-lang.org/en-
US/install.html](https://www.rust-lang.org/en-US/install.html) ) because it
makes managing things like cross compilation[0] and upgrading stable compilers
much easier. It also makes working with pinned compiler versions smoother: run
`rustup override set nightly-2017-01-05` (or whatever date is recommended) in
the project's directory, and that single command will both install that
compiler and ensure it is used for the project (and only that project) when
one invokes cargo or rustc. (I think it's great that Alacritty even helps
people with the process, as I guess you noticed:
[https://github.com/jwilm/alacritty#prerequisites](https://github.com/jwilm/alacritty#prerequisites)
)

In any case, the nightly split is Rust deciding that it is good to allow
people to use experimental features (i.e. working out if they're good/bug
free) while also resisting infecting code that doesn't want to risk breakage
---such projects use a stable compiler meaning even their dependencies won't
be able to accidentally rely on something unstable---and thus hopefully
avoiding defacto stabilisation of low quality features.

[0]: [https://blog.rust-lang.org/2016/05/13/rustup.html](https://blog.rust-
lang.org/2016/05/13/rustup.html)

~~~
uep
While it's nice that they want to converge on rustup, I greatly prefer using
my distro-provided compiler in almost all cases. Right now that is rustc 1.14,
which means that that alacritty is currently beyond my compilation capability.

I don't think this is nearly as bad as the grandparent suggested though. The
language is young, I'd prefer experimental features remain in the experimental
branch rather than get bad design stuck in the language.

I think if you're doing dev, it's completely reasonable to expect the dev to
install a newer toolchain. Cargo makes all of the actually painful parts of
contributing to a project pretty trivial.

~~~
computerphage
Don't worry. The Rust community is sensitive to the desire to only install
Rust with a package manager. There was even talk (a few days ago) of making an
LTS version of the Rust compiler for use in more conservative distros that
don't want to update it every 6 weeks.

On another front, Rust is working hard to get people off of nightly. This
project, for example, uses 3 unstable features. Clippy can already work on
stable (edit: code that is linted with Clippy can also build on stable in some
setups), Custom Derive will be stable in less than a month, and inclusive
ranges is a pretty minor feature.

I would expect this project to begin working on stable for Rust 1.15, but I'm
not affiliated with it directly, that's just my guess.

~~~
Manishearth
> Clippy can already work on stable

No. But we plan to make it work.

~~~
computerphage
Sorry Manish, I had meant that you can have code that can be built using a
stable compiler while still using Clippy via another means. I typically use
stable, but I run clippy on my code anyway. I realize that my post is
confusing, I'll edit.

~~~
Manishearth
Ah, thanks!

------
cyberpunk
Jwilm: This is great, and I'm really looking forward to following this
project; beers on me and thanks for the effort!

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).

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..

2) I had to set offsets and use a giant font to make it look reasonable on my
(highdpi) lappy:

font:

    
    
      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
    

Otherwise:

+100 :}

~~~
jwilm
2\. I don't have easy access to the high DPI scale factor, so it needs to be
configured manually for now :(.

    
    
         dpi:
             x: 144.0
             y: 144.0
    

1\. That doesn't sound good! Would you mind filing an issue?

~~~
cyberpunk
Sure I will do when I get a moment :}

One other feature that's a killer for me is being able to change the font size
while running -- ctrl++/-.

~~~
jwilm
I've heard that a few times now. For what it's worth, that's in the works!

------
Asooka
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: [http://wdobbie.com/post/gpu-text-rendering-with-
vector-textu...](http://wdobbie.com/post/gpu-text-rendering-with-vector-
textures/) . 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.

~~~
pcwalton
That will lose by a lot overall. Hit rates on the glyph cache are massive.

------
coldtea
> _tabs and scrollback are unnecessary. The latter features are better
> provided by a terminal multiplexer like tmux._

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.

I'd understand it if some more advanced or exotic feature wasn't available,
but scrolling?

------
shmerl
A pity you can't use Vulkan on MacOS. Otherwise you could have used vulkano[1]
instead of OpenGL.

1\. [https://github.com/tomaka/vulkano](https://github.com/tomaka/vulkano)

~~~
jwilm
Even so, I do plan to add a Vulkan renderer at some point using vulkano. My
hope is that the build script can choose the best option at compile time.

------
Anilm3
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:

At 80x24:

gnome-terminal:

    
    
      real	0m0.848s
      user	0m0.032s
      sys	0m0.072s
    

Alacritty:

    
    
      real	0m6.832s
      user	0m0.032s
      sys	0m0.164s
    

At fullscreen:

gnome-terminal:

    
    
      real	0m0.819s
      user	0m0.020s
      sys	0m0.088s
    

Alacritty:

    
    
      real	0m8.972s
      user	0m0.064s
      sys	0m0.164s
    

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.

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.

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.

~~~
jwilm
There's a known bug when using Mesa that kills performance. Hopefully we'll
get it resolved soon!

------
garaetjjte
Nice, but:

    
    
        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
    

or

    
    
        thread 'pty reader' panicked at 'cursor fell off grid', src/term/mod.rs:634

------
lngnmn
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.

What a decent terminal emulator should have is standard compliance and decent
font rendering (and freetype is good-enough).

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 _not_ an engineering.

~~~
mmstick
Everything that can be GPU-accelerated should be GPU-accelerated. The GPU is
far more energy efficient, and every bit of offload onto the GPU leads to a
decrease in CPU consumption. Terminals can be particularly CPU-heavy when
running a chatty program.

~~~
lngnmn
I hope systemd guys will read this.

------
ggame
I'd like to host this terminal in a 3D environment. Any plans to enable this?
Perhaps with a signed distance field texture.

I'm building a 3D game in Rust and would like to be able to drop this in.

~~~
elcritch
Oh, just as interesting, plugging this into VR system! Make it way easier to
multitask and work on lots of systems (at the risk of looking incredibly
goofy).

~~~
ggame
Sadly VR is useless for reading :( I wish it wasn't so. You're much better off
with a high resolution screen with the ability to zoom in and out between
landmarks. Maybe a head tracker to make navigation more intuitive.

~~~
eduren
Hopefully that changes with the next bump in pixel density. Aggressive
supersampling already is getting close to readable.

~~~
ggame
I wouldn't hold my breath. Maybe for causal reading but not for day in day out
8 hours a day. It's also solving the wrong problem when it comes to immersion.
I fly FPV which is a fuzzy intermittent analog 640x480 screen and it's
incredibly immersive. People are fully immersed into their tiny mobile phone
screens for a large portion of their day. AR peaked with Pokemon Go and we
didn't even need Google Glass, Magic Leap or HoloLens. We already have the
hardware for full immersion and it's sitting right in front of you (or in your
hand).

------
richdougherty
> 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!

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.

~~~
ycmbntrthrwaway
Rust has macros so any sort of tables can be rolled out into more efficient
code, like if you wrote switch-case in C. It should be possible to rewrite
vt_state_table! once later, when it becomes a problem.

------
Arubis
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.

But...the font rendering doesn't look as good as iTerm's, at least not yet.

I suspect I'll be swapping once you're at a public build release.

~~~
MaxLeiter
I'd swap to Alacrity if it supported multiple tabs or buffers like iTerm2

------
epberry
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.

EDIT: Ah, after a little sleuthing, the recent post from OneSignal on why they
chose rust for one of their services makes sense :).

~~~
rhaps0dy
This reads like it should go in a grad school statement of purpose :)

------
sigi45
Less repeating that it is fast and more benchmarks instead!

~~~
stuckagain
Seriously. ^^^

How fast is it? I haven't had a terminal that was as fast as xterm with a
matrox millenium ii. That was 20 years ago which is pretty sad. Of course the
terminals look better these days.

~~~
chadcmulligan
yah, 9600 baud is as fast as I need my terminal to go. 19.2K is just crazy.

~~~
stuckagain
That's not what I said. What I said was that terminal was unbelievably fast.
Especially for backwards scrolling which is an important use case to me.

~~~
chadcmulligan
I was just having a little joke, apologies if it came off as a criticism. It
seems very strange to me that people are still talking about speeds of
terminals, but not my field (any more) fortunately.

One of the first things I wrote was a terminal emulator using telnet to run on
PC-DOS using a port of curses to connect to our Sun 3's. To think in 2017
people are still concerned about terminals is very surprising to me.

~~~
stuckagain
The problem is the terminals have been getting monotonically slower over the
last 20 years, whereas the amount of build spew I need to grope around in to
find the relevant error has not decreased :-/

~~~
chadcmulligan
yeah, I use ide's (Xcode/Appcode/VS/Delphi) for all my work so not really an
issue. I can see if you're stuck with command line compilers though it would
be annoying. I would hate to go back to make files and command lines ugh!

~~~
Zardoz84
So you are missing a wonderful world of powerful tools because you not like
terminals.

~~~
chadcmulligan
I would argue the reverse :-). I've used terminals in the past, had the beauty
that is screen, even gave courses on vi. When bitmapped screens became
available it was ide's for me.

------
010a
Installation was surprisingly easy.

And performance was surprisingly good. `find /Applications` results in...

\- Unrecoverably crashing Hyper \- 1:28 iTerm2 \- 0:32 Terminal \- 0:20
Alacritty

Very impressive stuff. I'll be keeping an eye on this project.

And performance was surprisingly good; a `find /Applications` on my computer
crashes Hyper, takes 1:28 on iTerm2,

~~~
GolDDranks
What the heck!? I never knew terminal emulators themselves were such
bottlenecks! The more you know...

I tried this too. `$ find /Applications` iTerm2 - 0:26 Alacritty - 0:12

------
xedrac
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.

------
botverse
Like 58% faster than iTerm2 in my Late 2013 MBP retina.

    
    
      find ~
      iTerm2    1m20s
      alacritty 47s
      

where the find command itself uses between 40% and 50% of a core, the TERM
emulator process uses is 5x in iTerm2

    
    
      iTerm    130% (peak up to 140%)
      alacritty 25% (peak up to 29%)
    

I'm very excited with this and I'm going to follow the development of
alacritty :)

------
ejp
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.

The lack of scrollback/tabs/etc doesn't bother me at all - I use tmux for this
exactly as suggested.

Thank you for this!

------
anoother
Very interesting use of vsync.. using it to cap redraw time and allow more
time for processing...

------
__ddd__
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.

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.

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.

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_

~~~
jwilm
I'm happy to hear you're enjoying it!

> concerning the the Alacritty devs since Alacritty requires a multiplexer to
> be usable

The project initially started to be an optimized tmux renderer. It's not
supposed to appeal to everybody. That said, there's a big segment of users
with tiling window managers that are only blocked by not having scrollback,
and we're talking about adding it. Features like tabs/splits will likely never
be introduced.

> If I can find a workaround to the remote paste issue

What platform are you on that the selection copy and mouse paste isn't
working? It's also possible to configure this to another keybinding if you
prefer.

~~~
__ddd__
I'm using Mint Mate (Sarah), can't get a context menu on right click. I
installed all of the dependencies mentioned in the readme, though maybe Mint
requires something that Ubuntu doesn't. Tmux mouse support works,
interestingly enough.

> Features like tabs/splits will likely never be introduced.

I wholeheartedly support this. Count me among those that like the idea of an
"optimized tmux renderer".

~~~
__ddd__
edit: I just realized you weren't referring to a context menu, but
select/middle-click. Duh, didn't even think to try that as I don't really use
that feature much. That'll do the trick for now, though apparently they plan
to remove this feature from the next gnome release? Seems odd to me --
Anyways, thanks for the suggestion, now I can use alacritty for remote
sessions!

------
Philipp__
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)

------
dvcrn
As a tmux+vim user, this hits right home for me. I never use terminal tabs and
do almost everything inside tmux.

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!

I'm going to try this as my main tool for a couple of days and collect some
feedback :)

------
callumprentice
[https://github.com/unconed/TermKit](https://github.com/unconed/TermKit) or
[https://acko.net/blog/on-termkit/](https://acko.net/blog/on-termkit/)

TermKit is another terminal app from 2011 designed to modernize the command
line experience.

Sadly, I don't think it's being worked on anymore.

------
dorianm
Also, Cathode is a terminal made with OpenGl and it's really fast:
[https://www.jwz.org/blog/2011/01/cathode-vintage-terminal-
em...](https://www.jwz.org/blog/2011/01/cathode-vintage-terminal-emulator/)

~~~
rukittenme
That link redirects to imgur for me.

edit: or it did but now its going to the website.

~~~
timlyo
Copy and paste it in. For some reason the owner redirects traffic from hacker
news.

------
sakabaro
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.

------
koyote
Having never thought my current terminal emulator was slow I was surprised to
immediately see a difference with Alacritty!

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

I guess we're not quite at 1.0 yet but looking good otherwise!

------
malensek
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.

Nice work. Hopefully this can fill a particular void for folks that want no-
frills fast terminal emulation.

~~~
SloopJon
I can't remember the last time I thought that my terminal was too slow, except
maybe when I tried that Electron-based program a while back (Hyper, I think it
was). My priorities are more like the following:

1\. Stability. I crashed Alacritty thirty seconds after opening it; possibly
related to issue #12.

2\. Emulation correctness. In Terminal.app, the cursor often gets out of sync
when I "turn the corner" (i.e., backspace across a line boundary).

3\. Font rendering. Text in some terminals just looks ugly.

4\. Features. Alacritty doesn't seem to show the number of rows and columns
when I resize. Scrollback!

This looks like a really interesting project, but it seems really strange to
make performance such a high priority. I tried the find /usr test, and it
seemed equally fast in Terminal.app and Alacritty.

------
readittwice
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.

~~~
buzzybee
I learned this stuff a long while ago, but I found a promising textbook for
you to review [0]

tldr; the "easy 80%" of the effort in GPU rendering, specifically, is
reformatting graphics data in forms that the GPU prefers. (The "hard 20%" is
dealing with confusing APIs, broken implementations, etc.) Graphics techniques
themselves may apply various mathematics(geometry, trigonometry, a little bit
of linear algebra, DSP), either on the CPU or GPU. To render things you make
decisions about the processing and output format and write data and algorithms
accordingly.

[0] [http://math.hws.edu/graphicsbook/](http://math.hws.edu/graphicsbook/)

------
GrinningFool
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.

------
fvargas
> Welcome to nginx!

> If you see this page, the nginx web server is successfully installed and
> working. Further configuration is required.

On jwilm.io -- Just wanted to let you know

~~~
jwilm
Should probably redirect that to the blog; thanks for the notice!

------
uvesten
Wow. I just installed this on macOS, and the difference in speed compared to
iTerm 3 is huge!

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.

After some color bugs have been ironed out I'll switch full-time.

------
hl5
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.

~~~
guilloche
I thought alacrity was faster. If not, I will still use st. But alacrity can
still become a GUI terminal later and will have some usage for me.

------
greenspot
Excited and happy to see such a project!

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.

Wondering how Alacritty will perform, looking forward.

------
vectorpush
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.

------
conradk
Not sure why they rebuilt a clipboard library when "clipboard" exists (I think
it might even be used within Servo, not sure):
[https://crates.io/crates/clipboard](https://crates.io/crates/clipboard)

~~~
steveklabnik
> A non-GPL licensed cross-platform clipboard library,

(That is, that project is GPL licensed, and they didn't want that)

~~~
conradk
Oh, I thought "clipboard" was dual licensed to GPL and/or Apache 2.0. My bad.
I hadn't seen that the x11 related code was purely GPL 2.0.

Thanks for your help, Steve !

~~~
steveklabnik
No worries! :)

------
rocky1138
Why OpenGL instead of Vulkan since that's where everything seems to be going
these days.

~~~
jwilm
Vulkan is not yet supported on macOS. There are plans for a Vulkan renderer,
but cross-platform support will come first.

------
nitemice
A relevant Destroy All Software talk:
[https://www.destroyallsoftware.com/talks/a-whole-new-
world](https://www.destroyallsoftware.com/talks/a-whole-new-world)

------
davesque
I added support for Alacritty in my iTerm color scheme conversion tool:

[https://github.com/davesque/iterm_convert](https://github.com/davesque/iterm_convert)

------
psheets
Does this support crossfire?

------
aoeu345
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.

Thanks!

------
Gonzih
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.

------
anthk
[http://www.bbspot.com/News/2003/02/ati_ascii.html](http://www.bbspot.com/News/2003/02/ati_ascii.html)

Seriously.

------
simlevesque
It really is the fastest one I ever used. Font rendering is great.

------
d_kol
Impressive! I run [https://github.com/slash-
hq/slash](https://github.com/slash-hq/slash) and it just works.

------
gigatexal
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

------
ninjakeyboard
Cool project for learning and exploration and congrats on making a fast term.
I'm not sure that this solves a problem that I have personally.

------
Bromskloss
> Using vim inside tmux in many terminals was a particularly bad experience.
> None of them were ever quite fast enough.

When does this slowness show itself?

~~~
aoeu345
If you have four large files open in Vim tabs, it can be quite slow.

If you print out a large text file or script output with cat or less, it can
be slow as well. This is on a 1.8ghz i5 machine running Linux.

I can already notice the speed of Alacritty. We'll see how it performs in the
next few months for me.

~~~
Bromskloss
< If you have four large files open in Vim tabs, it can be quite slow.

Is this at all dependent on the terminal emulator?

------
sdegutis
How much unsafe code was needed to make this work?

~~~
jwilm
As Steve mentioned, it was mostly for ffi. There's also a few places where I'm
doing my own bounds checking in order to provide nicer error messages. After
doing the bounds checking, doing an index operation without the standard
library's bounds checking requires unsafe.

~~~
steveklabnik
Couldn't you use get instead of [] for this?

Maybe I'll look into it and send a PR :)

~~~
jwilm
That seems completely reasonable. Not sure why I didn't consider it. PRs
welcome :D

~~~
steveklabnik
I figured out why: because there are two of them, it's a little awkward... I
might have a PR for you, we'll see :)

------
jxy
Buzzwords aside, why do we need GPU-accelerated terminal emulators? What is
the real speed constraint in a terminal emulator?

------
dvt
Pretty awesome, but I'm not sure if I want my GPU fans spinning if all I'm
doing is looking at a terminal :P

~~~
jwilm
The amount of time spent doing GPU work is rather small. Battery life tends to
be better on my Macbook with Alacritty than with other terminals. This seems
to suggest that power consumption is actually less than with CPU based
renderers (and that your GPU fans shouldn't be spinning).

~~~
dvt
I didn't realize there's no Windows version available yet, I was totally
thinking about my Windows laptop. My Apple (work) laptop is much better about
not turning on fans willy-nilly.

~~~
dualogy
Not necessarily due to "your Windows laptop", sometimes it's due to
hidden/forgotten vendor bloatware and Windows' very own background services.
That is, due to shabby software, not your laptop. I disabled Windows Update
(rather check it manually every other month) and went through the list of
services that'll realistically never be used even indirectly to disable and
voila, no more random fan spinning! Until I open a WebGL page or something
that is.. that "3D JS" will heat up even a current mobile workstation with a
3GB-VRAM Quadro GPU!

------
steeve
I love iTerm3, but the speed compared to Terminal.app sometimes makes me
jealous.

So I guess we all need a faster term emulator :)

~~~
eridius
Out of curiosity, why do you love iTerm? It's always struck me as kind of ugly
(especially its preferences). And AFAIK, the only real feature it has that
Terminal.app doesn't (besides the native tmux integration, because I still
don't really see the point) is support for apps customizing the 256-color
palette on the fly (e.g. the initc capability), and wile I really would like
to see Terminal.app gain support for that seeing as how the xterm-256color
terminfo it uses declares that it works, lack of support for that isn't a good
enough reason to switch away.

~~~
fiddlerwoaroof
The coolest feature of recent versions of iTerm is the "Selection respects
soft boundaries" feature: with it on, iTerm will detect vim/tmux splits and
constrain the selection to just one side of that split. For my workflow, at
least, it makes a huge difference.

Also, if you start tmux as "tmux -CC" iTerm will open the tmux session in a
new window, with GUI tabs for tmux tabs and GUI splits for tmux splits.

~~~
eridius
That selection thing sounds kind of interesting, though tbh I almost never use
vertical splits in the Terminal. The only place I do is in MacVim.

------
yeasayer
In terms of speed, Alacritty to Hyper is like Sublime to Atom?

~~~
brianm
Vim to Atom

~~~
red2awn
More like butterfly to Atom

~~~
wsxarcher
More like xi-editor to Atom

~~~
red2awn
Oh man I really like what Xi editor is doing! Too bad it only have offical
support for OSX right now...

------
sssilver
How do they define performance, and how do they measure it?

~~~
xorxornop
FPS or more strictly, DUPS (display updates per second), as a function of
resource use - that is, what pushes the most text, the fastest, with the most
displayed frames (sent to actual display/monitor) corresponding to discrete
states of display output (v vis-à-vis the terminal), per second?

Some terminals bottleneck standard out ️ display , some hardcode the display
rate

------
elventear
cat /dev/random on macOS Sierra crashes for me.

------
DavideNL
heh just fyi, my F-secure reports:

"Harmful web site blocked. blog.jwilm.io

This web site has been reported as harmful. We recommend that you do not visit
this web site."

------
Aissen
So, like terminology, but with less features ?

------
rafinha
Why does one need 500fps on terminal ? I don't understand the need for the
GPU.

~~~
mrob
A real 500fps terminal (with 500Hz display) would be nice, because timing
jitter would be very low no matter what keyboard autorepeat rate you used.
Autorepeat would appear smooth even when the frame rate isn't an integer
multiple of the repeat rate. Although in practice something like 120fps is
probably sufficient if used with MPV-style motion interpolation.

------
0x445442
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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

------
plg
iOS version?

------
scott_s
This could definitely be tagged as a Show HN
([https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)).

~~~
sctb
Thanks, we've updated the title.

------
jackmott
Awww hell yeah.

------
teen
Wex wex exort!

------
jbverschoor
Very cool.

~~~
jwilm
Thanks!

