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

Show HN: Warp, a Rust-based terminal

warp.dev

Post reply on HN
Print view View original

281–290 of 757 posts

Re: Show HN: Warp, a Rust-based terminal

#281

Post by Mister_Snuggles »

qbasic_forever wrote: post #54
orastor wrote: post #20

Wanted to give it a shot but got disappointed when I launched it and the following happened: - Outgoing request to googleapis.com - Outgoing request to segment.io - Outgoing request to sentry.io - Requires sign up (only via Github, mind you) I understand the first request is probably to get some dynamic configuration, even though I'd rather my terminal ship with static configuration. But then you have segment and sen…

Wait, you _have_ to have a github account to even open this terminal? Yikes.

I remember an iOS email client many years ago that required a Dropbox login for some reason. It made no sense that an email client would require me to log in to a cloud file storage/syncing service - in my mind these two things are completely unrelated. That email client ended up disappearing.

I expect that a terminal program which requires a login to a completely unrelated service will end up meeting the same fate as that email client did.

Re: Show HN: Warp, a Rust-based terminal

#282

Post by akho »

qbasic_forever wrote: post #85

I love the idea of mixing terminal and documentation, kind of like a terminal notebook. I wish there was an open source project that was basically just a shell/bash jupyter notebook and nothing more. So many little scripts, makefiles, project setups, etc. would be way easier to understand and maintain if they were mostly markdown documentation with some big "Run this" buttons next to the code blocks.

There is a bash kernel for Jupyter.

Re: Show HN: Warp, a Rust-based terminal

#283

Post by rattray »

michlim wrote: post #59
munro wrote: post #35

> Telemetry > When Warp comes out of beta, telemetry will be opt-in and anonymous. > But for our beta phase, we do send telemetry by default and we do associate it with the logged in user because it makes it much easier to reach out and get feedback when something goes wrong. This is a hard pass for me, it looks really amazing though. I'm so tired of telemetry, how do we quit our day jobs to focus on open source? ;-;

Warp engineer here. I understand your concern. We will remove telemetry when we enter general availability. It will be opt-in and anonymous. We really want to improve the product quickly during this beta phase. Collecting data makes it much easier to reach out and get feedback when something goes wrong. But we only track metadata, never console output. For an exhaustive list of events that we track, see here: https:/…

I totally get your perspective, and I'd do the same thing… but only before launching on HN. If you want feedback from the hacking public, you have to accept that it'll be inefficient.

For myself, the visuals are compelling enough that my fingers twitched over "download" but the "you'll have to log in to your terminal" messaging I see here was enough for me to not, and even though I could theoretically do it later, it leaves a bad taste in my mouth that (rationally or no) will probably hold me back from trying it once it's GA.

Re: Show HN: Warp, a Rust-based terminal

#284

Post by GekkePrutser »

jacobsimon wrote: post #51
orastor wrote: post #20

Wanted to give it a shot but got disappointed when I launched it and the following happened: - Outgoing request to googleapis.com - Outgoing request to segment.io - Outgoing request to sentry.io - Requires sign up (only via Github, mind you) I understand the first request is probably to get some dynamic configuration, even though I'd rather my terminal ship with static configuration. But then you have segment and sen…

Come on. You must realize VS Code and basically every website you use collects telemetry data, which is rarely for anything nefarious except product improvements. If GitHub/Microsoft had released this product, would you be raising the same concerns?

I use VS Codium for this reason and self host git so yeah for me that's definitely a thing. And I have a ton of stuff to block as much telemetry from other software and websites as I can, including on mobile.

It's not for everyone but yes there are still Don Quixotes like me fighting the army of windmills :)

I suspect the proportion of us here at HN is pretty high too.

Re: Show HN: Warp, a Rust-based terminal

#285

Post by tedivm »

cors-fls wrote: post #26
orastor wrote: post #20

Wanted to give it a shot but got disappointed when I launched it and the following happened: - Outgoing request to googleapis.com - Outgoing request to segment.io - Outgoing request to sentry.io - Requires sign up (only via Github, mind you) I understand the first request is probably to get some dynamic configuration, even though I'd rather my terminal ship with static configuration. But then you have segment and sen…

I cant use it either (mostly because it's Mac only and also because of the sign-in requirement), but at least they are transparent about it : https://docs.warp.dev/getting-started/getting-started-with-w... https://docs.warp.dev/getting-started/privacy

That privacy policy is sketchy. It starts with this-

> Our general philosophy is complete transparency and control of any data leaving your machine. This means that in general any data sharing is opt-in and under the control of the user, and you should be able to remove or export that data from our servers at any time.

They then go on, further down the page, to say that this first paragraph is a complete lie-

> However, for our beta phase, we do send telemetry by default and we do associate it with the logged in user because it makes it much easier to reach out and get feedback when something goes wrong.

Re: Show HN: Warp, a Rust-based terminal

#286

Post by dudus »

ha_mei_93 wrote: post #263

Quoted post unavailable.

I don't follow the drama. I only hear good things about Rust from the folks here at HN's, I personally never got interested in checking it out.

But I don't quite follow why it's so important to know what programming language was used to build your closed source binary terminal app. Cool you used Rust. Why should I care?

I use iTerm2 as my Terminal. Their homepage doesn't tell me which language it was written in, it has a nice page that highlights its features, and an extensive FAQ. In neither of these places language choices are highlighted. You only see that once you go into their gitlab, which is what I expect.

It's mostly Objective-C BTW.

Re: Show HN: Warp, a Rust-based terminal

#287

Post by alpaca128 »

exdsq wrote: post #55
jacobsimon wrote: post #51

Earlier quoted context omitted.

Come on. You must realize VS Code and basically every website you use collects telemetry data, which is rarely for anything nefarious except product improvements. If GitHub/Microsoft had released this product, would you be raising the same concerns?

Maybe not but I'd trust Microsoft has a decent security and privacy team working on this more than a startup. What if they're logging the wrong stuff and my data is leaked?

You mean like when Microsoft started uploading all handwriting & voice recognition inputs including passwords?

History has shown that telemetry is effectively spyware until proven otherwise, no matter who does it.

Re: Show HN: Warp, a Rust-based terminal

#288

Post by iskamag »

steveklabnik wrote: post #198
andrewzah wrote: post #172

Earlier quoted context omitted.

That would also now force everyone to use this proprietary product instead of whatever they're familiar with. For mac linux, posix-compliant scripts mostly work in my experience but you have to account for different versions of gnu utils. For linux windows, if it's small you could just write a powershell script, or use something like python on both, no? I fail to see how these features are nice enough to force people…

Yes, that is true, but it does seem like that's what their strategy is. If you're using these collaboration tools at your job, you'd have to be using the product already. So that's less of a problem than it would be for say, scripts included with some sort of open source project. My point is mostly that shell isn't cross-platform, and this is one way you could address that. But it's not a generalized solution, absolu…

>shell isn't cross-platform

basically every operating system has a posix shell by default except windows, but it has been ported there multiple times, samba existed for decades and WSL is on the rise. It may sound a little more irritating but they deserve it for still running windows :p /hj (besides you can just host an ssh server)

Re: Show HN: Warp, a Rust-based terminal

#289

Post by zhengt »

ha_mei_93 wrote: post #263

Quoted post unavailable.

We started with Electron/Typescript and pivoted to Rust when it was clear that the performance was unfeasible for certain workloads (e.g. scrolling on 4k monitors).

If we already had a C++ terminal, I don't know that we would've rewritten in Rust. Starting from scratch, we were able to build an app and ship features in a good cadence.

We mention Rust in our marketing, because when talking about our features like blocks, code editor, visual menus, people automatically think "slow".

Re: Show HN: Warp, a Rust-based terminal

#290

Post by zokier »

michlim wrote: post #229
scottlamb wrote: post #195

Like others here, I'm leery of replacing my terminal with a VC-backed, maybe open-sourced eventually product, and a bit annoyed it claimed a name already in use in the Rust world. But...it is exciting to see someone reimagining the terminal a bit. People frequently talk about wanting a better GUI interaction model for everyone, but the actual ideas to improve it seem to be missing, I think because the desktop status…

Warp engineer here. Really appreciate your ideas here! > Warp's more visual completion is super welcome. Does it work with the shell's standard completion scripts? It does not. But we have completions out of the box for 200 commands. Warp's input is a text editor instead of the shell input. This means we ended up building completions by hand and soon, via the community. We think this is a better experience because we…

I'm wondering if the solution for the block separation could be to have separate tty (or pty?) for each block. I guess that wouldn't work too well with existing shells though
Post reply on HN