alokedesai

For transparency, the issue with telemetry turning back on after an app restart was a very bad bug introduced yesterday that only affected new users; this is P0 for us to fix and we’ll have a new release out in the next few hours with a fix. The PR is here https://github.com/warpdotdev/warp/pull/9438/ if you want to follow along.

To add more color to some of your points in the post above:

* We give users the option to disable telemetry before sending any back to our servers.

* We use Sentry for crash reporting, this can be disabled.

* Yes, we record telemetry with the option to disable. The events are in our source code (as you point out) and also on our website.

* We have a network log in app that you can open and view _any_ request we make, including requests to send telemetry.

* If you compile the OSS build it has no telemetry or crash reporting.

Our motivation with open sourcing is to build more trust with our community, not less. Happy to discuss more and, of course, the codebase is available to audit.

Appreciate the kind words!

Warp is still a terminal, but it also has a coding agent.

no requirement to use it--and you can turn off all of the AI features if you don't want to use them at all

Awesome to hear that the features are reasonating with you, thanks for the kind words!

Hey, Aloke from Warp here.

We've actually added a ton of controls recently to let users configure how much (or little) UI they want. If that's not enough, would love if you opened an issue on the Warp repo and we can discuss more what needs to change in the product to meet your needs!

Thank you for the kind words!

Hey there, this is Aloke from Warp here. We originally built custom tab completions in Warp partly because of limitations with how Warp’s input works. We think our completions can be better for a lot of common commands (git, yarn, npm, etc) but I totally hear you that when completions in Warp don’t work like they do in another terminal it’s very frustrating.

No ETA for this yet, but this is very much on our radar to fix asap.

Aloke from Warp here. The experience if you don’t have admin access isn’t great—I’ll follow up and make sure this gets fixed.

Hi! I’m Aloke, an engineer at Warp.

I’m really excited to share that Warp is now available on Linux! If you’re interested in trying it out, you can download Warp at https://www.warp.dev/.

We've gotten 2-3 reports of authentication issues like the one the author mentions. We are actively looking into it; we believe its an issue with a library we depend on to open URLs. If anyone is experiencing these issues, please contact us at support@warp.dev so we can better understand the issue and further debug!

Building Warp on Linux was quite an undertaking. Warp uses a custom Rust-based UI framework that we built in house and renders natively on the GPU. To get Warp running on Linux, we built a version of our UI framework that supports winit [1] as a windowing backend. We also built a version of our renderer that uses wgpu [2]. Reducing complexity by using these well-supported, cross platform, frameworks let us bootstrap a version of Linux quicker than expected and should make it easier to build Warp for other platforms (like Windows).

Please let me know what you think! Happy to answer any questions, either about the product or about technical challenges.

[1] https://github.com/rust-windowing/winit [2] https://github.com/gfx-rs/wgpu

Hi! I’m Aloke, an engineer at Warp.

I’m really excited to share that Warp is now available on Linux! If you’re interested in trying it out, you can download Warp: https://warp.dev/

Building Warp on Linux was quite an undertaking. Warp uses a custom Rust-based UI framework that we built in house and renders natively on the GPU. To get Warp running on Linux, we built a version of our UI framework that supports winit [1] as a windowing backend. We also built a version of our renderer that uses wgpu [2]. Reducing complexity by using these well-supported, cross platform, frameworks let us bootstrap a version of Linux quicker than expected and should make it easier to build Warp for other platforms (like Windows).

Please let me know what you think! Happy to answer any questions, either about the product or about technical challenges.

[1] https://github.com/rust-windowing/winit [2] https://github.com/gfx-rs/wgpu

Hey there, thanks for feedback. We built our own UI framework in Rust to build Warp, and there were some initial rendering quirks--especially with rendering text on low resolution monitors.

I'd love to hear more about the rendering issues you've faced when using Warp so we can fix them!

Hey there, engineer from Warp here. Warp never collects input or output from the console. There is only high-level tracking for monitoring app crashes and some feature usage data. Our philosophy is total transparency around telemetry. We’ve created a Network Log tool you can use to watch all events in real-time [1] and we have a full list of telemetry events we record in Warp’s docs [2]. You can also opt out of telemetry in Warp’s settings.

Warp requires a login to support its collaboration features (for example sharing commands with a team). Login makes it possible for developers to collaborate securely.

[1] https://docs.warp.dev/features/network-log [2] https://docs.warp.dev/getting-started/privacy#exhaustive-tel...

Hi there! I’m Aloke, an engineer at Warp. Happy to answer any questions!

If you are interested in trying Warp (including our new collaboration features), you can download Warp here: https://www.warp.dev

I've been making clear ice at home for a while--it's a great party trick and much easier to do than it seems.

The best part is chiseling ice cubes from a large clear block of ice: use a serrated knife and a hammer and you will end up with perfectly square blocks of ice.

Disclaimer: I work at Warp (warp.dev) and wrote the initial How Warp Works blog post (https://www.warp.dev/blog/how-warp-works) that discusses why we chose to write our own UI framework.

This is a great article! Writing a custom UI framework to render on the GPU is a big cost--but it has been worth it for us. It has let us build a UI-heavy terminal while continuing to match the performance of some of the fastest terminals on the market (such as Alacritty). There is certainly an initial velocity hit for new engineers as they have to learn the semantics of our framework, but overall I wouldn't say it has a big detriment on our velocity as a consumer of the framework.

The callout to a11y is a good one--we have basic a11y support but it is by no means robust. There are additional downsides to building your own GPU-rendered UI framework other than a11y that I want to call out: you have to build most of the interactions with the platform yourself instead of getting it for free when rendering using system APIs.

One example of this is properly supporting i18n. A robust framework should support RTL text, positioning IME / the emoji picker, so forth. While implementing these yourself is doable (we have decent support for IME at Warp, for example) it requires an engineer or two to spend a few weeks to implement.

Text rendering is also a beast, see https://www.warp.dev/blog/adventures-text-rendering-kerning-....

For Warp, this has definitely been worth it, but it hints that the community needs better cross-platform GPU-rendered UI frameworks so people don't need to consistently build them themselves.

We collaborated with thefuck to build our version of this :) TF is slightly different in that they actually _rerun_ your last command to get the output since they don't have access to command output

We are actively working on making telemetry opt out. We are very sympathetic to concerns about telemetry and data collection and try to be as transparent as possible about what we collect and why. We only collect metadata and never command input or output (you can see the full list of events we track here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel....

We initially required telemetry for all users while in beta so that we could have a better understand of usage patterns and improve the product in its early stages. As we mature, we are able to better extrapolate from a larger sample size without requiring telemetry.

You can launch vim within Warp without any problems, but vi/vim mode for the line editor itself isn't supported in Warp just yet. You're correct that this is because we'd need to implement VI mode ourselves (tracking issue here [1] if you are interested).

This is the tradeoff of building our own editor instead of using the shell's--we can build features that wouldn't be possible in the shell directly but it requires us to build features that already exist in the shell from scratch. So far, this tradeoff has been well-worth it to build what we think is a better experience when using the terminal.

[1] https://github.com/warpdotdev/Warp/issues/159

Thank you for your kind words! We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client. We want to make sure we get this right, both for our users and for Warp.

Our current best-guess on how we'd do this is a more restrictive license that * allows for verifying security and privacy * allows individuals to build and tweak Warp * prevents another company from starting a commercial enterprise off of it

We'd love more thoughts here though! Feel free to join the discussion at https://github.com/warpdotdev/Warp/discussions/400 if you're interested.

Aloke from the Warp team here--you're totally right that some of these features (syntax highlighting) can be accomplished within the terminal using an editor. In a traditional terminal--you'd have to spend time configuring your shell to get this to work instead of getting these features by default.

Some of these features are near-impossible given the current terminal-shell abstraction, however. For example, a traditional terminal has no concept of command input/output, which means that it can't suggest a next command to run based on the output of the previous command.

Hi HN,

I’m Aloke, one of the co-creators of commands.dev (https://www.commands.dev/) and an engineer at Warp (https://www.warp.dev/).

Commands.dev is a curated, open-source collection of popular terminal commands that lets you quickly search for hard-to-remember terminal commands by title, tag, and description. Each of these pages are also indexed by Google to provide a consistent, well-formatted alternative to the variety of sources these commands turn up now, like StackOverflow.

As an engineer who uses the terminal frequently, I often have trouble remembering the exact command I want to execute if it’s not easily searchable within my terminal. Some commands that I run infrequently don’t match up with the underlying task they perform, which makes it even harder to find. For example, to undo my last git commit, I have to search for “git reset”, which I never remember because I’m always thinking “undo”ing my last commit instead of “reset”ing.

We built commands.dev so that there would be a centralized place to quickly find and search commands based on their name, description, or category. If you are a Warp user, these commands are also integrated directly into Warp as a feature we call Workflows (https://docs.warp.dev/features/workflows) so that you can quickly search and execute them directly from the terminal.

These commands are open-source (https://github.com/warpdotdev/workflows) and we would love contributions to make commands.dev even more useful. So far, we’ve already had 85 commands created by 22 unique contributors.

I’m excited to hear what you think of commands.dev! Our team sincerely hopes this will become a go-to tool on the Internet to consult when developers need to remember a difficult command, either directly on the site or by discovering a commands.dev page when searching Google for help with a command.

If you’re interested, join Warp’s Discord (www.warp.dev/discord) and follow us on Twitter (www.twitter.com/warpdotdev).

Hey, thanks for the kind words!

The terminal is totally free for individuals. Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features.

The general philosophy is that we would never charge for anything a terminal currently does. So no paywalls around SSH or anything like that. The types of features we could eventually charge for are things that have a cost to us, for example enabling real-time terminal collaboration. Even those will likely be free up to some level of usage and only charged in a company context.

Great question! Warp has many features that more traditional terminals don't have. Mainly:

- Blocks: we group commands and outputs together so it is easier to navigate through the terminal, and perform actions on the outputs [0]

- A text editor for the input: selections, cursor positioning, multiple cursors [1]

- Workflows which allows you to save and share hard-to-remember commands [2]

[0]https://docs.warp.dev/features/blocks

[1]https://docs.warp.dev/features/the-input-editor

[2]https://docs.warp.dev/features/workflows

Thanks for flagging that! There's a long-tail of completion improvements in Warp that we'd like to fix in the coming weeks/months. We'll make sure this gets fixed!

That's a great question! Version controlled shell scripts are very useful (and in fact workflows in Warp can also be version controlled) but they still have a few problems: 1) Documentation--when a repo has a lot of shell scripts, it can be very difficult to know which command to run in certain situations. Even if each shell script has documentation, there's no way to find that documentation natively from the terminal itself. 2) Searching--you can only execute commands from the terminal based on the shell script name but there's no easy way to search for a script based on _what_ it does or any other metadata.

Thanks for calling this out! Yeah we unfortunately had a memory issue early on with loading fonts that would cause memory in Warp to explode. This has since been fixed and memory in Warp should hover around ~50-100 MB.

Yeah, this is a known issue, unfortunately--but it's definitely something we want to fix as we improve Warp. See more information here where we chat with Casey about it: https://twitter.com/zachlloydtweets/status/14175482714432348...

That's an important callout! By console output, we really mean output from the pseudoterminal, which includes command input and output printed to the terminal.

We don't store any content of _any_ part of a command that's executed in Warp.

We do support SSH, but Docker support is still something we'd like to support, you can read more about how we are able to render blocks here: https://www.warp.dev/blog/how-warp-works.

Ultimately, our ideal state would have to have an API for this so that developers can implement this themselves to support blocks in arbitrary REPLs (mySQL, Python, etc).

We had actually already picked the name before we settled on using Rust, but we think the warp server framework is great and actually used to use them as a dependency at one point in time