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

Warp: Fast, Rust-based terminal (waiting list)

warp.dev

Post reply on HN
Print view View original

71–80 of 181 posts

Re: Warp: Fast, Rust-based terminal (waiting list)

#71

Post by OJFord »

PragmaticPulp wrote: post #21

FYI, this appears to be a startup launching an e-mail signup for a product that isn't available yet. Nothing wrong with that, of course, but it's worth noting up front. There is no download link and the GitHub link goes to an issues-only repo with no code. There are several fast Rust-based, GPU-accelerated terminal projects that are open source and under active development: Alacritty: https://github.com/alacritty/ala…

> There is another fast Rust-based, GPU-accelerated terminal project that is open source and under active development:

I really thought 'Alacritty' came next! It's cool there are a few. If someone's looking for something popular and robust though, and not specifically interested in the cloud features of OP, Alacritty is pretty mature, actively developed, and also rust if you care.

Re: Warp: Fast, Rust-based terminal (waiting list)

#73

Post by kaetemi »

zachlloyd wrote: post #41
donio wrote: post #27

Who cares that it's Rust if it's closed source? Also: "All cloud features are opt-in. Data is encrypted at rest." The fact that this even needs to be stated makes it a hard no, especially for a terminal emulator.

Our plan is to open source the Rust client code once it's more mature. We are particularly excited about sharing our Rust UI framework since there aren't a lot of great options for building native UIs in Rust right now. We want to make it cross-platform first though.

Why not just develop out in the open from the start, instead of dangling an open source carrot? You might even get community contributions.

Re: Warp: Fast, Rust-based terminal (waiting list)

#74

Post by petepete »

nanis wrote: post #50
PragmaticPulp wrote: post #21

FYI, this appears to be a startup launching an e-mail signup for a product that isn't available yet. Nothing wrong with that, of course, but it's worth noting up front. There is no download link and the GitHub link goes to an issues-only repo with no code. There are several fast Rust-based, GPU-accelerated terminal projects that are open source and under active development: Alacritty: https://github.com/alacritty/ala…

Just tried it: 2021-07-14T17:05:56.423Z WARN window::os::windows::window > EGL init failed with_egl_lib failed: with_egl_lib(libEGL.dll) failed: no compatible EGL configuration was found, atioglxx.dll: LoadLibraryExW failed, fall back to WGL 2021-07-14T17:05:56.500Z ERROR wezterm_gui::frontend > Failed to create window: The OpenGL implementation is too old to work with glium I feel sad when terminals need OpenGL ...…

On the flip side, if you do have OpenGL, why not utilise it for unparalleled terminal performance? I've used Kitty for years for that reason, it's incredibly responsive and smooth, a pleasure to use.

Re: Warp: Fast, Rust-based terminal (waiting list)

#75

Post by akira2501 »

rhacker wrote: post #54
barbazoo wrote: post #22

Somehow it feels odd that an implementation detail like the programming language it's implemented in is so prominent in the project's description. I have no idea what bash is written in and frankly I don't care much about it. It's a tool that enables me do be more productive. Could it be faster? Probably, but does anyone even notice that in the context of all the other things that we do _with_ it? Are there any benef…

Well just a total guess but since it has a tiny bit more OO than C (traits) it could be argued it has a slightly better (aka more clearly obvious) ability to have plugins which is definitely possible in C, but it means you can pass a thing around that can do certain things for you, whereas in C there's a lot of crufty stuff to do that.

> whereas in C there's a lot of crufty stuff to do that.

Which is true.. but owing mostly to the fact that C actually has a stable ABI.

Re: Warp: Fast, Rust-based terminal (waiting list)

#76

Post by gratner »

I've been piloting Warp for a few weeks, and I have to say it's awesome. I can totally see the future of where this is going and I think that there is a lot left to be done to improve the terminal experience. Breaking the barrier of having the terminal be accessible only to thee most sophisticated folks will be huge. Excited to follow along with this project as it continues to evolve and mature.

Re: Warp: Fast, Rust-based terminal (waiting list)

#77

Post by LukeShu »

blunte wrote: post #47
woodruffw wrote: post #43

Earlier quoted context omitted.

Assuming that it wasn’t a rhetorical question: I do. I spend 1/3rd of my day in terminal emulators, and anything that reduces the number of stupid (normally memory corruption) crashes that interrupt my work is a legitimate value proposition for me. Edit: This isn’t an endorsement of this particular product, to be clear. I don’t know anything about it, except that being written in a fast, memory safe language endears…

What terminal are you using that crashes so often? I’ve used Linux and Mac terminals for ages and cannot remember one terminal crash.

rxvt-unicode regularly segfaults... during "quit".

Re: Warp: Fast, Rust-based terminal (waiting list)

#78

Post by sedatk »

barbazoo wrote: post #22

Somehow it feels odd that an implementation detail like the programming language it's implemented in is so prominent in the project's description. I have no idea what bash is written in and frankly I don't care much about it. It's a tool that enables me do be more productive. Could it be faster? Probably, but does anyone even notice that in the context of all the other things that we do _with_ it? Are there any benef…

I can see how "written in safe-only Rust" can be a plus, as that comes with certain security and safety assurances, but Rust itself doesn't warrant anything. You can write unsafe code with Rust too.

Re: Warp: Fast, Rust-based terminal (waiting list)

#79

Post by jstimpfle »

GordonS wrote: post #49
jacobmischka wrote: post #29

The UI seems interesting, and I'm a sucker for RIIR, but why do terminal emulators keep trying to use "blazingly fast" as a feature? They're all fast (except the hideous electron ones), they're white text on black rectangles.

I don't get it either - I use Windows (the default cmd, Powershell and Cmder), Linux and MacOS and don't recall a terminal emulator being slow... ever . Yet when the subject of terminal emulators comes up, there are often comments from other HN users insisting that Windows terminal emulators are molasses compared to MacOS, or that this emulator is much faster than that. I don't get it.

> I don't get it either - I use Windows (the default cmd, Powershell and Cmder), Linux and MacOS and don't recall a terminal emulator being slow... ever.

You might be a particular type of person... I don't remember Windows Cmd being not slow, ever. It feels extremely sluggish. It supposedly has something to do with Windows ConHost, but I don't know about the details.

In fact, even most terminals on Linux are unbearable to me. Not only do the antialised vector fonts tire the eyes on sub-4K screens - most of the terminals I've tried feel slow as well, though not as slow as Windows Cmd.

http://danluu.com/term-latency/

https://github.com/cmuratori/refterm

Personally I use xterm with bitmap fonts whenever I can, it feels sooo good. It has both crisp font rendering as well as being reasonably fast/responsive. (It's probably not the fastest ever in throughput if you want to display /dev/urandom, but that's not my benchmark).

Re: Warp: Fast, Rust-based terminal (waiting list)

#80

Post by wocka »

werm82 wrote: post #31
JeremyHerrman wrote: post #25

Warp looks great, but what do I do next? Where's the call to action? There is no download link, no "sign-up to hear more". With all of the thought and polish that went into this I'm surprised to see the ball dropped at the most important step!

There's a "Request access" button above the fold.

Not the original commenter, but thanks.

In my case the "Request access" button was blocked by uBlock Origin.

Post reply on HN