Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.jwilm.io

Post reply on HN
Print view View original

71–80 of 491 posts

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

#71

Post by pera »

jwilm wrote: post #2

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

Hey, nice project :) I do have a question: you mentioned that urxvt is difficult to configure (because of .Xresources format?), but then you also say that "GUI-based configuration is unnecessary", so how exactly is Alacritty easier than urxvt?

One feature that I really miss in rxvt is an easy/fast way to change the color scheme, or at least reverse colors (like with xterm, which if correctly configured it's just ~3 times slower than urxvt). This is something really important when your screen receives direct sunlight.

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

#73

Post by ycmbntrthrwaway »

Florin_Andrei wrote: post #25
jwilm wrote: post #2

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

> and scrollback are unnecessary Um... that's kind of a deal breaker to me. Really no scrollback at all?

I guess the idea of no scrollback is taken from st [0].

[0] http://st.suckless.org/

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

#74

Post by corysama »

elcritch wrote: post #66
ggame wrote: post #59

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.

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

https://www.reddit.com/r/HMDprogramming/ is all about stuff like that. Not much traffic there, though...

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

#76

Post by steveklabnik »

Paul-ish wrote: post #67
kbenson wrote: post #48

Earlier quoted context omitted.

Using nightly for a single build and going back to stable for regular work is not hard. It's a command or two to build and switch, and a command to switch back. Using nightly rust to build a project in development to check it out is like using a beta release of a library to build a project to check it out. In both cases, you expect that it will likely be using stable dependencies in the future, and you can still take…

It seems like the Cargo.toml file for binaries should be able to specify this, and cause the crate to be built with the nightly if it is installed. This way you only have to enter cargo build --release.

Cargo isn't in charge of selecting what rustc you use; that's the job of Rustup.

In general, _some_ feature like this is desired; nobody has put in the required work yet.

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

#77

Post by dbaupp »

llimllib wrote: post #65
steveklabnik wrote: post #53

Earlier quoted context omitted.

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

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…

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

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

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

#78

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

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

#79

Post by zie »

eridius wrote: post #62
steeve wrote: post #4

I love iTerm3, but the speed compared to Terminal.app sometimes makes me jealous. So I guess we all need a faster term emulator :)

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

iTerm has https://github.com/ravenac95/sudolikeaboss. Integration of your 1Password passwords with your terminal, which makes life amazing. Typing and copy/pasting passwords(not to mention copy/paste is not exactly secure) is a major time-suck. I'd love generic support for this feature in something like Alacritty.

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

#80

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

Post reply on HN