Live data from Hacker News

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

warp.dev

171–180 of 181 posts

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

#172

Earlier quoted context omitted.

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.

What does a responsive terminal look like compared to something else? What are you doing with your terminal that demands responsiveness? Genuinely curious. I've never ran into a situation where the standard terminals felt "sluggish"... barring a slow internet connection sshing.

It's hard to describe, things just feel quicker. Scrolling through files in vim or tailing logs is super smooth, when your grep accidentally hits a huge json file that's lurking in your project it prints instantly instead of making the terminal unresponsive for a few seconds.

I used Urxvt for about fifteen years, it didn't feel slow at all. Kitty just _feels_ faster.

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

#173
post #98

Earlier quoted context omitted.

Things that eat your data, your time, your money, your attention. Fads. Unicorns (but they probably don't exist).

THIS. Chasing after shiny things ignores means wasting the opportunity to become truly expert about something. EDIT: silent downvotes for saying this?

I didn't downvote you, but it's certainly fine to pass on something you think is a fad. It's another thing to jump directly to the end of the emotion spectrum by saying "hard no". My comment wasn't about skipping shiny things, it was about being so vocally firm about the negative. That doesn't leave much room for reconsideration later.

What if the project turns out to not be a fad, and a month or six later more people are using it and loving it? How does a "hard no" person back down from their bold rejection? This is what I was talking about.

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

#174
post #98
post #51

Earlier quoted context omitted.

If you “hard no” so easily, then what else may you be missing out on?

Things that eat your data, your time, your money, your attention. Fads. Unicorns (but they probably don't exist).

I had no idea that terminals and Rust projects were such highly charged emotional territory, nor that either were danger zones which commonly ate your time, your money, or your attention.

Kind of seemed to me like just another project.

I guess the kids these days have to start at volume 10 with "hard no!" or "best ever!" to be heard. THAT is a fad.

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

#175
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.

https://xkcd.com/463/ Strictly speaking, your plan is better than the alternative of keeping it closed-source, yet someone is clearly doing their job horribly wrong.

Anything useful you produce will be community-maintained eventually, and your cloud product will vanish once you complete your amazing journey; anything in-between seems like rent-seeking. Meanwhile, your competitors are Free Software and can out-develop you.

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

#176

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?

This. Also the mention of ‘collaboration’ and ‘cloud’ put me off. “Do one thing and do it well”.

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

#177

Earlier quoted context omitted.

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.

What does a responsive terminal look like compared to something else? What are you doing with your terminal that demands responsiveness? Genuinely curious. I've never ran into a situation where the standard terminals felt "sluggish"... barring a slow internet connection sshing.

You should look into Casey Muratori's quest[1] against Windows terminal slowness on github and youtube. There were some heated exchanges there and some proof of concept software created to demonstrate both how slow Windows Terminal is, and how fast a GPU enabled terminal can be.

[1] The latest video for it is here: https://www.youtube.com/watch?v=99dKzubvpKE

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

#179
post #47

Earlier quoted context omitted.

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

Maybe it's the way I use it, but iTerm2 crashes (or hangs) fairly regularly for me on macOS. I usually need to restart it at least once a week, which means losing ~dozens of tabs with context in them. I use urxvt on Linux, and I don't have any problems with it. Edit: I should also mention that I see plenty of non-crashing, non-hanging bugs with iTerm2 that look like memory misuse to me: split-workspace mode (tiled wi…

[deleted]

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

#180

Earlier quoted context omitted.

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.

What does a responsive terminal look like compared to something else? What are you doing with your terminal that demands responsiveness? Genuinely curious. I've never ran into a situation where the standard terminals felt "sluggish"... barring a slow internet connection sshing.

For one thing it's easy to build a bash line or even a NodeJS script that produces a lot of output that is dominated by the terminal's capability to render. When you benchmark it against the same thing but with a `foo > /tmp/foo.txt` redirection into a file, you'll notice that on bad terminals, it's several times or even orders of magnitudes faster than rendering to the screen. Many, many terminal emulators I have tried in the past did look sleek at first sight but then failed miserably a simple `cat manylines.txt` test.
Post reply on HN