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

111–120 of 181 posts

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

#111

Post by optymizer »

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 see comments about open source, safety guarantees, speed, etc, but let's be honest. The real reason why Rust was mentioned in the title is because Rust is popular now and mentioning it attracts attention.

It's the same deal with every popular language that was the new hotness at the time: "written in Python", "written in Ruby", "written in Go" from years ago, which I see less of now.

Nothing wrong with this, it's just a straightforward way of tailoring information to the target audience to maximize engagement with an ad, whether the authors did it consciously or unconsciously (maybe they like Rust a lot and mention it often).

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

#112

Post by samatman »

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.

Not true!

If a terminal doesn't paint on a per-frame basis, then dumping reams of text to that terminal will slow the program to the speed of printing, this can easily be a 100x slowdown versus only updating the view when the monitor wants more pixels.

Most of them don't do this, so the ones that do are within their rights to advertise it as a feature.

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

#113

Post by vidarh »

wffurr wrote: post #103
vidarh wrote: post #96

Earlier quoted context omitted.

But who would expect Electron or web tech for a terminal ? Having written terminal code both in compiled and interpreted languages, and on machines about a thousand times slower than a typical modern machine, speed here is also much more down to algorithm choices - especially for rendering - than language. I find the focus on FPS pretty odd as well, as really high update speeds for a terminal typically only comes int…

I guess you missed the HN posts about another buzzy terminal app that is in fact written with Electron and boasts about extensible web tech as a feature: https://hyper.is/

I might have suppressed it, as the very idea is the stuff of nightmares.

That said, I'll note that unlike Warp it will actually run on Linux...

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

#114

Post by timw4mail »

vidarh wrote: post #96
zachlloyd wrote: post #32

Earlier quoted context omitted.

We mention Rust primarily because it produces a really high-performance app and to make clear that it's not built using Electron or web tech. We wrote up a pretty detailed technical design if you're interested in checking out how we built and why we made the decisions we made: https://blog.warp.dev/how-warp-works/

But who would expect Electron or web tech for a terminal ? Having written terminal code both in compiled and interpreted languages, and on machines about a thousand times slower than a typical modern machine, speed here is also much more down to algorithm choices - especially for rendering - than language. I find the focus on FPS pretty odd as well, as really high update speeds for a terminal typically only comes int…

They exist. Hyper is the most notable one using Electron.

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

#115

Post by vidarh »

samatman wrote: post #110
charlespierce wrote: post #44

Earlier quoted context omitted.

Warp is a terminal, we still rely on the underlying shell to do the interpretation / execution of the commands. At the moment, we support using bash, zsh, or fish as the shell.

...huh. Writing a tty which has to support specific shells isn't confidence inducing. How did you paint yourself into that specific corner exactly?

I'm guessing the auto-complete handling means they need to understand the line editing of the shell. If they've done it well, it'd hopefully be possible to quickly handle others and/or make it configurable.

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

#116

Post by techrat »

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.

> Our plan is to open source the Rust client code once it's more mature.

Your plan should have been to wait until something was downloadable before you announced it.

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

#120

Post by 411111111111111 »

samatman wrote: post #104
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.

The fact that it needs to be stated means that it has cloud features. Opt-in and "encrypted at rest" AKA actually encrypted are the correct defaults. I'm also uninterested unless both the client and the server are made open-source, because terminals are a bread-and-butter program and there's just no way I'm getting locked into someone else's cloud for that. But the specific sentence you've quoted is a strange thing f…

The point I got from that that it's unacceptable that it's keeping data on their servers. The issue wasn't that it's encrypted at rest - the issue was that they got data they need to encrypt to begin with.
Post reply on HN