Live data from Hacker News

Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

blog.jwilm.io

141–150 of 491 posts

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#141

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…

Yup, I'd consider MacOS Terminal to be minimal. Anything less than that I just wouldn't use.

Anything with more features I probably wouldn't use, either.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#142
post #80

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 boun…

Another Rust terminal emulator project, notty[1], aims to do this. Downthread the author mentions that the projects are looking at collaborating. [1]: https://github.com/withoutboats/notty

It's too bad notty is licenced under the AGPL. That basically guarantees 0 usage at any sort of bigco.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#143
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!

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#144
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

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#145

Earlier quoted context omitted.

You do seem overly excited. :) Your last paragraph suggests what you really want is a notebook style interface (in the style of mathematica) rather than a terminal.

> You do seem overly excited. :) Hah, yeah I'm aware, but the potential of Rust is huge. We talk a lot about open source these days, but meanwhile the tools that we all use are sitting on huge substrates that the vast majority of us aren't contributing to and probably never will due to the complexity hurdle that needs to be overcome. This includes our web browsers, our terminals, our editors/IDEs, our operating syste…

Isnt most of your points just the relative newness of rust?

I could rewind a few years, replace [rust] with other platforms like [node] or [erlang] and the same statements apply.

I'm not disagreeing with you, I'm just pointing out that it seems to be the stage an a natural progression of platforms.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#146

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…

I never managed to actually like tmux. It breaks too much of what I'm used to, like mouse wheel scrolling, Ctrl-arrows, ESC in Vim and a lot of other small things.

The ESC thing is fixable by configuration, at least, but I really doubt I can make tmux behave like my native terminal.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#147

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

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

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#148
post #3
post #2

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

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?

It's more of a user comfort / perception thing. Using a slow terminal is basically like playing a game with really inconsistent frame rates. It's a distraction and can cause you to make mistakes from mistimed inputs. In both cases what you're really looking for is consistency more than raw speed.

Re: Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

#149

Earlier quoted context omitted.

> You do seem overly excited. :) Hah, yeah I'm aware, but the potential of Rust is huge. We talk a lot about open source these days, but meanwhile the tools that we all use are sitting on huge substrates that the vast majority of us aren't contributing to and probably never will due to the complexity hurdle that needs to be overcome. This includes our web browsers, our terminals, our editors/IDEs, our operating syste…

Isnt most of your points just the relative newness of rust? I could rewind a few years, replace [rust] with other platforms like [node] or [erlang] and the same statements apply. I'm not disagreeing with you, I'm just pointing out that it seems to be the stage an a natural progression of platforms.

The difference there is that Rust is directly targeting the ecosystem where this C and C++ stuff is being written; Node or Erlang never were.
Post reply on HN