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

131–140 of 491 posts

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

#131

Post by ggame »

eduren wrote: post #106
ggame wrote: post #84

Earlier quoted context omitted.

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.

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

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

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

#132

Post by a_humean »

llimllib wrote: post #35

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

Rustup automates this process so much that it costs you nothing to compile from a specific nightly release without compromising your existing configuration.

I downloaded the nightly within a minute, and I compiled a release within 125 seconds. Immediately after I changed back to stable. It took two cli commands to swap between. NPM couldn't get all my packages for my React crud app that quickly.

One thing that Rust really seems to be doing right is tooling whether it be Cargo's package and compilation management or Rustup's toolchain management, and their 2017 roadmap is pretty much entirely about tooling: https://github.com/rust-lang/rfcs/blob/master/text/1774-road...

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

#133

Post by sanderjd »

loeg wrote: post #93
sanderjd wrote: post #38

Earlier quoted context omitted.

Interesting - maybe this (or someone else) could skip the middle-man and just be a cross-platform tmux gui, instead of a terminal emulator.

Not really. After all, the applications inside tmux are ordinary terminal programs that need terminal emulation.

That makes so much sense that I now feel really silly about my suggestion :) Thanks for setting me straight!

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

#134

Post by vmarsy »

jwilm wrote: post #2

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

This looks like an awesome project! You mention tmux, what about GNU Screen? does it work as well?

I don't remember major perf issues using vim within screen, I'm afraid to use Alacritty and then never be able to come back to my past setup :)

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

#135

Post by nxrabl »

Bedon292 wrote: post #55
jwilm wrote: post #2

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

Might be a bit early, but will the Windows support be good for Bash on Ubuntu on Windows? Right now I use xming and run xterm inside it, but that is not a perfect solution, especially for things like vim. It works for now, but I am definitely looking for a good alternative.

Per [0], it looks as though only Bash on Ubuntu on Windows is being targeted, and not CMD or Powershell.

[0] https://github.com/jwilm/alacritty/issues/28

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

#136

Post by atombender »

WhatIsDukkha wrote: post #95

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…

> 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

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

#137

Post by rhelmer »

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…

> for example if I go to hack on a python project the odds that I have to change my interpreter setup are basically zero.

This doesn't match my experience at all - I frequently switch between projects that require python2 or python3, and I manage that using virtualenvs, which is a different problem than setup.py solves, just as rustup is separate from Cargo.toml

I have a lot of python experience and only a little bit of rust, but in my opinion the years-long python 2/3 split has been a lot more painful than the rust nightly/stable split... the fact that Rust produces binaries that work in any case vs. the user needing the right Python interpreter installed is a big part of this.

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

#138

Post by mistaken »

jwilm wrote: post #2

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

cool project, but my question is why? rxvt is plenty fast for general purposes. if your bottleneck is the terminal emulator then you're doing something wrong. can you really read at ~10mbps?

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

#139

Post by uep »

dbaupp wrote: post #77
llimllib wrote: post #65

Earlier quoted context omitted.

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

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.

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

#140

Post by adelarsq »

jwilm wrote: post #60
ekidd wrote: post #46

Earlier quoted context omitted.

I just wanted to say that this looks like a fantastic and very cool project! Congratulations on the speed. Personally, the lack of scrollback and tabs is a dealbreaker for me. I know that I'm supposed to use tmux for that, but I can never remember how tmux scrollback and tab switching work without thinking about them. Plus I rely heavily on mouse selection of multi-screen text in the scrollback buffer. So I'm unlikel…

> Personally, the lack of scrollback and tabs is a dealbreaker for me Completely understandable. This decision was expected to be polarizing. > Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux. Not yet. Fallback fonts, wide chars, and a number of other font rendering items are part of the 1.0 milestone.

> Not yet. Fallback fonts, wide chars, and a number of other font rendering items are part of the 1.0 milestone.

This will be available also on Windows?

Post reply on HN